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

@hrvojer There are many bugs in older versions of the Xen PV drivers. I suggest running Windows without guest tools and drivers if you can take the performance and functionality hit (no suspend/migration on UEFI VMs, no metric reporting, etc).

Hi! We recieved a fix via the support after opening a ticket as suggested. Now the pool metadata backup is running smoothly again. As far as i know 6.9 will become "stable" after 6.10 is released. I'd still suggest a patch for the stable version, unless the new release is a few days. Best wishes Jacob

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

Hello, I talked with colleagues, and the idea of sharing the docker socket from a VM to the XO VM would not be doable in the near future on XCP-ng 8.3 (ask @teddyastie if you want details, I remember only the conclusion ) So I took a shortcut - XO <--> Docker - and pushed a quick experimental branch on github, docker-experimental, https://github.com/vatesfr/xen-orchestra/tree/docker-experimental Warning, this is experimental. ( NOT PRODUCTION ready ) Key points: A container tab on each VM XO can connect to the VM via SSH, and reach the docker.sock SSH private key and passphrase are stored by XO in the same way as XCP-ng hosts credentials XO6 web UI and REST API No modification needed in XCP-ng dom0 No modification needed in the VMs with Docker Any docker root or rootless is expected to work (I didn't test rootless yet) It should also work with a Podman socket (I didn't test yet) Again, it is experimental DO NOT RUN IN PRODUCTION Here are a few screenshots: Containers tab when connected to the docker socket /home/nathanael/src/xen-orchestra/docker-prs/proof/6/shots-real/01-connected.png[image: 01-connected.jpeg] Same with side panel /home/nathanael/src/xen-orchestra/docker-prs/proof/6/shots-real/02-side-panel-logs.png[image: 02-side-panel-logs.jpeg] Actions possible, stop/start, pause, restart, delete container: /home/nathanael/src/xen-orchestra/docker-prs/proof/6/shots-real/03-actions-menu.png[image: 03-actions-menu.jpeg] Containers tab when no yet connected, with a form to fill: /home/nathanael/src/xen-orchestra/docker-prs/proof/6/shots-real/06-not-configured.png[image: 06-not-configured.jpeg] To use this, follow official installation from sources but use this experimental branch instead of master. Again, this is still experimental, comes with no official support. We'd be interested to here what you think of this

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.

I tried this on my lab (with XO 6.9.1), moving the pool master to the other host with xe pool-designate-new-master and then back. XO stayed connected both times and picked up the new master, even though Settings > Servers still showed the old host's address; on the way back it took a minute or two to catch up. I didn't test 6.2.2, and I used the CLI rather than the XO 5 Advanced tab, so my guess that your older version is the difference is only a guess. For the XVA, I'm not aware of release notes for the appliance image itself: it updates itself after import, and the notes that exist are per XO version, in the monthly blog post and the changelog, both linked from https://docs.xen-orchestra.com/getting-started/releases#release-cadence-and-channels . How often the downloadable XVA gets rebuilt I don't know, so the 2025.12 tag may just be the date of the base image, but I'd rather ask than guess.

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.