libvirt users - Jan 2023 - libvirt error - "cannot set CPU affinity"

Hello,

I am getting the following error message when trying to run a VM with
the emulatorpin cpuset set to a value -

"cannot set CPU affinity on process 78: Invalid argument".

Note that removing the emulatorpin leads to the VM running successfully.

The core that I am setting for the emulatorpin cpuset is present on the
system and is not in the isolcpus set of the host.

Any suggestions on what could be the problem? Any pointers to how to debug
the issue would help greatly too.

Some further details if they help - I am using kubevirt (KubeVirt.io
<http://kubevirt.io/>) which uses libvirt to manage VM instances in a
kubernetes environment. The libvirt version being used is 8.0.0.

Thanks,
Dipanjan Das
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://listman.redhat.com/archives/libvirt-users/attachments/20230131/b90c31a3/attachment.htm>

On 1/31/23 13:43, Dipanjan Das wrote:
> Hello,
> 
> I am getting the following error message when trying to run a VM with
> the?emulatorpin cpuset set to a value -
> 
> "cannot set CPU affinity on process 78: Invalid argument".
> 
> Note that removing the emulatorpin leads to the VM running successfully.
> 
> The core that I am setting for the emulatorpin cpuset is present on the
> system and is not in the isolcpus set of the host.
The question is, whether the container that libvirtd runs in is allowed
to run on the selected cpuset. I mean, you can have a cgroup that allows
a subset of physical CPUs, and when a process running within the cgroup
tries to set affinity to a CPU that's not allowed it gets EINVAL.

The function this error message comes from is: virProcessSetAffinity()
(the linux version)

https://gitlab.com/libvirt/libvirt/-/blob/master/src/util/virprocess.c#L445

Another reason for the error might be insufficient permissions (though
the man page of sched_setaffinity() says you'd get an EPERM so maybe not).
> 
> Any?suggestions on what could be the?problem? Any pointers to how to
> debug the issue would help greatly too.
Turning on debug logs is a good start. From there you'd need a trained
eye to see the code path, but if you post a link to the logs here I'll
try to help.

Michal