@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

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.

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

@koushik
I don't kown RKE2. Is it its own CCM which set the node providerID?

Regarding the CSI, it needs the labels set by the CCM to know the pool topology. Try to enable only the cloud-node-label-sync in the CCM:

--controllers=cloud-node-label-sync

I'm not sure if that's enough. Maybe you'll have an issue with the provider ID, too

Hi @robfox2, a release candidate version is about to be published. After that, we will wait for feedback before releasing a stable version.
Keep an eye out for the release blog post on https://xen-orchestra.com/blog/tag/release/

Terraform provider v0.41.0

New release of the Terraform provider for Xen Orchestra : a new xenorchestra_srs data source, a share option on
xenorchestra_vm to grant team access declaratively, and host_id filtering on xenorchestra_sr. Full release note here.

Xen Orchestra Golang SDK v1.19.0

Add share flag for VMs in the v1 SDK and other dependencies bumps. Release note.

Kubernetes CSI Driver for XO new release v0.3.0

• Stable CSI Volume Identity: This decouples Kubernetes volume identity from backend storage lifecycle events (e.g. VDI migration between Storage Repositories)
• Topology-Aware Volume Provisioning: Dynamic provisioning now supports topology-aware pool selection.

️ Migration required from v0.2.0 to v0.3.0

Full release note: https://github.com/vatesfr/xenorchestra-csi-driver/releases/tag/v0.3.0

Xen Orchestra Kubernetes Storage Driver new release v0.2.0

Introducing dynamic provisioning

The latest CSI driver release introduces dynamic provisioning: by creating a Kubernetes storage class that references the XO CSI driver and sets the poolId parameter, you can then create a PVC and pod using that storage class, and Xen Orchestra will automatically provision new VDIs into the default SR of the chosen pool, to satisfy the requested volumes.

Your feedback on the CSI driver is welcome! Which features would you like to see? How would you like to use the driver and storage classes?

https://github.com/vatesfr/xenorchestra-csi-driver/releases/tag/v0.2.0

Hi,

Thank you for the feedback

There was an error in the Makefile used to build the Docker image for the CSI. The name was incorrect... The fix that we pushed a month ago didn't trigger the CI

I manually ran the CI to rebuild the edge image with the correct name, which is now available at ghcr.io/vatesfr/xenorchestra-csi-driver:edge

I delete the wrong one (ghcr.io/vatesfr/xenorchestra-csi:edge).

@ThasianXi Thank you for your feedback !

Kubernetes CCM for Xen Orchestra v1.0.0-rc.1

We’re shipping v1.0.0-rc.1, our first release candidate on the road to a stable 1.0.0! This RC is feature-complete and ready for real-world use.

Please try it out and share any feedback—bugs, regressions, or usability notes—so we can polish the final release. Thank you for testing and helping us!

https://github.com/vatesfr/xenorchestra-cloud-controller-manager/releases/tag/v1.0.0-rc.1

Golang SDK for Xen Orchestra v1.11.0

SDK v2:

• VM and Task services now match the latest REST API.
• Host service has been added for host data retrieval.
• Integration tests have also been strengthened to boost reliability.

The v2 SDK is gradually becoming our main library for all the other DevOps tools (Kubernetes drivers, Terraform provider…).

There are BREAKING CAHNGES in the v2 SDK, so please read the release notes carefully.
Remember that the v2 SDK is a beta version and can be subject to significant changes. The current semantic versioning we use is mostly for the v1 SDK. When the v2 SDK becomes stable, the major version number will increase.

https://github.com/vatesfr/xenorchestra-go-sdk/releases/tag/v1.11.0

Hi @jacob.becker,
We identified the issue last weekend, and we're currently working on a solution. We plan to include a fix in the next XO release.

XO CCM v0.2.0

This update make it working with Talos.

What's Changed

• Feat: record event when region zone changed
• Refactor: make xoClient and xoConfig available outside package scope (to be used by the CSI)
• Workaround for the SystemUUID sometimes in little-endian

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

Terraform Provider v0.37.2

What's Changed

• Fix xenorchestra_vdi data source: you can now filter VDI/ISO with the same name label using tags.

https://github.com/vatesfr/terraform-provider-xenorchestra/releases/tag/v0.37.2

@afk Nice! I haven't tried Pulumi yet. Does Talos have a provider for it?

I'm working on improving the CCM to make it work with Talos. Especially the cloud-node-label-sync controller (as the cloud-controller is the Talos one) to get the XO topology in the node labels.

Hi here,

We have released documentation with our recommendations for those who want to run Talos in Xen Orchestra.

It is available in the official Sidero Labs documentation: Platform specific installation > Virtualized Platforms > Xen Orchestra

We are currently working on providing an example of a Talos cluster that has been created using Terraform.

Have fun

Terraform provider release v0.37.0

• Enables the secure boot parameter for the VM resource

Terraform provider release: https://github.com/vatesfr/terraform-provider-xenorchestra/releases/tag/v0.37.0

Terraform provider release v0.36.1

Fix for VM creation from templates with >=3 disks

• https://github.com/vatesfr/terraform-provider-xenorchestra/releases/tag/v0.36.1
• related sdk release: https://github.com/vatesfr/xenorchestra-go-sdk/releases/tag/v1.8.0

Can you share how you created the template?
And copy here the template object from xo-cli or the rest api: xo-cli list-objects type=VM-template id=<your_template_id>?

Hi @carloum70

I'm back now — sorry for the delay.
If I understand correctly, this issue only occurs with a template created from a Debian 13 cloud-init raw file, is that right? I'm trying to understand how to reproduce the issue, as I've never seen it before.

Actually, it's not a closed door; it's more a door that is opening for people who are already using both Xen Orchestra and Kubernetes.

From a technical point of view, it makes more sense for us to use XO, because its API is easier to use, especially with the new REST API. For the application side itself, it does many thing that we don't have to deal with. For VDIs, perhaps it's not so much. But for other things such as backups, live migrations, templates and VM creation... it's easier. Moreover, using a unique SDK to develop tools makes sense for our small DevOps team in terms of development speed, stability and security.