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

[Matthew Farrellee <matt redhat com>]

Daniel P. Berrange wrote:
> 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

It doesn't appear to be the case that the libvirtd daemon can trivially
restart and continue with no interruptions. Right now it loses track of VMs.

In a scenario where VMs are not deployed and locked to specific physical
nodes, it can be highly valuable to have ways to ensure a VM is no
longer running when a layer of its management stops functioning.

Best,


matt