Hello,
I've tested the scenario with restoring too many domains having
lock commented out. It turns out that in case when there is no
memory left for XEN to allocate, all pending xl restore
commands will simply fail with an internal error.
As far as I understand, it's not going to do any damage unless I
request too much memory?
If so, then there is some place for improvement, i.e. to make xl
acquire the lock, allocate memory, release the lock and then start
restoring the domain state. Maybe I could provide some pull
request if I would manage to implement such behavior.
Best regards,
Michał Leszczyński
On 10.06.2019 11:41, Anthony PERARD
wrote:
On Fri, Jun 07, 2019 at 02:06:30PM +0200, Michał Leszczyński wrote:
Hello,
Hi,
when either "xl restore" or "xl create" command is invoked, a global lock is acquired here:
https://github.com/xen-project/xen/blob/master/tools/xl/xl_vmcontrol.c#L876
I'm trying to figure out what is the exact importance of this lock? Is it really critical for XL operation? I have a pretty powerful machine on which I want to run a few dozen of short-lived VMs. This lock is seriously slowing me down, not letting to restore more than one domain at once. Turns out that everything still works fine (and much faster) when I comment-out the lock in the abovementioned place, but I'm not sure if it's a correct impression.
Does anyone know if there is a situation in which Xen would screw up without this lock?
Here is the reason for the lock:
https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=ea4dce89d478d62341cd2f9d8944e215f7086144
xl: free memory before building a domain
Free the needed amount of memory before proceeding with the domain
build.
Use a filelock to prevent other xl instances from conflicting during
this operation.
So there are probably configurations where the lock isn't useful, or
there are better ways to reserve memory for domain creation.
--
Pozdrawiam
Michał Leszczyński
CERT Polska/NASK
+48 532 461 124
_______________________________________________
