On Tue, Jun 12, 2018 at 03:04:42PM +0200, Michal Privoznik wrote:
On 06/12/2018 02:42 PM, Igor Mammedov wrote:
>>>
>>> Do we really need to make -daemonize and -preconfig work
>>> together? libvirt uses -daemonize only for its initial
>>> capability probing, which shouldn't require -preconfig at all.
>>>
>>> Even on that case, I wonder why libvirt doesn't simply create a
>>> server socket and waits for QEMU to connect instead of using
>>> -daemonize as a sync point.
>>>
>>
>> because libvirt views qemu as well behaved daemon. Should anything go
>> wrong libvirt reads qemu's stderr and reports error to upper layers.
> We can keep daemonizing flow in QEMU as it's now.
> But Eduardo's idea about libvirt created socked + letting QEMU connect to it
> has a merit. It should fix current deadlock issue with as monitor
> won't be depending on lead exit event.
Not sure about the benefits. Currently, libvirt spawns qemu, waits for
monitor to show up (currently, the timeout dynamic depending on some
black magic involving guest RAM size) and if it does not show up in time
it kills qemu. The same algorithm must be kept in place even for case
when libvirt would pass pre-opened socket to qemu in case qemu deadlocks
before being able to communicate over qmp. The only advantage I see is
libvirt would not need to label the socket (set uid:gid, selinux, ...).
As mentioned in my other reply, we already do FD passing, and that code
has intentionally got rid of the timeout, because timeouts cause false
failures to launch QEMU. This is a particular problem when using many
disks that are encrypted, since LUKS encryption has a minimum 1 second
delay on opening each disk, so with many disks we're at risk of hitting
the timeout even when QEMU is still starting normally.
I don't see a reason to special case startup with timeouts to deal
with hangs, while ignoring the possibility of hangs after initial
startup.
On the other hand, since it would be libvirt creating the socket
what
would happen on libvirtd restart?
We're creating a *listener* socket, not a client connection, so on
restart we simply connect again as normal.
Regards,
Daniel
--
|:
https://berrange.com -o-
https://www.flickr.com/photos/dberrange :|
|:
https://libvirt.org -o-
https://fstop138.berrange.com :|
|:
https://entangle-photo.org -o-
https://www.instagram.com/dberrange :|