Libvirt commit c2e60ad0e51 added a new check to the XML validation
logic where XMLs containing <memoryBacking><mlocked/> must also
contain <memtune><hard_limit>. This causes two breakages where
working guests won't start anymore:
1. Systems where mlock limit was set in /etc/security/limits.conf
2. Guests using hugeTLB pages. In this case, guests were relying
on the fact that libvirt automagically increases mlock
limit to 1GB
While it's true that <memoryBacking><mlocked/> documentation
says that <memtune><hard_limit> is required, this is actually
an extremely bad request because:
A. <memtune><hard_limit> own documention strongly recommends
NOT using it
B. <memtune><hard_limit> does more than setting memory locking
limit
C. <memtune><hard_limit> does not support infinity, so you have
to guess a limit
D. If <memtune><hard_limit> is less than 1GB, it will lower
VFIO's automatic limit of "guest memory + 1GB"
Here's two possible solutions to fix this all:
1. Drop change c2e60ad0e51 and drop automatic increases. Let
users configure limits in /etc/security/limits.conf
pros: this is the most correct way to do it, and how
it should be done originally IMHO
cons: will break working VFIO setups, so probably undoable
2. Drop change c2e60ad0e51 and automtically increase memory
locking limit to infinity when seeing <memoryBacking><locked/>
pros: make all cases work, no more <hard_limit> requirement
cons: allows guests with <locked/> to lock all memory
assigned to them plus QEMU allocations. While this seems
undesirable or even a security issue, using <hard_limit>
will have the same effect
Lastly, <locked/> doesn't belong to <memoryBacking>, it should
be in <memtune>. I recommend deprecating it from <memoryBacking>
and adding it where it belongs.
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
