On Wed, Jun 13, 2018 at 03:23:09PM +0100, Daniel P. Berrangé wrote:
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.
Good. :)
> The options I see are:
> 1) complete daemonization before preconfig main loop
[...]
> 4) Not supporting -preconfig + -daemonize
[...]
> I believe the only reasonable options are (1) and (4).
Agreed.
If it was up to me, I would just go with (4) because it's
simpler.
But if somebody wants to implement (1), the caveats should be
clearly documented. I would prefer to simply document
"--daemonize --preconfig" as experimental, with something like:
"Note: usage of --daemonize with the --preconfig option is
experimental, because it can prevent QEMU from reporting
machine initialization errors and prevent some features from
working after QEMU is daemonized."
--
Eduardo