@poddingue This can be handled quite cleanly by including a simple up to date package inventory (via dpkg -l) for the XVA, saved as a JSON file, along with a "built-on" date within the download portal to accompany the standard checksum. Can this please be developed and implemented on the download portal where we grab the XVA, and/or where the Security Advisories are held? Providing this metadata upfront would solve a major visibility gap for two critical reasons: Pre-Boot Compliance & SBOMs: Many enterprise security teams require an asset and package review before an image is ever imported or booted in a production cluster. Having a verifiable JSON manifest alongside the download allows admins to satisfy compliance and Software Bill of Materials (SBOM) requirements without forcing a "blind" deployment. First-Boot Vulnerability Window: Because the XVA acts as a snapshot frozen in time until it hooks into the Vates update servers and Debian repos, it inherently contains a window of unpatched packages upon its very first boot. A build date and package list give engineers immediate clarity on what baseline versions (like OpenSSH or the kernel) are active during that initial setup window. This wouldn't require changing how the appliance itself updates, but it would provide immense public clarity and enterprise readiness for the deployment process.

Hello, We have received your request and thank you for the feedback on this matter. A task card has been created and assigned to one of our teams. It has not yet been assigned to a specific developer, but we will be sure to get back to you once it has been addressed and resolved.

@timemaster5 @dustyarmstrong I published a thread with packages to test, if you have a non production host on which you can test it would be awesome: https://xcp-ng.org/forum/topic/12523/igpu-pci-passthrough-new-experimental-packages-need-testers Thanks! Regards, Yann

@steff22 Good news! And thanks a lot for the test! Could you share the guest VM dmesg please? as well as the lspci -n -vvv -s SBDF of the GPU? Also, was it working with the stock xcp-ng packages?

Glad the ticket sorted it, @jacob.becker, and thanks for coming back to say so. I don't know whether a patch for the stable channel is planned before 6.9 moves there. If someone else on stable lands here with the same Body Timeout Error, opening a ticket like you did seems to be the quickest route for now.

@hrvojer I can't tell for sure without detailed troubleshooting, but your crash reminds me of a bug in XenVbd that was fixed in the XCP-ng 9.1.200 tools (Apr 2026). It's unlikely that updating to an old Xen tools version would help in that case.

If a mount uses the hard mount option, it will lock any process touching it, including unmount during shutdown, if the mount source is unavailable. It is a kernel thing and I believe there is no solution for it at present.

@bug-meister Yeah, I would say the "mechanism" is deprecated too. Getting this mechanism to work, either by using ansible-pull or by some clever scripting during the first boot, requires Ansible to be preinstalled on your VM templates. That just makes your VMs messy and bloated with additional stuff you only use once. Also, managing Ansible versions becomes more complex. If Ansible is installed from distro repositories, you will have all different versions of Ansible across different distros. If you use pip to install Ansible, it can mess up your system if Ansible dependencies are installed on a system level. You can use Python virtual environments to prevent that but requires additional managing. It's much better and much more practical to have Ansible installed and used from a single place - Control Node. That way you have one place, one OS, one Ansible version to think about. You already have a machine you are accessing your VMs from? Use that as a control node... unless it is Windows?

@acebmxer I would have said the logs depend on how you deployed XO. Basically it would be an error printed when you ran yarn start. But it depends if XO is started with systemd or something else. But as you found yourself the solution... this is not needed anymore for now. I'll see if we can report an helpful message in XO. Something like "Cannot reach docker.sock. As you're running a RedHat like distro, ensure SELinux rules let sshd reach it. See this link for more... Etc."

@john.c @poddingue I am very happy to report that I am no longer receiving the "XOA Unable to connect xo server every 30s" message on the Chrome browser of my Windows 11 PC, as of today, after updating the XO-CE VM and all xcp-ng hosts. I just updated the XO-CE VM to master, commit 70b08, and ran a rolling pool update of my 3 xcp-ng hosts. Thank you to the Vates team.

@acebmxer that is awesome work! Looking forqard to duplicating your effort on Monday. Have an aqesome weekend!

Update - changes are live in the dev branch now. So figured out the update / switching branches for the proxy by connecting the proxy to my xoa free account. That triggered the available update to next version. From there I found the command that needs to be ran on the proxy to switch back and forth... [image: Screenshot_20261009_143546.png] Latest branch [image: Screenshot_20261009_144414.png] stable branch [image: Screenshot_20261008_202716.png] Backup job ran sucessful. 2026-10-09T17_48_25.447Z - backup NG.txt After the proxy has been deployed... The proxy has been registered with your Xen Orchestra instance. You can manage it from the Xen Orchestra web interface. Next: register the proxy's updater and move it to the 'latest' channel. On the pool master (IP), set a password for the proxy's 'xoa' user (choose your own) and reboot the proxy VM: xe vm-param-set uuid=UUID xenstore-data:vm-data/system-account-xoa-password='<your password>' xe vm-reboot uuid=UUID SSH to the proxy as 'xoa' (IP) and run: sudo xoa-updater register - This registers it with your vates account. sudo xoa-updater configure-channel xo-proxy-appliance-latest - set to latest or stable sudo xoa-updater upgrade - This can be ran via the UI or this command. Both need to be done twice to do the upgrade and/or downgrade. register needs a free xen-orchestra.com account; see the README. And host connected via proxy. [image: Screenshot_20261009_150011.png]

Thanks for coming back with that. Commit 8c2f3 is PR #10518 (https://github.com/vatesfr/xen-orchestra/pull/10518), and the changelog lists it under XO 6.9.1 from 5 October, so XOA users get it with 6.9.1, on the latest channel for now if I read the release channels right.

The docs have a section for this symptom, Windows Server 2025 hanging at 0% CPU: https://docs.xcp-ng.org/troubleshooting/windows-pv-tools#windows-server-2025-hangs-randomly-with-0-cpu . Besides the Viridian flags you've already set, it says to revert useplatformclock and useplatformtick with bcdedit if they were ever set in the guest. Your earlier thread showed a VM created from the "Other install media" template, so it's worth checking which template this one came from, since the Windows templates bring their own Viridian settings. I don't think the QEMU SIGTERM is the cause, though: when I force-shut down a VM on a lab host, qemu-dm logged that exact terminating on signal 15 line, sent by xenopsd-xc (ps -o comm -p 1526469 will tell you on yours), so yours most likely just matches your forced shutdown around 10:20 on 5 Oct. If it freezes again after that, the memory dump procedure further down the same page (https://docs.xcp-ng.org/troubleshooting/windows-pv-tools#how-to-gather-kernel-memory-dumps-for-in-depth-troubleshooting) is likely what people who know Windows guests better than me would want to see.

@yannsionneau Hi, I really appreciate the effort, but unfortunately I had to migrate to another hypervisor on this server and it's already away and running. However, when I get a new one I will make sure to test this and report back. Thanks anyway.

@jp13232 @peek have you tried following this: https://docs.xcp-ng.org/compute/#pci-passthrough ? Also, you can have a look there: https://xcp-ng.org/forum/topic/12523/igpu-pci-passthrough-new-experimental-packages-need-testers if you finally manage to do the passthrough but have "vbios issues" like explained in the thread.

@the_spice @bullerwins @xerxist @hawkpro @vhaelan @ovicz Hi I published a post this morning with packages to test iGPU passthrough, if you have a non production host on which you can test it would be awesome: https://xcp-ng.org/forum/topic/12523/igpu-pci-passthrough-new-experimental-packages-need-testers Thanks! Regards, Yann

@mgr42 Hi I published a post this morning with packages to test, if you have a non production host on which you can test it would be awesome: https://xcp-ng.org/forum/topic/12523/igpu-pci-passthrough-new-experimental-packages-need-testers Thanks! Regards, Yann