Ah excellente nouvelle Je passe le sujet en résolu !

@julienXOvates sounds promising !! @gashorus in last veeam webinar they announced for veeam v13.1 (currently 13.0.1) to be out of beta on XCP-NG plugin... date : june 2026.

@psafont Thank you for the quick response. I also found a similar issue: the other-config:auto-scan=true parameter is not being applied during xe sr-create either. As with the name-description parameter, the workaround is to add it separately afterwards using xe sr-param-add.

Dug a little deeper. For a VM where the disks are not shown the following XO API call fails: /rest/v0/vms/a519e879-3971-9210-51b6-7df14336e7b7/vdis { "error": "no such VDI ac37700d-3157-4df7-b8e8-e1799a994591", "data": { "id": "ac37700d-3157-4df7-b8e8-e1799a994591", "type": [ "VDI" ] } } Also the VDI cannot be retrieved over the XO API: /rest/v0/vms/a519e879-3971-9210-51b6-7df14336e7b7 ... "$VBDs": [ "4ea8a3cd-0d1b-dc60-4d9c-fd70e060f06c", "9f4ca686-9fc2-35a9-c3e9-c871c9f68aba" ], ... /rest/v0/vbds/9f4ca686-9fc2-35a9-c3e9-c871c9f68aba { "type": "VBD", "attached": false, "bootable": false, "device": "xvda", "is_cd_drive": false, "position": "0", "read_only": false, "VDI": "ac37700d-3157-4df7-b8e8-e1799a994591", "VM": "a519e879-3971-9210-51b6-7df14336e7b7", "id": "9f4ca686-9fc2-35a9-c3e9-c871c9f68aba", "uuid": "9f4ca686-9fc2-35a9-c3e9-c871c9f68aba", "$pool": "93d361b7-f549-53b7-a3aa-c9695bf0abe4", "$poolId": "93d361b7-f549-53b7-a3aa-c9695bf0abe4", "_xapiRef": "OpaqueRef:1d424d94-f540-2eb4-9e52-2a9b21ec0a19" } /rest/v0/vdis/ac37700d-3157-4df7-b8e8-e1799a994591 { "error": "no such VDI ac37700d-3157-4df7-b8e8-e1799a994591", "data": { "id": "ac37700d-3157-4df7-b8e8-e1799a994591", "type": "VDI" } } However the VDI can be listed using the xe cli: $ xe vm-list uuid=a519e879-3971-9210-51b6-7df14336e7b7 uuid ( RO) : a519e879-3971-9210-51b6-7df14336e7b7 name-label ( RW): XXX power-state ( RO): halted $ xe vbd-list vm-uuid=a519e879-3971-9210-51b6-7df14336e7b7 uuid ( RO) : 4ea8a3cd-0d1b-dc60-4d9c-fd70e060f06c vm-uuid ( RO): a519e879-3971-9210-51b6-7df14336e7b7 vm-name-label ( RO): XXX vdi-uuid ( RO): <not in database> empty ( RO): true device ( RO): xvdd uuid ( RO) : 9f4ca686-9fc2-35a9-c3e9-c871c9f68aba vm-uuid ( RO): a519e879-3971-9210-51b6-7df14336e7b7 vm-name-label ( RO): XXX vdi-uuid ( RO): ac37700d-3157-4df7-b8e8-e1799a994591 empty ( RO): false device ( RO): xvda $ xe vdi-list uuid=ac37700d-3157-4df7-b8e8-e1799a994591 uuid ( RO) : ac37700d-3157-4df7-b8e8-e1799a994591 name-label ( RW): XXX Disk 0 name-description ( RW): Created by XO sr-uuid ( RO): 977b7e63-bb84-57b2-3e0d-206afea553bf virtual-size ( RO): 34359738368 sharable ( RO): false read-only ( RO): false Seems almost like something changed in the XCP-ng API which XO cannot consume.

Hi, What's your S3 provider?

Hi @maximsachs, Sorry for the delay. From what you describe, the driver seems to be probed in all cases but I have a doubt regarding the driver from xcp-ng 8.2. I rebuilt it specifically for 8.3. To completely eliminate a driver issue, can you try this RPM ? From the host, this can be done by running the following commands: $ wget https://nextcloud.vates.tech/public.php/dav/files/R33Dwpt5gjy6CCr/broadcom-bnxt-en-1.10.0_216.0.119.1-1.0.82srcs.0.xcpng8.3.x86_64.rpm $ yum update ./broadcom-bnxt-en-1.10.0_216.0.119.1-1.0.82srcs.0.xcpng8.3.x86_64.rpm Also, since this xcpng-8.2 release seems to have support for device IDs that have been removed from the 8.3 one, can you give the output of the following shell commands: $ lspci -nn -s 0001:86:00.0 and $ lspci -nn -s 0001:86:00.1 Regards, Thierry

ping @poddingue for visibility as I believe I've found the trigger for IPv6 expanding... Live Migrations

@julienXOvates Excellent, thanks for looking at this Julien! Rob