Terraform provider release v0.36.1

Cyrille

Terraform provider release v0.36.1

Fix for VM creation from templates with >=3 disks

nathanael-h

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

Cyrille

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

Cyrille

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.

Cyrille

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.

Cyrille

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

Cyrille

Xen Orchestra Container Storage Interface (CSI) for Kubernetes

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

https://github.com/vatesfr/xenorchestra-csi-driver

Cyrille

@carloum70 Disk migration isn't supported by the provider yet. What you can do it's only ignore the changes to the sr_id of a given disk.

For example for the first disk:

  lifecycle {
    ignore_changes = [
      disk[0].sr_id
    ]
  }

You can also manually do the migration in XO and then after edit your HCL to update the sr_id with the new ID. It should do the trick.

Cyrille

Terraform Provider v0.36.0 and Pulumi Provider v2.3.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

Cyrille

I created a GitHub issue to track this feature request: https://github.com/vatesfr/terraform-provider-xenorchestra/issues/378

gCyrille created this issue in vatesfr/terraform-provider-xenorchestra

Team - DevOps

Posts

Terraform provider release v0.36.1

Xen Orchestra Container Storage Interface (CSI) for Kubernetes

Terraform Provider v0.36.0 and Pulumi Provider v2.3.0

open CPU topology (sockets/cores) for new VMs deployed via Terraform #378

Member List