@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: https://github.com/vatesfr/terraform-provider-xenorchestra/releases/tag/v0.37.0
Fix for VM creation from templates with >=3 disks
@ferrao Hey thanks, yes you are welcome to send a PR to improve the docs. It is based on Docusaurus, it is in the docs directory in https://github.com/vatesfr/xen-orchestra/tree/master/docs. Then pages are in the 2nd level docs directory.
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.
@bvitnik As Olivier said, it's more of a design decision than a technical requirement. The idea behind using XO is to have a single point of entry, regardless of the number of pools, etc.
For example, this allows the mapping of Kubernetes regions to Xen Orchestra pools and Kubernetes zones to Xen Orchestra hosts with a single entry point and credentials.
We are pleased to announce the development of a CSI driver for Xen Orchestra 
It is currently under active development, but it's already available for testing with static volume provisioning only (i.e. use an existing VDI with its UUID).
