@m4xm0rris Xen Orchestra's web application is doing this templating on the client side (reference). Since terraform already has a nice interface for templating (using its template_file data source), you can do the substitution yourself.

Here is an example below. Note: this code is not tested but was pulled from an internal project I have.

# template_file.tpl
#cloud-config

hostname: ${name}

# any other cloud-config you need
[...]

# vm.tf
data "template_file" "cloud_config" {
  template = file("${path.module}/template_file.tpl")
  vars = {
    name = "your_hostname_value"
  }
}

resource "xenorchestra_cloud_config" "cloud_config" {
  name = "cloud_config"
  # This performs the templating
  template = data.template_file.cloud_config.rendered
}

resource "xenorchestra_vm" "vm" {
  [ ... ]
  cloud_config = xenorchestra_cloud_config.cloud_config.template
  
}

Please share your terraform code if you would like more specific advice on how to recreate exactly what you are trying to do.

@ruskofd is right. You should be able to use the cloud_network_config attribute to achieve this.

The following code is untested but should launch a vm with a static IP. Please see the xenorchestra_vm resource docs and the cloud-init networking v1 docs for more details.

resource "xenorchestra_vm" "static_ip_vm" {
....
  cloud_network_config = <<EOF
network:
version: 1
config:
  - type: physical
    name: eth0
    subnets:
      - type: static
        address: STATIC_IP/24
        gateway: GATEWAY_IP
        dns_nameservers:
          - 8.8.8.8
EOF
}

Let me know if you have any questions or issues using cloud_network_config,

As for the blog post, the VM would have been assigned an ip address via dhcp (assuming the guest OS had cloud-init installed which was true for the VM template in the blog post).

@Gurve thank you for providing a full example!

@michael132 sorry I read a little too much into your initial message's "I am failing to get it to extract the metadata for a single VM".

That makes sense. The terraformer integration could help here, but as mentioned above it will require some work to integrate with the VM resource. We also would need to upgrade the terraform-provider-xenochestra dependency since it's quite old.

In order to understand how much work is needed, it would be useful to follow the terraform import process for one of these VMs and see what difficulties are surfaced through that process. The terraform import process will share the same issue(s) that terraformer will see as mentioned in my comment here.

Identifying the outstanding work would help us understand if there is more to complete outside of terraform-provider-xenorchestra#100 and the terraformer glue work itself.

@dan89 yep, I'm the right person for terraform-provider-xenorchestra features or issues

There aren't any settings to accomplish what you are trying to do, but I think that's feasible and would be a nice addition. The current wait_for_ip logic exits once the Xen Orchestra api returns a ip address field. If the vm resource had additional information, say expected_ip_cidr = 10.0.0.0/16, then the provider could continue polling until the DHCP assignment completes.

resource "xenorchestra_vm" "qa-vm1" {
    cpus = var.cpu
    memory_max = var.memMax
    name_label = var.vmDesc
    name_description = var.vmName
    hvm_boot_firmware = "uefi"
    wait_for_ip = true

    expected_ip_cidr = "10.0.0.0/16"  # wait_for_ip will continue to poll until the XO api shows that the VM has an IP in that range

}
    

Please let me know if this would satisfy your use case and I can probably investigate implementing that over the next few weeks. I'll be creating a GitHub issue for this and linking it here once it's created.

@brodiecyber no worries and I hope you are doing better and staying healthy!

Just wanted to give you an update that the terraform provider is currently testing against multiple versions of terraform (v0.14.11 and v1.6.5). The build matrix will be easy to extend to support OpenTofu testing, so we should be able to integrate that testing soon.

Hi @brodiecyber, glad to hear that Terraform has become an important part of your workflow with XO

To @olivierlambert's point, the projects needed to implement a terraform provider (terraform-plugin sdk and the terraform-plugin-framework) have not been relicensed. Unless that occurs, which I think is extremely unlikely, there will be no impact for the Xen Orchestra terraform provider. The OpenTofu team also believes that the terraform provider interface will not be changed in their FAQ:

Does OpenTofu work with all the providers Terraform works with?
OpenTofu will not have its own providers. Terraform providers have not altered their licenses, and the potential for such a change is virtually zero. OpenTofu will work with the current Terraform providers, but it will use a separate registry.

I would like to have testing coverage across OpenTofu and terraform to catch any discrepancies. There isn't a timeline for accomplishing that, but that is my current thinking.

@mlustosa apologies for the slow response on that issue. I'm hoping to around to addressing that within the next week or so and thanks for posting the workaround on the related issue.

@fred974

I just saw that terraform had a free cloud account for less that 5 users and I was thinking of registering, will it work?

Terraform cloud would work if your XO deployment was publicly accessible. I highly advise against this because if your XO deployment were compromised an attacker has access to your entire infrastructure.

If you were to do this I would make sure all of your user's have strong passwords and if Hashicorp has documented public IPs that you only open your firewall to Hashicorp's Ips. It seems from this forum post that this is only available if you on the business tier.

If I run Terraform in a VM on xcp-ng, I don't need to open any port and use Terraform localy.

Yes running it on the xcp-ng host would work, however, keeping best practices in mind I would run it on a less privileged host (laptop with vpn access, development VM). If you have others collaborating on this terraform deployment, giving access to the xcp-ng host just to use terraform seems like a heavy hammer.

Is there a simple script I can run to see if I can access the Xen Orchestra API?

nmap will be able to tell you this.

nmap -sT -P0 -p 443 xo-domain

@rochemike sorry for the late reply!

If we already have an ISO on an SR, do we even need to mount the ISO for a network build of Centos/RHEL? Isn't... shouldn't it be possible for the ISO to be mounted by the new build VM as source for creating the new VM, instead of using network build?

That is exactly what packer-plugin-xenserver#56 accomplishes.

The new VM mounts the guest tools to the DVD - which I don't even want to use as I prefer to install a package afterwards. Is it possible to mount the RHEL/Centos ISO instead?

I believe the ISO and guest tools are treated the same -- both VBDs are attached as cds. If you can identify what is different about them in the UI or from the xe cli that would help me understand what you trying to describe.

As for what is possible, if what you want to configure is accessible via the XCP-ng / Xenserver API the packer plugin could be enhanced to perform that action. Hope this helps explain more on the potential possibilities.

@Gurve thank you for providing a full example!

@michael132 here is the command you will need to run, but I recommend doing some research on this command's workflow if you aren't familiar.

# Note: you will need to have a barebones resource
# specified that matches the later `terraform import` command
$ cat main.tf

resource "xenorchestra_vm" "vm1" {

}

# See screenshot below for the uuid example.
$ terraform import xenorchestra_vm.vm1 uuid-from-xo

From researching this, it seems the new import block can also generate terraform code. It may not script as well as terraformer would, but the functionality has some overlap. This blog explained the legacy import flow and the new import block and I recommend reading it.

@michael132 sorry I read a little too much into your initial message's "I am failing to get it to extract the metadata for a single VM".

That makes sense. The terraformer integration could help here, but as mentioned above it will require some work to integrate with the VM resource. We also would need to upgrade the terraform-provider-xenochestra dependency since it's quite old.

In order to understand how much work is needed, it would be useful to follow the terraform import process for one of these VMs and see what difficulties are surfaced through that process. The terraform import process will share the same issue(s) that terraformer will see as mentioned in my comment here.

Identifying the outstanding work would help us understand if there is more to complete outside of terraform-provider-xenorchestra#100 and the terraformer glue work itself.

Hey @michael132, apologies for the late reply.

The GitHub issue (vatesfr/terraform-provider-xenorchestra#96) tracking its initial implementation has some additional details and why the VM resource was not done initially (there's outstanding work to make the experience seamless). Since it was initially developed, I haven't received any feedback on the integration so I wasn't sure if it was worthwhile to maintain it.

If you are working with a single VM, have you tried terraform import? From my own personal terraformer use, I'm mainly found it valuable once you are trying to export a significant number of resources.

@dan89 this is complete and available in v0.29.0 of the provider.

@dan89 this is enough to work off and I appreciate your review. Here is the GitHub issue where I'll be tracking the implementation (vatesfr/terraform-provider-xenorchestra#300).

@dan89 yep, I'm the right person for terraform-provider-xenorchestra features or issues

There aren't any settings to accomplish what you are trying to do, but I think that's feasible and would be a nice addition. The current wait_for_ip logic exits once the Xen Orchestra api returns a ip address field. If the vm resource had additional information, say expected_ip_cidr = 10.0.0.0/16, then the provider could continue polling until the DHCP assignment completes.

resource "xenorchestra_vm" "qa-vm1" {
    cpus = var.cpu
    memory_max = var.memMax
    name_label = var.vmDesc
    name_description = var.vmName
    hvm_boot_firmware = "uefi"
    wait_for_ip = true

    expected_ip_cidr = "10.0.0.0/16"  # wait_for_ip will continue to poll until the XO api shows that the VM has an IP in that range

}
    

Please let me know if this would satisfy your use case and I can probably investigate implementing that over the next few weeks. I'll be creating a GitHub issue for this and linking it here once it's created.

@brodiecyber no worries and I hope you are doing better and staying healthy!

Just wanted to give you an update that the terraform provider is currently testing against multiple versions of terraform (v0.14.11 and v1.6.5). The build matrix will be easy to extend to support OpenTofu testing, so we should be able to integrate that testing soon.

@twaapo are you able to share the full error of your terraform apply command? In addition to that it would be helpful to see the TF_LOG=DEBUG terraform apply output as well.

Please be aware that you might need to sanitize the output.

Hi @brodiecyber, glad to hear that Terraform has become an important part of your workflow with XO

To @olivierlambert's point, the projects needed to implement a terraform provider (terraform-plugin sdk and the terraform-plugin-framework) have not been relicensed. Unless that occurs, which I think is extremely unlikely, there will be no impact for the Xen Orchestra terraform provider. The OpenTofu team also believes that the terraform provider interface will not be changed in their FAQ:

Does OpenTofu work with all the providers Terraform works with?
OpenTofu will not have its own providers. Terraform providers have not altered their licenses, and the potential for such a change is virtually zero. OpenTofu will work with the current Terraform providers, but it will use a separate registry.

I would like to have testing coverage across OpenTofu and terraform to catch any discrepancies. There isn't a timeline for accomplishing that, but that is my current thinking.