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

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

@dkg Oops sorry I thought you were someone else having the same issues.

@bvivi57 xo do check license if you have xostor installed, since it need some magic to work at a lot of steps ( like the rolling pool updates) this is the expected behavior with a manually installed xostor ( cc @julienxovates for information )

@acebmxer not yet (a little under the water with the release patch, but we will do it )

@vlamincktr XO PROXY from source is pretty reliable at no cost either use @acebmxer script or @ronivay here is a quick tuto on an ubuntu VM https://omnibox.huducloud.com/shared_article/QJ9y1bRSPj9VTbWp6NKaV7yn/installation-xoa-a-partir-des-sources-github-ronivay first part is XO CE, second part is XO PROXY CE beware as you delegate some jobs to XO PROXY, to ever upgrade XO PROXY when you upgrade XOA, so that they have the same backup mechanisms/code

Hello all, XenClean/XenBootFix 9.1.152 have been released. This release fixes VSA-2026-012 (DLL sideloading vulnerability in XenClean and XenBootFix). If your VM is running 9.1.146, you don't need to update. You just need to replace any XenClean and XenBootFix files you downloaded. The package\XenClean and package\XenBootFix directories contain fixed versions of the aforementioned tools. package\XenTools-x64.msi has not changed from version 9.1.146, and is only provided as a convenience. The installation MSI does not include the fixed XenBootFix. You must use the one from package\XenBootFix or download the tool directly from GitHub! The next release of the XCP-ng Windows Guest Tools will contain a fixed version of XenBootFix. Get it here: https://github.com/xcp-ng/win-pv-drivers/releases

@lknite Hello, sorry if replying in this old thread looks odd... but I wanted to share that we are starting to work on supporting Cluster API. We have an internal proof of concept: /home/nathanael/Images/Captures d’écran/Capture d’écran du 2026-05-05 17-12-22.png[image: 1777999357100-a9596fde-e251-4996-8fc9-3f8e208f9f01-image.jpeg]

Ok I think I have resolved the issue. It appears that if you do not activate either a paid license or the trial, it fails with the import because many of the features are not active until you enable the license and then update the XOA appliance. Once I activated the trial and then updated the appliance again, I was able to successfully import the backup. My hesitation with activating the license before importing the config as the licenses are bound and I didn't want to have to redo the setup if the config did not import. Again, it looks like I need to activate the license first and then I can import the config.

@hoerup Dang, how did I miss that. Thanks and my apologies! Graham

@gcpeters4 said: @john.c This is a good idea as well. If the previous suggestion of trying to do a DNS round robin approach doesn't work, this may be my best option. Thanks for taking the time to provide your suggestion! By the way my suggestion is recommended best practice from Microsoft for their Active Directory software and/or technology. My suggestion will be more likely to work if your DNS servers and requests have issues with Round Robin configuration. Plus with my solution you can easily add more servers as domain controllers to the cluster, as required and use replication to keep them consistent and up to date.

@florent OK cool, thank you for the info.

@jvanabra "merge synchronously" option is there for log purpose. When you click on your backup job you can get all logs from this job here: [image: 1777971428328-78941893-5585-486a-b9bc-7d4c59873aa6-image.jpeg]

I solved the problem by installing and setting up a new Ubuntu Server. I exported the XO configuration from the old server and imported it onto the new one. What can I say—the backup started working again right away.

@julienXOvates Got it. I didn't get a chance to work on this over the weekend, so sometime this week, I'll just bounce the host and see if it comes back. Right now, while I can SSH into it, the admin console appears to be frozen and unresponsive (over iLO).