On Fri, Dec 02, 2011 at 09:22:37 -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
Hmm, in that case I would rather introduce another detail VIR_DOMAIN_EVENT_SHUTDOWN_REQUESTED or something similar so that one can distinguish between a request that any guest can just ignore and a real shutdown. And more importantly, we need to decide what state a domain should be in after virDomainShutdown. IMHO it should still be "running" until we know the guest is really shutting down. Perhaps a new reason for "running" state that would mean the domain is running but a shutdown was requested could make sense.
ACK. Up to you whether to fold the examples/ change in now or as a followon patch, as long as you remember to do it.
Thanks, I sent a separate patch for adding the event to examples/domain-events/ and pushed this patch. Jirka