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@xxxxxxxxxx> > --- > 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?
Attachment:
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
