[libvirt] [PATCH 1/2] qemu: make sure capability probing process can start

[Jiri Denemark]

On Thu, Oct 09, 2014 at 10:45:50 +0100, Daniel Berrange wrote:
> On Thu, Oct 09, 2014 at 11:38:46AM +0200, Jiri Denemark wrote:
> > On Thu, Oct 09, 2014 at 10:14:48 +0100, Daniel Berrange wrote:
> > > On Thu, Oct 09, 2014 at 09:58:30AM +0200, Martin Kletzander wrote:
> > > > When daemon is killed right in the middle of probing a qemu binary for
> > > > its capabilities, the VM is left running.  Next time the daemon is
> > > > starting, it cannot start qemu process because the one that's already
> > > > running does have the pidfile flock()'d.
> > > 
> > > I was wondering if there's anything we can easily change in the way
> > > we launch the QEMU binary so that it automatically dies when libvirtd
> > > exits, rather than us needing to manually kill it.
> > > 
> > > The comments say we have to use daemonize to synchronize with the
> > > monitor socket creation and I recall we've tried other approaches
> > > to that before which failed.
> > > 
> > > Another idea would be to play with adding '-serial stdio' and then
> > > when libvirt died stdio would get a broken pipe but I don't think
> > > it is safe to use -serial when we have -M none so that's out.
> > > 
> > > So I guss we don't have much choice but to manually kill.
> > 
> > It would be cool if we could tell QEMU to die when the monitor
> > connection gets closed. Configuring some predefined actions to be taken
> > when monitor is closed would be useful in general... we could use that
> > to automatically cancel migration if QEMU loses connection with libvirt,
> > for example. I'm not sure how this idea would be taken by QEMU
> > community, though. I'll try to get opinions on it during KVM Forum. But
> > even if this is something that could be done, we'd still need Martin's
> > solution.
> 
> The real problem with this capabilities probing is that we really need
> to deal with whatever functionality was availble when '-M none' was
> first introduced. Otherwise we'll have to have 3 different ways of
> launching QEMU to probe for capabilities, which sucks even more than
> having 2 different ways

Hmm, that makes sense. However, the feature may still be useful :-)

Jirka