New release !

nathanael-h

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

nathanael-h

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

nathanael-h

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

nathanael-h

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

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

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

Cyrille

New release !

Cloud Controller Manager v1.2.0

https://github.com/vatesfr/xenorchestra-cloud-controller-manager/releases/tag/v1.2.0

Adds a new cloud-node-out-of-service controller that applies the node.kubernetes.io/out-of-service=nodeshutdown:NoExecute taint to the nodes whose Xen Orchestra VM is halted or has been deleted. More about this feature in the documentation or #90

nathanael-h

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.

Cyrille

@koushik you have to use the Helm controller addons for RKE2 to deploy autmatically the Helm chart for the Xen Orchestra CCM with the field spec.bootstrap set to true:

Field              | Default	| Description
--------------------------------------------------
`spec.bootstrap`   | `false`    | Set to True if this chart is needed to bootstrap the cluster (Cloud Controller Manager, etc)

EDIT: I wrote a wiki page with what I've tested https://github.com/vatesfr/xenorchestra-cloud-controller-manager/wiki/Rancher-RKE2

Cyrille

Hi @koushik,
Having read the RKE2 documentation, I understand that the only difference between the embedded CCM and the Xo CCM is that the latter does not have the ServiceLB LoadBalancer controller. The Xo CCM does everything else that the embedded CCM does (e.g. clearing the uninitilazed taint and setting the node IP) + it set the right providerID.

Disabling the embedded CCM will "only" result in the loss of the load balancer.

I would suggest disabling the RKE2 embedded CCM in order to use the Xo CCM as an external Cloud Controller Manager, as described in the RKE2 documentation. You need also to edit the kubelet configuration and set --kubelet-arg=cloud-provider=external.

You could then use another service to run the load balancer.

Cyrille

@koushik a dit:

Is there any flag or configuration in the CSI driver to completely bypass the strict CCM/Topology validation logic for non-native cloud setups, or do we have to wait for an update that allows an option like is-the-ccm-mandatory=false?

The CSI is designed to run with the Xen Orchestra provider ID because it enables the CSI node server to identify the VM on which it is running. This also means that the node server itself has no access to the Xen Orchestra API; only the CSI controller server has access.

There are no plans to remove this dependency in the next release. Sorry about your issue, we will investigate and see what we can do about that.

Team - DevOps

Posts

New release !

Cloud Controller Manager v1.2.0

Member List