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 Farellee (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
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|