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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list