Comment 11 for bug 350936

2010/5/5 Soren Hansen <email address hidden>:
>
> It's important to remember that libvirt intentionally does not kill VM's
> on termination. This enables us to upgrade libvirt without interruping
> running VM's, so we want to only conditionally shut down VM's.

Correct.

> What I've
> done on one of my Hardy boxes is to check $0 to see if the init script
> was invoked as K??libvirt-bin. If so, I assume we're being shut down and
> then I go and shut down the virtual machines. If invoked any other way,
> it just stops libvirt, not the VM's. To achieve something similar with
> upstart jobs, there's an environment variable that tells us why libvirt-
> bin is being stopped. This will reveal whether it's being shut down as a
> result of shutdown being called or whatnot.
>

But the problem is that the PIDs of the vm are not part of the libvirt-bin upstart job. Try to look my *ugly* workaround[1] :
/etc/init.d/sendsings is just parallelizing killing any process not in upstart pool of tracked ones. So, when upstart shutdown libvirt-bin, almost for sure libvirt-bin won't find any active guests because they have been killed before by /etc/init.d/sendsing (killing those vm processes seems very quick). While this is good for libvirt-bin independence from kvm guests processes, this make fine grain control of guests shutdown harder, and one may wonder if it's not kvm itelsef that should send ACPI shutdown signal to guests, and not libvirt.

I have another suspect: upstart may failing here. Doesn't libvirt-bin forks here to create kvm guests? Shouldn't "expect daemon" upstart stanza track daemons that fork more than once? If so, shouldn't libvirt-bin upstart job track these guests processes too? I have to ask in upstart mailing list.

[1] https://bugs.launchpad.net/ubuntu/+source/kvm/+bug/350936/comments/8