Proxmox tries to start VM with incorrect 'smp' value after creation with API

[William Edwards]

Issue:

• When creating a VM with Proxmox API, I get the error "kvm: maxcpus must be equal to or greater than smp" on startup.
• The startup command contains `-smp '4,sockets=1,cores=1,maxcpus=1'`, but these values differ from processor configuration:
  
  
  
  Values I am passing to API: cores = 6, vcpus = 1
  
  
• Requests logged in `/var/log/pveproxy/access.log` when trying to start VM with API:
  
  

  $myip - - [25/02/2020:08:17:01 +0100] "POST /api2/json/access/ticket HTTP/1.1" 200 903
  $myip - apitest@pve [25/02/2020:08:17:01 +0100] "GET /api2/json/version HTTP/1.1" 200 84
  $myip - apitest@pve [25/02/2020:08:17:01 +0100] "GET /api2/json/cluster/resources?type=vm HTTP/1.1" 200 637
  $myip- apitest@pve [25/02/2020:08:17:01 +0100] "GET /api2/json/cluster/resources?type=vm HTTP/1.1" 200 637
  $myip - apitest@pve [25/02/2020:08:17:01 +0100] "GET /api2/json/nodes/px01/qemu/103/status/current HTTP/1.1" 200 324
  $myip - apitest@pve [25/02/2020:08:17:02 +0100] "POST /api2/json/nodes/px01/qemu/103/status/start HTTP/1.1" 200 72

  
  
• I have also tried not setting vCPUs (`maxcpus`) and only set cores instead. The same issue occurs.

I am quite certain this is a bug, because the issue isn't triggered when simply starting the VM via the GUI. When I start via the GUI, different values are passed to the startup command: `-smp 1,sockets=1,cores=6,maxcpus=6` (instead of `-smp '4,sockets=1,cores=1,maxcpus=1'`).

Why are (seemingly) default values being passed to QEMU when trying to start VM with API?

root@pxdev:~# pveversion -v
proxmox-ve: 6.0-2 (running kernel: 5.0.21-1-pve)
pve-manager: 6.0-11 (running version: 6.0-11/2140ef37)
pve-kernel-helper: 6.0-11
pve-kernel-5.0: 6.0-10
pve-kernel-4.15: 5.4-8
pve-kernel-5.0.21-4-pve: 5.0.21-9
pve-kernel-5.0.21-1-pve: 5.0.21-2
pve-kernel-4.15.18-20-pve: 4.15.18-46
pve-kernel-4.15.18-12-pve: 4.15.18-36
pve-kernel-4.15.18-9-pve: 4.15.18-30
ceph: 14.2.4-pve1
ceph-fuse: 14.2.4-pve1
corosync: 3.0.2-pve4
criu: 3.11-3
glusterfs-client: 5.5-3
ksm-control-daemon: 1.3-1
libjs-extjs: 6.0.1-10
libknet1: 1.13-pve1
libpve-access-control: 6.0-3
libpve-apiclient-perl: 3.0-2
libpve-common-perl: 6.0-7
libpve-guest-common-perl: 3.0-2
libpve-http-server-perl: 3.0-3
libpve-storage-perl: 6.0-9
libqb0: 1.0.5-1
lvm2: 2.03.02-pve3
lxc-pve: 3.2.1-1
lxcfs: 3.0.3-pve60
novnc-pve: 1.1.0-1
proxmox-mini-journalreader: 1.1-1
proxmox-widget-toolkit: 2.0-8
pve-cluster: 6.0-7
pve-container: 3.0-10
pve-docs: 6.0-8
pve-edk2-firmware: 2.20190614-1
pve-firewall: 4.0-7
pve-firmware: 3.0-4
pve-ha-manager: 3.0-2
pve-i18n: 2.0-3
pve-qemu-kvm: 4.0.1-5
pve-xtermjs: 3.13.2-1
qemu-server: 6.0-13
smartmontools: 7.0-pve2
spiceterm: 3.1-1
vncterm: 1.6-1
zfsutils-linux: 0.8.2-pve2

 

[dietmar]

I guess your host cpu only has 4 cores?

 

[William Edwards]

I guess your host cpu only has 4 cores?

No, this test host has 12. I have also updated my post to show that not setting vCPUs (`maxcpus`) but only setting `cores` leads to the same issue.

I feel like Proxmox passes default values to 'smp' by mistake.

root@pxdev:~# lscpu | grep CPU
CPU op-mode(s):      32-bit, 64-bit
CPU(s):              12
On-line CPU(s) list: 0-11
CPU family:          6
Model name:          Intel(R) Xeon(R) CPU           X5650  @ 2.67GHz
CPU MHz:             1596.302
NUMA node0 CPU(s):   0-11

 

[dcsapak]

proxmox-ve: 6.0-2 (running kernel: 5.0.21-1-pve)

please upgrade to a current version and try again, just to rule out that it was a bug we maybe already fixed

 

[William Edwards]

please upgrade to a current version and try again, just to rule out that it was a bug we maybe already fixed

I can confirm this issue does not occur on 6.0-7. Our production runs on 5.4-13, so I will try on that version as well.

 

[Yvan Watchman]

I somehow cannot reproduce this issue on:

root@px01:~# pveversion -v
proxmox-ve: 6.0-2 (running kernel: 5.0.21-1-pve)
pve-manager: 6.0-11 (running version: 6.0-11/2140ef37)
pve-kernel-helper: 6.0-11
pve-kernel-5.0: 6.0-10
pve-kernel-4.15: 5.4-8
pve-kernel-5.0.21-4-pve: 5.0.21-9
pve-kernel-5.0.21-1-pve: 5.0.21-2
pve-kernel-4.15.18-20-pve: 4.15.18-46
pve-kernel-4.15.18-12-pve: 4.15.18-36
pve-kernel-4.15.18-9-pve: 4.15.18-30
ceph: 14.2.4-pve1
ceph-fuse: 14.2.4-pve1
corosync: 3.0.2-pve4
criu: 3.11-3
glusterfs-client: 5.5-3
ksm-control-daemon: 1.3-1
libjs-extjs: 6.0.1-10
libknet1: 1.13-pve1
libpve-access-control: 6.0-3
libpve-apiclient-perl: 3.0-2
libpve-common-perl: 6.0-7
libpve-guest-common-perl: 3.0-2
libpve-http-server-perl: 3.0-3
libpve-storage-perl: 6.0-9
libqb0: 1.0.5-1
lvm2: 2.03.02-pve3
lxc-pve: 3.2.1-1
lxcfs: 3.0.3-pve60
novnc-pve: 1.1.0-1
proxmox-mini-journalreader: 1.1-1
proxmox-widget-toolkit: 2.0-8
pve-cluster: 6.0-7
pve-container: 3.0-10
pve-docs: 6.0-8
pve-edk2-firmware: 2.20190614-1
pve-firewall: 4.0-7
pve-firmware: 3.0-4
pve-ha-manager: 3.0-2
pve-i18n: 2.0-3
pve-qemu-kvm: 4.0.1-5
pve-xtermjs: 3.13.2-1
qemu-server: 6.0-13
smartmontools: 7.0-pve2
spiceterm: 3.1-1
vncterm: 1.6-1
zfsutils-linux: 0.8.2-pve2
root@px01:~#

 

[William Edwards]

The issue seems to have been solved without intervention. Strange.

 

[LnxBil]

I think the error is back since one of the last updates... I have it on VMs that worked before.