qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [libvirt] [PATCH v6 2/2] vl: fix use of --daemonize wit


From: Igor Mammedov
Subject: Re: [Qemu-devel] [libvirt] [PATCH v6 2/2] vl: fix use of --daemonize with --preconfig
Date: Thu, 14 Jun 2018 14:32:41 +0200

On Wed, 13 Jun 2018 14:09:32 -0300
Eduardo Habkost <address@hidden> wrote:

> 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.
Let's just disable it for now. it will be easier to allow it
than take it back later.

> 
> 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."





reply via email to

[Prev in Thread] Current Thread [Next in Thread]