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.

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

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

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

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

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

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

Whoo this looks very nice! Thank you for sharing this tool with us!

The release v0.35.0 improves the logging of both the Xen Orchestra golang SDK and the Terraform Provider.

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

Terraform Provider - Release 0.35.1

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

Release v2.2.0

This new version introduces a new field, 'memory_min', for the VM resource and makes a slight change to the 'memory_max' field, which now sets both the dynamic and static maximum memory limits and providing better control of VM memory.

What's Changed

• feat: Update TF provider to get VM memory improvements by @gCyrille in https://github.com/vatesfr/pulumi-xenorchestra/pull/420

Full Changelog: https://github.com/vatesfr/pulumi-xenorchestra/compare/v2.1.0...v2.2.0

• JavaScript/TypeScript: @vates/pulumi-xenorchestra
• Python: pulumi-xenorchestra
• Go: github.com/vatesfr/pulumi-xenorchestra/sdk
• .NET: Pulumi.Xenorchestra

gCyrille opened this pull request in vatesfr/pulumi-xenorchestra

closed feat: Update TF provider to get VM memory improvements #420

New releases for Terraform and Pulumi providers!

This new version introduces a new field, memory_min, for the VM resource and makes a slight change to the memory_max field, which now sets both the dynamic and static maximum memory limits and providing better control of VM memory.

Pulumi Provider v2.2.0
Terraform Provider v0.33.0
Xen Orchestra Go SDK v1.4.0

Pulumi Xen Orchestra Provider - Pre-Release v2.2.0-alpha.1

This is the pre-release version, which includes the changes to the memory_max field and adds the new memory_min field.

https://github.com/vatesfr/pulumi-xenorchestra/releases/tag/v2.2.0-alpha.1

@bufanda said in DevOps Megathread: what you need and how we can help!:

@sid I made that request a while ago, and tried to look into myself too, but the current API of XenOrchestra just doesn't support it, there are many pieces missing from what I could see. I hope with XenOrchestra 6 the API wil support it though.

That's the point. We started working on it, but it wasn't possible to implement the required functionality in the TF provider using the current JRPC API. We are working with the XO team to provide feedback to make it happen with the REST API. I hope the backup resource will be available with XO6

NB: If you want to take a look, there are branches on the GitHub repository. These are for both the provider and the Golang client.

Hi @afk!
We are working on a new version of the Xen Orchestra Terraform provider to improve VM memory control.

In this new version, the memory_max setting will now set the maximum limits for both the dynamic and static memory.

There is also an optional new setting called 'memory_min', which can be used to set the minimum limit for dynamic VM memory.
This version will also resolve the issue with template memory limits used during VM creation.

Can you test this pre-release version and provide us with some feedback? Or maybe just tell us if this new behaviour is more likely to meet your needs?

https://github.com/vatesfr/terraform-provider-xenorchestra/releases/tag/v0.33.0-alpha.1

I will try asap to do a pre-release version for the Pulumi provider.

Hi, thank you for the example! We will take a look. It could be a good idea to have a dedicated documentation/web page with usage examples of 'DevOps' tools

@deefdragon can you check if /sys/hypervisor/uuid matches your VMs UUID?

Hi,
Do you know what causes the system UUID to change and not match the VM UUID?

In the tests I have run (with Debian and Microk8s), it never changed.