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

@Monkadelic_D thanks for that additional detail. I still feel that I'm unsure of the type of construct you are looking for. Here is an example that allows each VM to have a single private network and as many DHCP connected networks (meaning mac is provided) as needed.

# variables.tf
variable "mac_network" {
  type = string
}
# Map where key is VM hostname and value is list of MACs
variable "vm_network_macs" {
  type = map(list(string))
  default = {}
}

# terraform.tfvars
vm_network_macs = {
  "lab-vm-00" = ["0a:c3:fd:8a:6e:5b"],
  "lab-vm-01" = ["52:b2:f4:d7:d4:fe"],
  "lab-vm-02" = ["62:94:26:63:dd:a2"],
}

vm.tf
resource "xenorchestra_vm" "vm" {

  # The vm_network_macs contains a key for every VM hostname
  count = length(keys(var.vm_network_macs))
  name_label =  keys(var.vm_network_macs)[count.index]

  [ ... ]

  # This creates a network for each mac address provided
  dynamic "network" {
   for_each = lookup(var.vm_network_macs, keys(var.vm_network_macs)[count.index])
   iterator = mac_addr
   content {
    network_id = var.mac_network
    mac_address = mac_addr.value
   }
  }

  # This is the private network your VMs will be given
  network {
    network_id = data.xenorchestra_network.network.id
  }
}

Here is what the plan of that looks like:

Terraform will perform the following actions:

  # xenorchestra_vm.vm[0] will be created
  + resource "xenorchestra_vm" "vm" {

[ .. ]

      + network {
          + device         = (known after apply)
          + ipv4_addresses = (known after apply)
          + ipv6_addresses = (known after apply)
          + mac_address    = "0a:c3:fd:8a:6e:5b"
          + network_id     = "Your mac network"
        }
      + network {
          + device         = (known after apply)
          + ipv4_addresses = (known after apply)
          + ipv6_addresses = (known after apply)
          + mac_address    = (known after apply)
          + network_id     = "6c4e1cdc-9fe0-0603-e53d-4790d1fce8dd"
        }
    }

  # xenorchestra_vm.vm[1] will be created
  + resource "xenorchestra_vm" "vm" {

[ .. ]

      + network {
          + device         = (known after apply)
          + ipv4_addresses = (known after apply)
          + ipv6_addresses = (known after apply)
          + mac_address    = "52:b2:f4:d7:d4:fe"
          + network_id     = "Your mac network"
        }
      + network {
          + device         = (known after apply)
          + ipv4_addresses = (known after apply)
          + ipv6_addresses = (known after apply)
          + mac_address    = (known after apply)
          + network_id     = "6c4e1cdc-9fe0-0603-e53d-4790d1fce8dd"
        }
    }

  # xenorchestra_vm.vm[2] will be created
  + resource "xenorchestra_vm" "vm" {
 
[ ... ]

      + network {
          + device         = (known after apply)
          + ipv4_addresses = (known after apply)
          + ipv6_addresses = (known after apply)
          + mac_address    = "62:94:26:63:dd:a2"
          + network_id     = "Your mac network"
        }
      + network {
          + device         = (known after apply)
          + ipv4_addresses = (known after apply)
          + ipv6_addresses = (known after apply)
          + mac_address    = (known after apply)
          + network_id     = "6c4e1cdc-9fe0-0603-e53d-4790d1fce8dd"
        }
    }

Plan: 3 to add, 0 to change, 0 to destroy.

If that isn't what you are looking for, I hope that it helps to spark additional inspiration from what you've tried already.

@Monkadelic_D I'm still not understanding how you determine which VMs need network interfaces with one of these existing DHCP MAC assignments.

Could you provide an example that includes a DHCP server and its MAC assignments, XCP network(s), VMs and what interfaces you expect them to have?

@Monkadelic_D can you explain how these MAC addresses will be assigned? Will you have a static list of addresses per network?

If you provide an example, I can modify the example to accommodate that if I see a solution.

Hey @Monkadelic_D, this is possible with a count'ed network data source and a dynamic block for dynamically creating the xenorchestra_vm network blocks.

Here is an example that should show off what you are trying to do:

data "xenorchestra_pool" "pool" {
  name_label = "Your pool name"
}

data "xenorchestra_network" "networks" {
  count = length(var.networks)
  name_label  = element(var.networks, count.index)
  pool_id = data.xenorchestra_pool.pool.id
}

resource "xenorchestra_vm" "vm" {

  # Fill in required arguments here

  dynamic "network" {
        for_each = data.xenorchestra_network.networks[*].id
        content {
          network_id = network.value
        }
  }
}

I verified that this creates the correct plan when the networks variable is changed.

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

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

Hi @slynch, I unfortunately don't have any experience with Talos Linux. It seems like a very promising project.

Creating packer images with the xenserver packer plugin is OS dependent. The Ubuntu and CentOS examples provided in the repo use autoinstallation and kickstart respectively.

Is Talos Linux based on an existing distro that has an existing unattended / automatic install solution? I think the key to accomplishing this is using an off the shelf auto install tool or finding something that will work for Talos.

Talos's nocloud data source will likely be part of this solution, however, for the existing examples it's just a means for configuring the auto install tool for the target distro.

There are two platforms they support that they document using Packer - Hetzner and Upcloud - but I can't figure out how to use that knowledge to get this to work with packer-plugin-xenserver.

While I'm not familiar with the the Hetzner and Upcloud packer plugins, it seems there "examples" are essentially booting a VM and then dd'ing the raw.xz file over top of a disk device. So unfortunately I don't think those examples will be useful for implementing this with the xenserver packer plugin.

@sMteX sorry for the late reply. I responded to your GitHub issue with some questions and comments.

Let's keep the discussion there, and we can summarize the conclusion here once we get to the bottom of it.

@rochemike apologies for the late reply. As you've seen, there is lots of improvement for the xenserver-packer-plugin that has been revived from the orphaned upstream repo.

I would greatly appreciate it if you added these issues to the GitHub project. That way we can make sure there is tracking for them.

As for the iso issue you mentioned, that was already tracked and it should be fixed soon (packer-plugin-xenserver#56)!

The ddelnano/packer-plugin-xenserver release v0.5.1 has been released and includes @bagas's fix for this issue.