On Fri, Apr 04, 2025 at 04:32:42PM +0300, Biser Milanov via Devel wrote:
Hi,Right now, looking at the QEMU driver, libvirt supports listing all of the present CPUs on the hypervisor via /sys/devices/system/cpu/present. For systems where cgroups with exclusive CPU bits are configured, however, there might be CPUs that are not availabe to libvirt. This leads to situations where a domain cannot be started because of an invalid cpuset attribute (using a CPU with an exclusive bit set). My initial idea was to refactor functions like virNodeGetCPUMap() to take into account cgroup limits. danpb mentioned in #virt (thanks danpb!) that libvirtd might run in a cgroup that is not the one in which VMs will run (like on systemd hosts where libvirtd will run under /sys/fs/cgroup/system.slice/, and VMs under /sys/cgroup/machine.slice/), so just reading hardcoded cgroup files is not a good idea.
Yes, there are several reasons why libvirt is trying to schedule the VM on all CPUs and rather provides ways to limit that selection. Having said that, we also already subtract isolated CPUs from the full list (if there is no pinning set for the VM) since commit da95bcb6b2d9 https://gitlab.com/libvirt/libvirt/-/commit/da95bcb6b2d9b04958e0f2603202801dd29debb8 However it is a bit trickier with exclusive CPUs. AFAIU isolated CPUs are static between reboots so it is easier to know what to subtract. So I would rather vouch for letting the users decide based on what's the current host setup, which they should, ideally, know beforehand.
Is it possible for libvirt to figure out what the actually schedulable CPUs are? Ideally users can then query this information via `virsh nodeinfo` or `virsh capabilities`.
If that is not known for some reason, then we could provide that
information, but is there a reliable way to get all the non-exclusive
CPUs that could be used for a VM? I'm worried about two things:
1) the information gathering being racy (by the time we check one
cgroup there might be a change in another)
2) there are more than one file per cgroup to check in order to make it
correct and the logic behind it is not too straightforward.
--- Regards, Biser
signature.asc
Description: PGP signature
