Re: [libvirt] 200ms delay waiting for qemu monitor

On 06.04.2016 21:45, Richard W.M. Jones wrote: > [Thanks to Dan Berrangé for doing the analysis of this one] > > I was investigating a 200+ millisecond delay when libvirt starts a > qemu guest. You can see the traces here: > > http://oirase.annexia.org/tmp/libvirt.log > http://oirase.annexia.org/tmp/libvirtd.log > > The delay happens at around 16:52:57.327-6:52:57.528 in the libvirtd log. > As you can see the delay is almost precisely 200ms. > > Dan found the cause which seems to be this code: > > https://libvirt.org/git/?p=libvirt.git;a=blob;f=src/qemu/qemu_monitor.c;h... > > (There are other examples of the same anti-pattern in src/fdstream.c > and src/qemu/qemu_agent.c, but it's the particular code above which > seems to be causing the delay). > > To give you some sense why I regard this as a problem, the TOTAL time > taken to launch and shutdown the libguestfs appliance (that includes > qemu, BIOS, guest kernel, probing and mouting disks, running the > guestfs daemon, and the shutdown process in reverse), without libvirt, > is now 900ms. Libvirt adds about 220ms on top of this. > > What can we do about this? Obviously we could simply reduce the > delay, but even if it was set to 20ms, that would be too much (aim is > to reduce the whole process from 900ms down to 150ms), and it would > also mean that libvirt was essentially polling. > > Can we use inotify to detect if the socket has been created? Seems to > create portability problems.

> > Dan suggested: > > Can we create the socket in libvirtd and pass it to qemu? > > Can we pass a file descriptor to qemu? Right. This is the goal that we try to reach. Well, not that anybody I know of is working on it actively. But the idea would be that libvirt would open all the files for qemu and then just pass the FDs. As for the monitor - I think qemu counterpart should be fairly easy, but we rather confirm with qemu guys. I'm definitely in!