Re: [libvirt] KVM processes -- should we be able to attach them to the libvirtd process?

On Tue, May 05, 2009 at 04:13:38PM -0400, Hugh O. Brock wrote: > Not too long ago we took a patch that allowed QEMU VMs to keep running > even if libvirtd died or was restarted. > > I was talking to Matt Farrellee (cc'd) this afternoon about > manageability, and he feels fairly strongly that this behavior should be > optional -- in other words, it should be possible to guarantee that if > libvirtd dies, it will take all the VMs with the "die-with-libvirtd" > flag set down with it. > > I'm not sure this API is portable to Xen, but it would work on any > hypervisor that represents the VM as a normal process. > > Does this strike anyone else as useful behavior? This isn't really a model we want in the architecture. That the QEMU instances used to die when libvirtd died was an unfortunate artifact of the fact that QEMU was the parent process leader. These days all VMs are fully daemonized, so there is no parent/child relationship. In fact QEMU was really the odd-ball in this respect, because with Xen/OpenVZ/LXC and VirtualBox, VMs have always happily continued when libvirtd stopped or died, as do storage pools and virtual networks. This is important because it ensures we can automatically restart the libvirtd daemon during RPM upgrades, and provides robustness should a bug cause the daemon to crash - the daemon can be trivially restarted and continue with no interruption to services being managed. Daniel