[libvirt] [PATCH] qemu: Report shutdown event details

[Martin Kletzander]

On Wed, Apr 12, 2017 at 05:04:37PM +0200, Peter Krempa wrote:
>On Wed, Apr 12, 2017 at 09:55:23 -0500, Eric Blake wrote:
>> On 04/12/2017 09:48 AM, Martin Kletzander wrote:
>> > QEMU will likely report the details of it shutting down, particularly
>> > the system it received in case it was killed.  We should forward that
>> > information along.  Since the only way we can extend information
>> > provided to the user is adding event details, we might as well emit
>> > multiple events (one with the reason for the shutdown and keep the one
>> > for the shutdown being finished for clarity and compatibility).
>> >
>> > Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1384007
>> >
>> > Signed-off-by: Martin Kletzander <mkletzan at redhat.com>
>> > ---
>> > This is waiting for a patch in QEMU [1] that I tested this with.
>> >
>> > [1] https://lists.gnu.org/archive/html/qemu-devel/2017-04/msg01098.html
>>
>> The discussion on the qemu patch says it will probably not expose signal
>> names, but merely a boolean of guest- vs. host-initiated.  So you'll
>> have to respin on top of whatever qemu settles on, but the idea is sane.
>>  You are correct that since we can't expand the existing event, we have
>> to add a second one, and wire up both events to fire at once (we've done
>> it before, so there's precedence).
>

Is it OK to have just another shutdown event detail or should I wire up
a new lifecycle event?

>Umm, yes, the signal names are kind of qemu/linux specific so we really

Not really, we have more hypervisors where VMs are processes that we
see, and even though the notion of "signals" doesn't exist in Windows
per se, it's not like you cannot be killed there.  Plus it's just one of
multiple platforms that we run on, all the other have signals ;)

>should only expose the fact whether the host or guest initiated the
>shutdown.

But I agree here.  If we draw a clear line between guest/host
initiation, which is not *that* clear [1] IMHO, then we're fine.
Especially when we leave the differentiation decision on the
hypervisor itself ;)

Have a nice day,
Martin

[1] For example what is it when you send an ACPI event to the guest from
    the host using virsh?  And what if it ignores that event, but then
    shuts down itself due to different reason right after that?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20170413/a473d861/attachment-0001.sig>