On Mon, Aug 22, 2011 at 09:29:56AM -0600, Eric Blake wrote:
On 08/22/2011 09:21 AM, Daniel P. Berrange wrote:
>If we had a separate API for sending 'quit' on the monitor, then the
>mgmt app can decide how long to wait for the graceful shutdown of QEMU
>before resorting to the hard virDomainDestroy command. If the app knows
>that there is high I/O load, then it might want to wait for 'quit' to
>complete longer than normal to allow enough time for I/O flush.
Indeed - that is exactly what I was envisioning with a
virDomainShutdownFlags() call with a flag to request to use the quit
monitor command instead of the default ACPI injection. The
virDomainShutdownFlags() would have no timeout (it blocks until
successful, or returns failure with no 'quit' command attempted),
and the caller can inject their own unconditional virDomainDestroy()
at whatever timeout they think is appropriate.
The virDomainShutdown API is really about guest initiated graceful
shutdown. Sending the 'quit' command to QEMU is still *ungraceful*
as far as the guest OS is concerned, so I think it is best not to
leverage the Shutdown API for 'quit'.
I think this probably calls for a virDomainQuit API.
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 :|