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

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