On Fri, Dec 02, 2011 at 09:22:37AM -0700, Eric Blake wrote:
On 12/02/2011 08:02 AM, Jiri Denemark wrote:
When QEMU guest finishes its shutdown sequence, qemu stops virtual CPUs and when started with -no-shutdown waits for us to kill it using SGITERM. Since QEMU is flushing its internal buffers, some time may pass before QEMU actually dies. We mistakenly used "paused" state (and events) for this which is quite confusing since users may see a domain going to pause while they expect it to shutdown. Since we already have "shutdown" state with "the domain is being shut down" semantics, we should use it for this state.
However, the state didn't have a corresponding event so I created one and called its detail as VIR_DOMAIN_EVENT_SHUTDOWN_FINISHED (guest OS finished its shutdown sequence) with the intent to add VIR_DOMAIN_EVENT_SHUTDOWN_STARTED in the future if we have a sufficiently capable guest agent that can notify us when guest OS starts to shutdown.
Not for this patch, but should we use VIR_DOMAIN_EVENT_SHUTDOWN_STARTED any time we use the virDomainShutdown API to request a graceful shutdown? That is, by actually changing the state of the domain after a call to virDomainShutdown, it will be more apparent whether a user has previously requested shutdown, and if the guest is still running, it means the guest either didn't react to the ACPI interrupt or else is taking a long time to shut down.
I don't think we should do this in the lifecycle events. Not least because emitting "VIR_DOMAIN_EVENT_SHUTDOWN_STARTED" would be very misleading because a guest OS is free to ignore the ACPI power event. The lifecycle events should only reflect things that have actually happened to the guest VM lifecycle & I don't really this counts. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|