Re: [libvirt] [PATCH] qemu: Allow graceful domain destroy

On Mon, Aug 22, 2011 at 05:33:12PM +0100, Daniel P. Berrange wrote: > 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. Actually this entire thread is on the wrong path. Both the monitor 'quit' command and 'SIGTERM' in QEMU do exactly the same thing. A immediate stop of the guest, but with a graceful shutdown of the QEMU process[1]. In theory there is a difference that sending a signal is asynchronous and 'quit' is a synchronous command, but in practice this is not relevant, since while executio nof the 'quit' command is synchronous, this command only makes the *request* to exit. QEMU won't actually exit until the event loop processes the request later. There is thus no point in us even bothering with sending 'quit' to the QEMU monitor. The virDomainDestroy method calls qemuProcessKill which sends SIGTERM, waits a short while, then sends SIGKILL. It then calls qemuProcessStop to reap the process. This also happens to call qemuProcessKill again with SIGTERM, then SIGKILL. We need to make this more controllable by apps, by making it possible to send just the SIGTERM and not the SIGKILL. Then we can add a new flag to virDomainDestroy to request this SIGTERM only behaviour. If the guest does not actually die, the mgmt app can then just reinvoke virDomainDestroy without the flag, to get the full SIGTERM+SIGKILL behaviour we have today.

So there's no need for the QEMU monitor to be involved anywhere in this. Regards, Daniel [1] The SIGTERM handler and 'quit' command handler both end up just calling qemu_system_shutdown_request().