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