Sorry to necro-post this but I thought I'd come back and let you know that the new (finally signed) guest drivers for Windows resolved the problems I had been having with "inaccessible boot device" whenever I tried to install the Xen guest drivers while also using PCI-Passthrough to pass a nvme drive directly to the VM. The VM now boots perfectly fine with the boot disk being a virtual drive while allowing me to use the passthrough nvme as a data disk to which most of the software and my Steam library is installed. And ever since my virtual gaming rig has been stable and performing as I have expected.

@julienXOvates Sure. This is the backups page in XCP-ng...![image: 1778543444207-ss7.jpg]

After looking at things some more and not seeing anything else I could do, I restarted the controller and satellites. This allowed things to recover.

@Chuckz That's great and very cool. Unfortunately Microsoft doesn't publish the containers in a place like docker hub, rather they distribute a PowerShell script that installs and configures the containers on a Windows server, specifically. Updates to the Microsoft Enterprise Connected Cache is also updated via Windows services/tools.

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

@AlexanderK said: which is the difference with this? https://github.com/ronivay/XenOrchestraInstallerUpdater Using the above around 5-6 years with no issues at all e.g. XenOrchestraInstallerUpdater does not support Debian 13 yet.

Copy Fail is documented in VSA-2026-013, we don't have one for Dirty Frag yet as we're still investigating XCP-ng side regarding it. For XOA, unattended updates should have installed the patched debian kernel, you just need to reboot it. Debian security tracker states they are both fixed: https://security-tracker.debian.org/tracker/CVE-2026-31431 https://security-tracker.debian.org/tracker/CVE-2026-43284

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

@poddingue there is a notion of appliance too (group of VMs) https://docs.xcp-ng.org/appendix/cli_reference/#appliance-commands where you can start/stop a group of VMs, never tried it, doesn't seem to have a boot order in the vAPP neither

The "PIF is not attached" usually means the network interface selected as the migration network isn't currently active on the target host. It can happen after upgrades if the host hasn't been fully rebooted. Worth checking whether a reboot of both hosts changes anything, and running xe pif-list to see whether that specific PIF shows currently-attached: true on the target. If the PIF looks attached in xe but migration still fails, might be worth a ping to Team-XAPI-Network.

@poddingue Thanks for your input. Yes I'm aware that basically everything on the VM is incorporated into the snapshot. Including settings and metadata. This is acctually why I was surprised that the creation date wasn't preserved as part of that metadata. And as you say, if one uses that metric to track VM history. Then it can, and will, throw you off. I'll gladly submit this as a feature request. But my gut feeling is that it is more akin to a bug than missing feature per se. Thanks!

From what I understand, the OS-to-iDRAC pass-through is a direct USB link between the host and the BMC, designed for the hypervisor host itself to talk to the iDRAC, not something that would naturally bridge through Xen's networking layer into a VM. That might be why the PIF shows up in XCP-ng but the VM still can't reach 169.254.0.1; the bare metal case works because the OS sits directly on the hardware with no virtualisation layer in between. If you need the VM to have direct BMC access, USB passthrough might be worth exploring; XCP-ng does support passing USB devices through to VMs (https://docs.xcp-ng.org/compute#usb-passthrough), though I'm not certain the iDRAC virtual USB NIC would show up as a passthrough-able device. Might be worth a mention to @Team-Hypervisor-Kernel to find out; others here will know more than me.

@Pilow @acebmxer Thanx for your replies. And sorry, i havent seen your first reply between my last posts with the link to your existing Thread. So, i think this is some kind of a bigger thing. Will handle with care, but i have to leave for today. Maybe i have time to test the snapshot and revert workarounds on the weekend. But these are all production VMs. Have to coordinate. I have 2 NFS-SRs in the Pool. Will try to migrate VMs from one to the other and see if this helps. Kind Regards and thx again Alex

@pkgw I tested it with a cluster size of 2 megabytes. I got similar results to those with the default size.

@ducatijosh did you do a yarn build ?