@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

After applying latest updates and commits, to both xcp and XO. The zeroes were still non-collapsed. However. Rebooting the VM resulted in the zeroes now collapse properly as expected. I had previously rebooted the VM, so I don't believe that was the solution. But I did not check inbetween pulling latest source, and updating XCP. So I'm unsure which update solved it. But this then has been resolved.

Mixing Intel and AMD is more than losing feature, it's a recipe for crashing your VMs every time you do a live migration.

@olivierlambert said: Might be interesting to test a different cluster size and see the impact I tested it with a cluster size of 2 megabytes, and nothing changed [image: 1778012606947-qcow2-2m_bandwidth_summary.png] [image: 1778012609162-qcow2-2m_latency_summary.png]

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.

@dthenot ... The XOSTOR SR is working on the other hosts. It's only the master which updated where it fails to plug the pbd. Given that it can't mount the pbd after doing the update, I am very doubtful about updating another host. What's more, I can't without shutting down a large number of VMs or doing a long migration off the XOSTOR, because I only have N+1 redundancy on my personal cluster, and we're already one host down because the master can't rejoin the XOSTOR SR. In short, this looks like a very dangerous suggestion - sorry!

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

@florent OK cool, thank you for the info.

@tsukraw said: Hey guys, Looking for some help at understanding auto power on as the documentation possibly looks to need some refreshing. https://docs.xcp-ng.org/guides/autostart-vm/ From the Xen Orchestra, the guide does not mention the pool level it is only under the CLI that it mentions the pool level. Just looking for some clarification. In order for auto power on to function, we need to enable it on the pool level, and then per VM correct? If you have auto power on enabled at the VM level and the pool level disabled, the VM level is ignored, correct? What is actually triggering the power on? Is it XOA or the host itself? I am assuming the host itself, just looking for clarification if XOA VM was part of the systems that went offline, should we expect to see it auto power back on if it is set to auto power on. What determines the start order for auto power on when you have multiple VMs on a host? Thank you!! Yes, it needs to be enabled at pool level and at VM level. I tried once at only enabling at the VM level and it didn’t auto power on, as it wasn’t enabled at the pool level, it started auto powering on once it’s enabled at both levels. It’s configuring a XAPI value as this occurs at the Xen level (virtualisation server). Xen Orchestra is just making this value visible with a nice UI interface toggle.

@florent Just checking to make sure you got the memory dump? [image: 1778011838638-screenshot-2026-05-05-160905.png]

@florent said: ping @julienxovates I think we can change thie behavior ( accepting a xo-server start even if a zombie process is still running) Hello, Today I tried to update again with the same steps and a reboot and it still shows out of date. [image: 1778007914995-887782ff-6408-4788-a761-4d13d6b0ee95-image-resized.jpeg] I did see the new XO6 features so I assume it kind of half worked From the command line I ran git log -1 --format="%h" and still saw the old commit version of c998f though I then ran the following and got the newest 7e144 version git fetch --all git reset --hard origin/master From there I reran my yarn and yarn build commands and it's updated fully now. For some reason git pull --ff-only was not getting the full update or something.

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]

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

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