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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list