@ddelnano yes, having an expected CIDR field would cover this use case perfectly.

@ddelnano do you need any additional information or is this enough to work off of?

@ddelnano yes, having an expected CIDR field would cover this use case perfectly.

@ddelnano is this something you may be able to help with?

When using Terraform to deploy a Windows VM I need to be able to connect to the host to finalize OS configuration settings. To connect to the host I am using an inline provisioner that is connecting via WinRM with the host connection using the output of the network ipv4 address.

    connection {
      type = "winrm"
      user = var.username
      password = var.password
      host = element(xenorchestra_vm.qa-vm1.network[0].ipv4_addresses, 0)
    }

I set the wait_for_ip flag to true so I could use the returned IP address

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
    template = data.xenorchestra_template.vm_template.id

but it returns a 169.254.126.62 address and attempts to connect via that address until the apply times out or is cancelled

Still creating... [1m10s elapsed]
Still creating... [1m20s elapsed]
(remote-exec): Connecting to remote host via WinRM...
(remote-exec):   Host: 169.254.126.62
(remote-exec):   Port: 5985
(remote-exec):   User: jsmith
(remote-exec):   Password: true
(remote-exec):   HTTPS: false
(remote-exec):   Insecure: false
(remote-exec):   NTLM: false
(remote-exec):   CACert: false

XCP-NG tools are installed on this host and I can see it reporting the IP address correctly in Xen Orchestra.

Is there a setting I can use to refresh this address so it updates to use the proper DHCP IP of this host or possibly a way to use a sleep timer to wait for the IP to be assigned and show through the XCP-NG tools?

@julien-f slightly off topic then, but is there a way to extend token expiration for a single user and not globally? Or to have a single user excluded from the global default?

@julien-f some of the scripts I need to be run can't always run on the XOA appliance and need to be run on other Linux/Windows hosts so the output can be manipulated for use via other programs/methods.

Having a way to pass authentication through curl would give the ability to generate a token when not running scripts on the main XOA appliance.

Is there a method available, or planned, to generate a REST API token via curl? My environment currently has tokens set to expire after 72 hours and regenerating it via xo-cli or pulling it through the web UI is an extra manual step.

Being able to run something similar to the below to generate and store a token would help with automating some tasks I am looking to do on a scheduled basis

 curl --location 'https://XOA.company.lan/rest/v0/authorization/token' --data-urlencode 'grant_type=password' --data-urlencode 'username=admin' --data-urlencode 'password=P@$$w0rd'

@olivierlambert - Figured it out for anyone else's future reference.

When setting platform_args you need to define all of them even if you only need to change one.

Since the defaults are

{
    "viridian": "false",
    "nx": "true",
    "pae": "true",
    "apic": "true",
    "timeoffset": "0",
    "acpi": "1",
    "cores-per-socket": "1"
}

I needed to include all of them even though I only needed "viridian": "true". Once I added in the other options the VM booted and the build worked.

@olivierlambert That is always a possibility

I created the Windows and CentOS templates the same way by creating a base VM without installing the OS and then capturing that as a Template. I also tried copying the default pre-defined Windows Server 2022 template.

When creating a Windows VM with Packer using UEFI boot firmware, the VM is failing to boot around 88% with no errors logged in XOA.

I am using the following Packer plugin:
https://github.com/ddelnano/packer-plugin-xenserver/tree/main

Things tested/checked so far:

1. If the VM is switched from UEFI to BIOS it boots but then fails to boot if switched back to UEFI.
2. If a VM is manually created in XOA from the same template it boots with no issue
3. If the firmware="uefi" option is removed from Packer, the VM defaults to BIOS and boots fine. However, if the VM is switched to UEFI it fails to boot
4. Using Packer to create a UEFI CentOS VM works as expected
5. Re-created the cloned Windows template and issue persists

I checked the output of xe vm-list with all params, and the only major differences I noticed are:

Packer created VM:

platform (MRW): timeoffset: 0; device-model: qemu-upstream-uefi; viridian: true

other-config (MRW): xo:03af740a: {"creation":{"date":"2023-11-06T20:16:30.631Z","template":"1c33af1c-e919-418c-ad45-85d7d6fb604a","user":"f8241546-6b58-484e-92d0-58817ea45b3f"}}; base_template_name: Windows Server 2022 (64-bit); import_task: OpaqueRef:55b37ba3-84a2-47ac-b8a6-41fb63a69ebc; mac_seed: ceaf53ff-f229-63d2-b586-5cb5aaea6686; install-methods: cdrom

XOA created VM:

platform (MRW): secureboot: false; device-model: qemu-upstream-uefi; timeoffset: 0; videoram: 8; hpet: true; viridian_apic_assist: true; apic: true; device_id: 0002; cores-per-socket: 2; viridian_crash_ctl: true; pae: true; vga: std; nx: true; viridian_time_ref_count: true; viridian_stimer: true; viridian: true; acpi: 1; viridian_reference_tsc: true

other-config (MRW): xo:17504efc: {"creation":{"date":"2023-11-06T21:03:58.450Z","template":"03af740a-ca0d-4246-e64d-bab99b90f682","user":"f8241546-6b58-484e-92d0-58817ea45b3f"}}; xo:03af740a: {"creation":{"date":"2023-11-06T20:16:30.631Z","template":"1c33af1c-e919-418c-ad45-85d7d6fb604a","user":"f8241546-6b58-484e-92d0-58817ea45b3f"}}; base_template_name: Windows Server 2022 (64-bit); import_task: OpaqueRef:55b37ba3-84a2-47ac-b8a6-41fb63a69ebc; mac_seed: f5d234ad-6d5c-012b-a2f7-2c2ee9a61cca; install-methods: cdrom