```boot``` parameter not applied on Qemu VMs

[Thulium-Drake]

Hi there,

When I clone a template VM (as #341 isn't here yet) with the following .tf, it keeps complaining the VM does not have the correct boot order. In my case the boot order is empty on my template (as it has no disks/networks), but also when I want to change it from net0;virtio0 to virtio0;net0 for example, the change is not applied to the VMs

TF file

resource "proxmox_vm_qemu" "ns1-example-com" {
  name         = "ns1.example.com"
  target_node  = "phoenix"
  boot         = "order=virtio0;net0"
  clone        = "template"
  bios         = "ovmf"
  onboot       = true
  vcpus        = 1
  memory       = 2048
  scsihw       = "virtio-scsi-single"
  qemu_os      = "l26"
  disk {
    type       = "virtio"
    storage    = "main"
    size       = "50G"
    iothread   = 1
  }
  network {
    bridge     = "vmbr0"
    firewall   = false
    link_down  = false
    model      = "virtio"
  }
}

terraform plan output

  # proxmox_vm_qemu.ns1-example-com will be updated in-place
  ~ resource "proxmox_vm_qemu" "ns1-example-com" {
      ~ boot                      = "order=net0;virtio0" -> "order=virtio0;net0"
        id                        = "phoenix/qemu/101"
        name                      = "ns1.example.com"
        # (29 unchanged attributes hidden)

        # (2 unchanged blocks hidden)
    }

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

Proxmox task log entry

update VM 101: -bios ovmf -cores 1 -cpu host -hotplug network,disk,usb -kvm 1 -memory 2048 -name ns1.example.com -net0 virtio=C6:B3:7B:19:D5:76,bridge=vmbr0 -numa 0 -onboot 1 -ostype l26 -scsihw virtio-scsi-single -sockets 1 -tablet 1 -vcpus 1 -virtio0 main:vm-101-disk-1,size=50G,format=raw,iothread=1
TASK OK

Unless I'm mistaken, the boot parameter isn't passed to the Proxmox API at all.

The workaround I have right now is create a template VM with a dummy disk and network (I use PXE boot to provision them anyway), set the boot order on the template and clone it then.

[tnyeanderson]

Noticed that boot wasn't getting sent in the update call to the API (from the proxmox-api-go package) so working on a fix there

[scottbot95]

What version of the provider are you using? I agree that it definitely doesn't seem like boot is being set for update calls, but I was doing some packet sniffing for an unrelated issue and I can confirm that with 2.9.11 of the provider it is definitely somehow managing to set the boot parameter on at least the initial call to /api2/json/nodes/<node>/qemu/<vmid>/config after cloning (although it still just uses the same config.UpdateConfig function so I would not expect this to be a special case).

[Thulium-Drake]

I'm using following configuration:

terraform {
  required_providers {
    proxmox = {
      source  = "telmate/proxmox"
      version = "2.9.13"
    }
  }
}

provider "proxmox" {
  pm_user = "terraform-prov@pve"
  pm_password = "xxxxxxxxxxxxxx"
  pm_api_url = "https://pve.example.com:8006/api2/json"
}

Which according to the docs, should be the latest version :-)

[scottbot95]

Ah interesting, I updated to 2.9.13 and it definitely breaks it. Looks like ~6 months of change to the PVE API package got merged in between 2.9.11 and 2.9.13 and in that time, it seems like the API package got more or less completely rewritten (1/3 of all commits happened in the last 6 months).

All that is to say, the previously mentioned PR probably is the correct fix and I will be sticking with 2.9.11 until that PR is merged and this provider is updated to use a non-broken version of the API

[scottbot95]

@Thulium-Drake FWIW it is actually possible (with some limitations) to create EFI disks and has just been an undocumented feature for a while apparently. See my latest comment in #341

[Thulium-Drake]

Thanks for the note! It can't help me in my situation, I need to have pre-enrolled keys disabled (as I can't run with SecureBoot enabled when deploying systems via Foreman/Satellite).

But the template workaround is just fine for me, it also allows for some extra settings to be defined.