On Wed, Jun 13, 2018 at 11:17:30AM -0300, Eduardo Habkost wrote:
> On Tue, Jun 12, 2018 at 01:50:33PM +0100, Daniel P. Berrangé wrote:
> > On Tue, Jun 12, 2018 at 02:42:05PM +0200, Igor Mammedov wrote:
> > > 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.
> >
> > NB, libvirt only ever uses --daemonize when probing capabilities, never
> > when launching QEMU for a real VM. In the latter case, we now use FD
> > passing, so libvirt opens the UNIX domain socket listener, and passes
> > this into QEMU. So libvirt knows it can connect to the listener
> > immediately and will only ever get a failure if QEMU has exited.
>
> So, what I'm really missing here is: do we have a good reason to
> support --daemonize + --preconfig today?
On the libvirt zero, I don't see a compelling need for it.
> The options I see are:
>
> 1) complete daemonization before preconfig main loop
> ----------------------------------------------------
>
> By "complete daemonization" I mean doing chdir("/"),
> stderr/stdout cleanup, chroot, and UID magic before calling
> exit(0) on the main QEMU process.
>
> Pros:
> * More intuitive
>
> Cons:
> * Can break existing initialization code that don't expect
> this to happen.
> (can this be fixed?)
> * Can break any preconfig-time QMP commands that rely on opening
> files
> (is it a real problem?)
NB Use of -chroot is separate from -daemonize, so it is not
an issue with -preconfig + -daemonize alone.
There's soo many caveats around -chroot, I struggle to
care about adding another caveats.
> * Any initialization error conditions that currently rely on
> error_report()+exit() will be very inconvenient to handle
> properly
> (this can be fixed eventually, but it's not trivial)
> 3) daemonize only after leaving preconfig state
> -----------------------------------------------
>
> AFAICS, this is the current behavior.
>
> Pros:
> * Less likely to break init code
> * Keeps existing code as is
>
> Cons:
> * Less intuitive
> * -daemonize becomes useless as synchronization point for monitor
> availability
Yeah that honestly kills the key benefit of having -daemonize
imho.
> * Would this be useful for anybody, at all?
> * We won't be able to change this behavior later
>
>
> I believe the only reasonable options are (1) and (4).
Agreed.
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 :|
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
