<div dir="ltr"><div dir="auto">I can share some test results with you:</div><div dir="auto">1. If no memtune->hard_limit is set when start a vm, the default memlock hard limit is 64MB</div><div>2. If memtune->hard_limit is set when start a vm, memlock hard limit will be set to the value of memtune->hard_limit</div><div>3. If memtune->hard_limit is updated at run-time, memlock hard limit won't be changed accordingly</div><div><br></div><div>And some additional knowledge:</div><div>1. memlock hard limit can be shown by ‘prlimit -p <pid-of-qemu> -l’</div><div>2. The default value of memlock hard limit can be changed by setting LimitMEMLOCK in /usr/lib/systemd/system/virtqemud.service<br></div><div><br></div><div>BR,</div><div>Fangge Jin</div></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 17, 2022 at 19:25 Milan Zamazal <<a href="mailto:mzamazal@redhat.com" target="_blank">mzamazal@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Peter Krempa <<a href="mailto:pkrempa@redhat.com" target="_blank">pkrempa@redhat.com</a>> writes:<br>
<br>
> On Wed, Aug 17, 2022 at 10:56:54 +0200, Milan Zamazal wrote:<br>
>> Hi,<br>
>> <br>
><br>
>> do I read libvirt sources right that when <memtune> is not used in the<br>
>> libvirt domain then libvirt takes proper care about setting memory<br>
>> locking limits when zero-copy is requested for a migration?<br>
><br>
> Well yes, for a definition of "proper". In this instance qemu can lock<br>
> up to the guest-visible memory size of memory for the migration, thus we<br>
> set the lockable size to the guest memory size. This is a simple upper<br>
> bound which is supposed to work in all scenarios. Qemu is also unlikely<br>
> to ever use up all the allowed locking.<br>
<br>
Great, thank you for confirmation.<br>
<br>
>> I also wonder whether there are any other situations where memory limits<br>
>> could be set by libvirt or QEMU automatically rather than having no<br>
>> memory limits?  We had oVirt bugs in the past where certain VMs with<br>
>> VFIO devices couldn't be started due to extra requirements on the amount<br>
>> of locked memory and adding <hard_limit> to the domain apparently<br>
>> helped.<br>
><br>
> <hard_limit> is not only an amount of memory qemu can lock into ram, but<br>
> an upper bound of all memory the qemu process can consume. This includes<br>
> any qemu overhead e.g. used for the emulation layer.<br>
><br>
> Guessing the correct size of overhead still has the same problems it had<br>
> and libvirt is not going to be in the business of doing that.<br>
<br>
To clarify, my point was not whether libvirt should, but whether libvirt<br>
or any related component possibly does (or did in the past) impose<br>
memory limits.  Because as I was looking around it seems there are no<br>
real memory limits by default, at least in libvirt, but some limit had<br>
been apparently hit in the reported bugs.<br>
<br>
</blockquote></div></div>