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

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

CSI v1.0.0-rc.1

This is the first release candidate for v1.0.0. We're looking for feedback and real-world testing before the final release.

What's new:

• Split controller/node modes — nodes no longer hold Xen Orchestra credentials
• SR selection & live volume migration via VolumeAttributesClass
• A proper XO client timeout flag
• A brand-new Helm chart, with component toggles and provisioning tests

https://github.com/vatesfr/xenorchestra-csi-driver/releases/tag/v1.0.0-rc.1

CCM v1.1.2

The Helm chart can now be configured to disable Role and RoleBinding creation, making it easier to integrate into environments where RBAC resources are managed separately.

We've also bumped dependencies, including CI tooling and go-xo-sdk.

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

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.

Terraform Provider Xen Orchestra v0.40.0

This new release allows users to import VMs directly from Xen Orchestra into Terraform without recreating it or modifying manually the Terraform state.

There is still some drift when importing it, but nothing that changes the real state of VM and we are currently on it!

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

Golang SDK for Xen Orchestra v1.17.0

v2

The network service is now available from the v2 client!

You can now create, get and delete your network directly from it!

v1 & v2

The template value in VM struct params has been fixed, We can now get the template id directly from it.

https://github.com/vatesfr/xenorchestra-go-sdk/releases/tag/v1.17.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

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

I just wanted to say a big thank you for the MCP support that’s now landing in Xen Orchestra. This is definitely a genuinely forward-thinking move, and it’s going to have a huge impact on how IaC tooling interacts with XCP-ng going forward.

MCP gives XO a clean, structured, read-only interface that modern AI-assisted tools (e.g Pulumi Neo, Copilot, Claude, Cursor, etc.) can understand natively. That’s a massive step toward making XCP-ng an AI-visible, AI-navigable platform - something no other virtualisation stack is doing yet.

What’s even more exciting is the long-term implication: this kind of openness and clarity is exactly what hyperscalers have been struggling with internally. If Vates continues down this path, it’s not unrealistic that MCP-native infrastructure could start attracting interest from much larger players - whether as customers, collaborators, or contributors.

The combination of:

• IaC
• MCP
• AI-assisted operations
• and XCP-ng’s open architecture

Puts Vates in a very strong position for the future.

Thanks again for pushing this forward. It’s a big deal, and it’s going to unlock a lot of possibilities for the community.

• Pulumi
• MariaDB

Anyway I would really appreciate having an MCP Server which, can be used when writing IaC to provision and configure your customers’ systems. Can it be made available during this year please?

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

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.

Yes there is a provider for it: https://www.pulumi.com/registry/packages/talos/

I guess its the auto-generated provider from the terraform one because I had some type checking errors in some places, but using python I could ignore that... I don't know if it has been fixed since.
I remember reading some terraform examples on blogs to write the pulumi config so converting one to the other should be straightforward. Unfortunately, I can't publish what I wrote because its quite messy but feel free to ask if you have some blockers.

The CCM would be nice to have indeed ! Good luck on that.

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

Nice ! Thank you for this.

Fwiw, I started to work on a PoC deployment of a talos cluster this summer and managed to do the full process with pulumi. I'll probably migrate to opentofu when I have everything setup as I want to clean things up.

The whole install and k8s bootstrap takes 2-3 minutes to deploy a 3 nodes control plane and 3 workers from start to finish. You even get the machine configs, kubeconfig and talosconfig as outputs. Then, I deployed fluxcd manually but you could even automate that in the deployment.

Overall, its really impressive and quite easy once you understand the way talos works. Highly recommended !

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

• Enables the secure boot parameter for the VM resource

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

Prioritization of VM startup AND shutdown sequencing! PLEASE - in the GUI (XO). So - without code - I can finally shutdown my servers accessing DB's prior to shutting down the DB server vm's themselves thereby saving myself from table corruption.

@cichy In the past it was recommended to do this with an vApp and script. However this means editing the script or configuration file (if one’s created for the script). Which doesn’t make it as easy as the method, used by VMware ESXi for configuring the order and enabling the capacity.

Xen Orchestra and/or XCP-ng could really do with an UI (and API) based method of setting up and managing the VM boot and shutdown order.

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

• Read and expose boot_firmware on template data-source by @sakaru in #381
• Fixes VM creation from multi-disks template:
  • All existing disks in the template are used if they are declared in the plan.
  • All unused disks in the template are deleted to avoid inconsistency between the plan and the actual state.
  • It is no longer possible to resize existing template disks to a smaller size (fixes potential source of data loss).
  • Order of existing disk matches the declaration order in the plan

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

Pulumi provider release: https://github.com/vatesfr/pulumi-xenorchestra/releases/tag/v2.3.0

Now it should be easier to read the log using TF_LOG_PROVIDER=DEBUG (see the provider documentation)

The new version fixes bugs when creating a VM from a template #361:

• All existing disks in the template are used if they are declared in the TF plan.
• All unused disks in the template are deleted to avoid inconsistency between the TF plan and the actual state.
• It is no longer possible to resize existing template disks to a smaller size (fixes potential source of data loss).

The release: https://github.com/vatesfr/terraform-provider-xenorchestra/releases/tag/v0.35.1