administrators group | XCP-ng and XO forum

nathanael-h

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

Same with side panel
/home/nathanael/src/xen-orchestra/docker-prs/proof/6/shots-real/02-side-panel-logs.png

Actions possible, stop/start, pause, restart, delete container:
/home/nathanael/src/xen-orchestra/docker-prs/proof/6/shots-real/03-actions-menu.png

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

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

poddingue

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.

poddingue

The 6.9 release post has it as "Fixed: BodyTimeoutError during long transfers" (https://xen-orchestra.com/blog/xen-orchestra-6-9/), thanks @john.c.
It's in the changelog too, I just didn't recognise it: 6.9.0 lists PR #10282 as the fix for assert(!this.paused), and that PR is the undici update behind the BodyTimeoutError fix.

@jacob.becker it's only on the latest channel for now, and I'd go straight to 6.9.1, which fixes servers stuck in Connecting behind an HTTP/2 proxy (#10507), a side effect of that same update. The post talks about backup jobs in general and I'm not sure it covers the metadata job the same way, so it'd be great to hear whether it still times out after the update.

poddingue

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.

poddingue

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.

administrators

Posts

Member List