API error creating qemu VM when boot: set

[murphyslaw]

Hello,

When using POST on the API with boot: parameter set, I am receiving error 400. If I remove the boot order from the request it works fine.

https://pve-nuc-1:8006 "POST /api2/json/nodes/pve-nuc-2/qemu HTTP/1.1" 400 107
requests.exceptions.HTTPError: 400 Client Error: Parameter verification failed. for url: https://pve-nuc-1:8006/api2/json/nodes/pve-nuc-2/qemu

This is the POST data:

{'vmid': 102, 'memory': 2048, 'ide2': 'synology-pve:iso/ubuntu-22.04.2-live-server-amd64.iso,media=cdrom', 'net0': 'virtio,bridge=vmbr20,firewall=0', 'name': 'testme2', 'ostype': 'l26', 'boot': 'order=scsi0,ide2,net0', 'ide0': 'local:cloudinit', 'scsihw': 'virtio-scsi-single', 'scsi0': 'local-lvm:10'}

So my questions:

• Is there something about the order in which parameters are set? Should VMs be created in two or more steps, because the boot order can't be set until the disks exist?
• Are there any other parameters which can't be set during creation? I wonder if those are documented or if I can retrieve them from the API so that I don't have to hardcode them in my code?

 

[shanreich]

I think the issue is that you are using , as a separator but the boot key requires ;

 

[murphyslaw]

I just used this, the error remains:

'boot': 'order=net0'

I think I found the problem. Probably scsi0 gets created asynchronously, and setting boot: fails during creation until disk creation is complete.

But are there other parameters that shouldn't be set during creation, and is there a way to query the API for status of async creation operations?

 

[shanreich]

I think I found the problem. Probably scsi0 gets created asynchronously, and setting boot: fails during creation until disk creation is complete.

Good catch I didn't think of that initially - also thanks for opening a bug report in our Bugzilla regarding this issue. Sadly I cannot tell you about which params would be affected by this, I'd have to try and see or read the source code.

For someone stumbling over this thread in the future, here is the bugreport: https://bugzilla.proxmox.com/show_bug.cgi?id=4694