@JL457 Hi, For now it looks like Wasabi is not sending us the correct date format, which is strange because we support this provider and don't usually have issues. In order to allow us to investigate further, could you send us the full backup job logs ? You can find them by clicking on the failed backup status and then on the download logs button: [image: 1779106635704-export-logs.png] Relevant XO logs would also help. If you are a client, also don't hesitate to open a ticket with an open support tunnel. Thanks.

@taghjichte From my testing you would need to passthought a device for audio. If need for professional audio work then yes a pci passthough would be the perferred option. With that said. @dinhngtu As for sound I have never looked much into it but the only vm I heard make sound is from Fedora even while booted from install iso. Kubuntu or windows with xen drivers installed no audio. (find for me at the moment) While audio seems to work in Fedora from iso it seems to be limited to left channel. Local system is connected to 5.1 sound.

@tsukraw I am taking the ticket and will keep you informed as soon as possible

@johnnezero The full HTML versions will render much better. The PDF conversion is less than perfect. iIll try to get those uploaded, as well.

Take it with a grain of salt, but I think bonds are usually managed as a whole rather than edited port by port in the UI. As far as I can tell, the supported route is from the network section in Xen Orchestra (the bonding part of the infrastructure docs is here: https://docs.xen-orchestra.com/xo5/manage_infrastructure#network-bonding), and on the CLI side, the bond commands are documented at https://docs.xcp-ng.org/appendix/cli_reference#bond-create (there's a matching bond-destroy command alongside it). My honest guess is you may end up destroying and recreating the bond with the four ports you want to keep, since I'm not sure removing a single member in place is exposed anywhere, but I could easily be wrong. If there's a cleaner way that avoids the recreate, someone will let us know.

This is a nice bit of community tooling, and thanks for keeping it updated and being upfront about the "use at your own risk" part. On the naming point a few people raised, I think the distinction folks are drawing is fair: XOA is the Vates-built appliance, and anything you compile yourself is XO from sources. The official docs cover that path at https://docs.xen-orchestra.com/xo5/installation#from-the-sources, including the note that there is no pro support for that method. Hope the project keeps going well!

Quick update now that Vates has published their official advisory. First, kudos to the Vates security team for the thorough and timely response. VSA-2026-014 is well-documented and covers the full picture, including a third CVE I had not covered in my earlier posts. VSA-2026-014 confirms what I outlined above: XCP-ng is affected by CVE-2026-43284 (XFRM-ESP) and is NOT affected by CVE-2026-43500 (no RxRPC support). The CVE I had missed: CVE-2026-46300 ("Fragnesia") also affects XCP-ng via the XFRM ESP-in-TCP subsystem. The same esp4/esp6 blacklist mitigation applies, with the same caveat @semarie raised: it will break encrypted private networks on XCP-ng. Now that the VSA and official mitigation guidance are public, I'm releasing the diagnostic script I built. It's Python 3.6, no external dependencies, safe to run on production dom0. It tests whether an unprivileged process can engage the esp4 engine via the XFRM interface inside a user namespace — without touching any exploit code. Since both CVE-2026-43284 and CVE-2026-46300 (Fragnesia) require esp4 or esp6 to be reachable from an unprivileged namespace, and share the same mitigation, a positive result confirms exposure to both. Blacklist esp4/esp6, then run the script again — ACCESS DENIED means both CVEs are mitigated. One important note before running it: please read the code before executing it on any of your systems. This is good practice with any script from the internet, regardless of the source. The code is intentionally short and straightforward so you can review it quickly and satisfy yourself that it does exactly what it says. VSA-2026-014: https://docs.vates.tech/security/advisories/2026/vates-sa-2026-014/ Diagnostic tool: https://github.com/grabesec/XCP_ng_CVE-2026-43284_tester A kernel patch from Vates is in progress. Apply as soon as it lands.

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.

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

@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.

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

@yomeyo I had this also, but problem disappeared itself. https://github.com/xcp-ng/xcp/issues/793 [image: a3dcbb0b-fe7a-4389-addc-247190039a18] IgorGlock created this issue in xcp-ng/xcp open XN-xenguestagent-rs skips IPv4 at Windows boot #793

@Mathieu-L linstor n l was included in my original post. All nodes were updated to May 2026 Security and Maintenance Updates for XCP-ng 8.3 LTS, all nodes were restarted. May 2026 Updates #2 for XCP-ng 8.3 LTS was released, and a couple days later I installed on all hosts. No host restarted. When xen04 was restarted, that is when this issue happened. I had used systemctl restart linstor-controller here (https://xcp-ng.org/forum/post/105309) to restart the controller.

Thanks for that information. I will make this message short because @stormi is busy but I want to say thanks to Vates and XCP-ng for all their work done to support Windows on the Xen platform. This includes TPM2 and secure boot support and Microsoft-signed pv drivers. Well done!

Nice!! Thanks for the feedback @mattrc , it's really cool to see that you can fully enjoy your machine

Hi! I think what you're seeing may be stale entries in the XAPI database, ghost records that can survive upgrades or host reconfigurations. From what I've read, xe vm-destroy uuid=<vm-uuid> removes the record without touching any storage, which seems like what you need here; the xe CLI reference confirms storage is left intact. I think you can get the UUID first with xe vm-list name-label="Before Ubuntu Update" (replacing the name with whichever one you're after). I'm not entirely sure why xsconsole would show them but XO wouldn't, so if the VMs don't turn up in xe vm-list, it might be worth a mention to Team-XAPI-Network, they'll know the right way to dig into XAPI state.

@pierrebrunet @poddingue the size is really 2.17Tb, but showing last incremental size on the key I'll wait for the patch, this is really a visual bug, backup is working okay.

@afk I’ve got two draft nixpkgs for libvhdi and Xen orchestra from sources respectively, I’ll look into submitting them upstream soon but take a look and feel free to share any feedback xen-orchestra-ce libvhdi.

@dthenot said: @ccooke Hello, You should be able to make the XOSTOR SR work again if you update sm and sm-fairlock on the other hosts. yum update sm sm-fairlock Then you should be able to re-plug the SR on the master and proceed with the RPU. Hello, Had the same problem, the command resolved the issue. It needs to be run on every host. Everything is working fine again. However, I had to complete the pool update manually.