Regenerate Cloudinit by PUT API return 500

[guilranc]

Hello !
I want to regenerate my cloud-init iso by API using a PUT on /api2/json/nodes/{node}/qemu/{vmid}/cloudinit
Like describe in doc : https://pve.proxmox.com/pve-docs/api-viewer/index.html#/nodes/{node}/qemu/{vmid}/cloudinit
But api replies : "status : 500 Can't use string ("VM.Config.Cloudinit") as an ARRAY ref while "strict refs" in use at /usr/share/perl5/PVE/RPCEnvironment.pm line 280"
I can do this with "pvesh set /nodes/{node}/qemu/{vmid}/cloudinit", on the same VM, no problem
Moreover, i do many jobs by API without trouble

If you have some ideas

 

[fweber]

Hi, I can reproduce this error.

Just to be sure: Could you post the output of pveversion -v? Is the authenticated user different from root@pam?

As a workaround until this is fixed, you could regenerate the cloudinit drive by two PUT/POST requests to /nodes/{node}/qemu/{vmid}/config: The first to delete the cloudinit drive, the second to re-add it.

 

[guilranc]

hi, thanks for responding

proxmox-ve: 7.3-1 (running kernel: 5.15.85-1-pve)
pve-manager: 7.3-6 (running version: 7.3-6/723bb6ec)
pve-kernel-helper: 7.3-4
pve-kernel-5.15: 7.3-2
pve-kernel-5.15.85-1-pve: 5.15.85-1
pve-kernel-5.15.74-1-pve: 5.15.74-1
pve-kernel-5.15.30-2-pve: 5.15.30-3
ceph-fuse: 15.2.16-pve1
corosync: 3.1.7-pve1
criu: 3.15-1+pve-1
glusterfs-client: 9.2-1
ifupdown2: 3.1.0-1+pmx3
ksm-control-daemon: 1.4-1
libjs-extjs: 7.0.0-1
libknet1: 1.24-pve2
libproxmox-acme-perl: 1.4.3
libproxmox-backup-qemu0: 1.3.1-1
libpve-access-control: 7.3-1
libpve-apiclient-perl: 3.2-1
libpve-common-perl: 7.3-2
libpve-guest-common-perl: 4.2-3
libpve-http-server-perl: 4.1-5
libpve-network-perl: 0.7.2
libpve-storage-perl: 7.3-2
libspice-server1: 0.14.3-2.1
lvm2: 2.03.11-2.1
lxc-pve: 5.0.2-1
lxcfs: 5.0.3-pve1
novnc-pve: 1.3.0-3
proxmox-backup-client: 2.3.3-1
proxmox-backup-file-restore: 2.3.3-1
proxmox-mail-forward: 0.1.1-1
proxmox-mini-journalreader: 1.3-1
proxmox-offline-mirror-helper: 0.5.1-1
proxmox-widget-toolkit: 3.5.5
pve-cluster: 7.3-2
pve-container: 4.4-2
pve-docs: 7.3-1
pve-edk2-firmware: 3.20220526-1
pve-firewall: 4.2-7
pve-firmware: 3.6-3
pve-ha-manager: 3.5.1
pve-i18n: 2.8-2
pve-qemu-kvm: 7.1.0-4
pve-xtermjs: 4.16.0-1
qemu-server: 7.3-3
smartmontools: 7.2-pve3
spiceterm: 3.2-2
swtpm: 0.8.0~bpo11+2
vncterm: 1.7-1
zfsutils-linux: 2.1.9-pve1

I use a user api token like "user_api@pam!token_api" and his "PVEAPIToken" in headers, this account has all privileges, i confirme this with pveum
It do the same with a "CSRFPreventionToken"

 

[guilranc]

Thanks for the workaround too

 

[fweber]

Thanks for checking, and thank you for the report! I sent a patch to the mailing list to fix this [1]. Until it is merged and packaged, I'd suggest to use the workaround -- it's also the approach currently used by the Web UI

[1] https://lists.proxmox.com/pipermail/pve-devel/2023-March/056155.html

 

[guilranc]

Thanks a lot for your reactivity ! meanwhile the patch i'm using pvesh command

 

[linuxdaemon]

I am running in to the same issue using an API token for the user root@pam (with privilege separation enabled). Is there an expected timeframe for this patch to be packaged in a release?

 

[fweber]

The patch I linked was already applied [1] and available in qemu-server >= 8.0.7. Could you doublecheck whether you have a package version with the fix installed? If yes and you still see the error, please post the output of pveversion -v as well as the VM config (output of qm config VMID), API request you send, and error message you see.

[1] https://git.proxmox.com/?p=qemu-server.git;a=commit;h=dafabbd01fa2612b7d28a7bc5c6bf876259309f8

 

[linuxdaemon]

Ah ok, I see the problem. I am still on PVE 7.4 due to some hardware issues with linux kernel 6.x. Is there any plan to backport this fix to 7.4?

 

[fweber]

Ah ok, I see the problem. I am still on PVE 7.4 due to some hardware issues with linux kernel 6.x. Is there any plan to backport this fix to 7.4?

The fix is unlikely to be backported to PVE 7, as it's not a security-relevant issue. Have you checked whether the following workaround I mentioned above works for you?

As a workaround until this is fixed, you could regenerate the cloudinit drive by two PUT/POST requests to /nodes/{node}/qemu/{vmid}/config: The first to delete the cloudinit drive, the second to re-add it.

As a last resort and since the patch is really small, you could also apply it locally yourself, but keep in mind that a package upgrade would overwrite the file again.

 

[linuxdaemon]

I ended up rolling out PVE 8.1 across my cluster as it seems kernel 6.5 fixed my hardware issues. I was using the workaround, it was just annoying to be deleting and recreating the image like that. Thank you for your work on this!