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.
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`.
---
Regards,
Biser
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.
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`.
---
Regards,
Biser
