]> git.ipfire.org Git - thirdparty/libvirt.git/commit
qemu: Set up EMULATOR thread and cpuset.mems before exec()-ing qemu
authorMichal Privoznik <mprivozn@redhat.com>
Wed, 10 Apr 2019 15:14:25 +0000 (17:14 +0200)
committerMichal Privoznik <mprivozn@redhat.com>
Thu, 18 Apr 2019 15:53:42 +0000 (17:53 +0200)
commit0eaa4716e1b8f6eb59d77049aed3735c3b5fbdd6
tree9a2b0e95cf3c7cb410318a12ec8733d76d266db0
parent22dc3e94c24b4d9a6c28beda91b9b283eb9b0251
qemu: Set up EMULATOR thread and cpuset.mems before exec()-ing qemu

It's funny how this went unnoticed for such a long time. Long
story short, if a domain is configured with
VIR_DOMAIN_NUMATUNE_MEM_STRICT libvirt doesn't really honour
that. This is because of 7e72ac787848 after which libvirt allowed
qemu to allocate memory just anywhere and only after that it used
some magic involving cpuset.memory_migrate and cpuset.mems to
move the memory to desired NUMA nodes. This was done in order to
work around some KVM bug where KVM would fail if there wasn't a
DMA zone available on the NUMA node. Well, while the work around
might stopped libvirt tickling the KVM bug it also caused a bug
on libvirt side: if there is not enough memory on configured NUMA
node(s) then any attempt to start a domain must fail. Because of
the way we play with guest memory domains can start just happily.

The solution is to move the child we've just forked into emulator
cgroup, set up cpuset.mems and exec() qemu only after that.

This basically reverts 7e72ac787848b7434c9 which was a workaround
for kernel bug. This bug was apparently fixed because I've tested
this successfully with recent kernel.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
src/qemu/qemu_process.c