During a RPU, I need to have at least 2 non-paused CP VMs running or else the environment goes belly up.

This is a very good question about RPU and custom behavior for specific VMs. ping @julienXOvates

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

Hello there,

I posted in another thread an experimental Docker containers integration, not for production, but good enough to test it, see

https://xcp-ng.org/forum/topic/12423/bringing-container-visibility-back-to-xo/9?_=1791618850567

@acebmxer Thanks for your very quick feedback, even more with screenshot for the VM where the connection to the docker socket did not worked, are you sure the public ssh key corresponding to the private ssh key filled in the form is correctly deployed in the VM, to the corresponding ssh user? Do you have any logs from xo-server?

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

Same with side panel

Actions possible, stop/start, pause, restart, delete container:

Containers tab when no yet connected, with a form to fill:

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

Hello there,
Thanks a lot for raising the question and offering ideas to move forward @caps ! I would like to say that I really like the AI crafted screenshot provided 🤩

But, to be clear, the status as of today regarding Docker or other containers integration in XO/XCP-ng is that there is an item in the DevOps Tools team roadmap. The item is just to look and define what could be done (example update xscontainer, do something totally new, ...). Unfortunately this spike has a low priority and is not yet scheduled.

That being said, there is an active project, which is close to what you're asking. It's about a better integration of Kubernetes, including, cluster update, adding nodes, etc. More on this should come in the next months! ️

Also note that I am chatting with different people and teams in Vates about this thread and the Docker integration topic to see if we could do something.

Also last thing is that, the community is always welcome to build on top of our open source softwares. I am pretty sure that if someone would contribute a Xen Orchestra plugin to integrate Docker we would welcome this, and we could give tips and guidance. Like @teddyastie said, I'm not sure having Docker, Podman, related features in the guest agent would be something our colleagues would merge. But maybe the docker daemon socket could be kind of shared between VMs (I'm not sure at all this is possible and if possible how to do it). In the meantime exposing the docker daemon over network (with restrictions) to Xen Orchestra would be quick'n easy and I think safe enough if done carefully.

Bonjour @bvivi57 merci pour le partage, le tuto est très détaillé, et me semble bien juste, bravo !

Hâte de voir la suite, mais aussi j'ai très envie de te proposer de tester la Kubernetes Cluster API pour Xen Orchestra, https://github.com/vatesfr/cluster-api-provider-vates/ c'est tout neuf, mais ça devrait t'aider à créer des clusters Kubernetes, et au-delà à les gérer (mise à jour, ajout/suppression de node, etc.) ping @devops

@pszelestey Hi, yes, we've pushed an initial commit and a few more here https://github.com/vatesfr/cluster-api-provider-vates/ it is moging every day. Ping us in Matrix/Discord devops if you want to chat live while trying

@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

@ThasianXi Hello, thanks for the report. It looks like the pull image step fails. Can you test that the token generated from Github is working and allows to pull the image.

Maybe a simple test on a docker install could ease the verification:

docker login ghcr.io -u USERNAME -p TOKEN
docker pull ghcr.io/vatesfr/xenorchestra-csi:v0.0.1

Also note that only "Classic" persona access token are supported.

More doc here https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-container-registry#authenticating-with-a-personal-access-token-classic