kvm runs in user.slice cgroup instead of qemu.slice, flooding syslog

[benyamin]

Running a VM via the shell (to institute additional command line parameters) results in the syslog being flooded with qmeventd events like the following:

qmeventd[1038]: error parsing vmid for 3371241: no matching qemu.slice cgroup entry
qmeventd[1038]: could not get vmid from pid 3371241

Running cat /proc/$(ps auxf | grep kvm | grep " <VMID> " | awk '{print $2}')/cgroup reveals:

0::/user.slice/user-0.slice/session-142.scope

However, when run the unmodified VM via the PVE GUI, we get: 0::/qemu.slice/<VMID>.scope

Is there a method to cause a VM run from the shell to run in the qemu.slice instead...?

 

[sva]

If my understanding is correct - When you run a VM through the PVE GUI, it uses the proper systemd slice (qemu.slice) and creates a specific scope for the VM. When running from the shell, the VM process is created within the user-session scope, which doesn't provide the same level of integration with Proxmox's management tools.

I suspect syslog would be a smidgen happier if you ran in a fashion such as below:

systemd-run --slice=qemu.slice --scope -p Delegate=yes qemu-system-x86_64 <qemu params>

 

[benyamin]

Thanks @sva. I had to add --enable-kvm to get it to run, but it came back with:

0::/qemu.slice/run-ra4e81684ec1f462ea56c3a1b9be6b1c1.scope

The scope needs to be created as /sys/fs/cgroup/qemu.slice/<VMID>.scope

Any ideas?

 

[sva]

Thanks @sva. I had to add --enable-kvm to get it to run, but it came back with:

0::/qemu.slice/run-ra4e81684ec1f462ea56c3a1b9be6b1c1.scope

The scope needs to be created as /sys/fs/cgroup/qemu.slice/<VMID>.scope

Any ideas?

Nice, looks like we're a step further. You should be able to get away with adding --unit=<vmid>.scope. Something like:

systemd-run --slice=qemu.slice --unit=vm101.scope --scope -p Delegate=yes -- qemu-system-x86_64 --enable-kvm <addl params>

 

[cheiss]

Hi,

Running a VM via the shell (to institute additional command line parameters)

the usual way to add additional arguments to the QEMU command line is via the args configuration key in the respective VM configuration file.
See also the documentation about VM configuration for general information about VM configuration files, under VM options you can then also find the args: being documented.

Properly starting the VMs is done using qm start <vmid> command, which will insert the configured extra arguments as appropriate.

 

[benyamin]

@sva, that did the trick. Thanks for that.

I note running it in the proper scope changes certain things, the most obvious being that -no-shutdown has no effect (which I didn't mind).

@cheiss, I normally would do as you advise above, but in this case I was adding blkdebug to a drive. This would require drive and device lines to be added and removed from the quest's configuration file for each switch between normal and debug operation. As an alternative, I leave the guest's configuration file alone and start from the command line just for my debug session. This is much more convenient, especially when switching often.

 

[sva]

Great, thanks for that feedback/info!

@cheiss

Thank you as well for your feedback. Can you confirm if there's a better/more supported way to do this kind of temporary debugging with that in mind?

 

[benyamin]

I note running it in the proper scope changes certain things, the most obvious being that -no-shutdown has no effect (which I didn't mind).

Interestingly, it also drops any mention of the added blkdebug directives from qm showcmd <VMID> --pretty and qm showcmd <VMID>. The presence of the addition can still be confirmed with ps aux and the guest certainly responds to block device debug events.