On 1/31/23 20:17, Dipanjan Das wrote: > > > On Tue, 31 Jan 2023 at 22:49, Michal Prívozník <mprivozn@xxxxxxxxxx > <mailto:mprivozn@xxxxxxxxxx>> wrote: > > 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. > > > Makes sense. > > I am now wondering whether we can check the cgroups on the host or > inside the containers to confirm that this is the case. Since I am > setting the emulator pin thread to a known cpu, being able to check > whether the cpu is in the cpu subset of the cgroup might be a quick way > to find the problem. Yeah. I don't know enough about KubeVirt let alone OpenShift to tell you ow to do that, sorry. But essentially, you want to check the contents of cpuset.cpus of the container that libvirtd runs in. cat $(grep -lr $(pgrep libvirtd) $(mount | grep cpuset | awk '{print $3}') | head -n1 | sed 's/cgroup.procs/cpuset.cpus/') > > > > The function this error message comes from is: virProcessSetAffinity() > (the linux version) > > https://gitlab.com/libvirt/libvirt/-/blob/master/src/util/virprocess.c#L445 <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. > > > Thank you very much. Should I enable debug logs for any specific > module(s) or for all of them? This should help: https://libvirt.org/kbase/debuglogs.html And we're interested in the daemon logs as the daemon is where all the interesting work takes place. Michal
