[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



On Tue, Aug 23, 2011 at 02:36:02PM +0200, Michal Privoznik wrote:
> On 22.08.2011 20:31, Daniel P. Berrange wrote:
> > 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.
> 
> Sending signal to qemu process is just a part of domain destroying. What
> about cleanup code (emitting event, audit log, removing transient
> domain, ...)? Can I rely on monitor EOF handling code?  What should be
> the return value for this case when only SIGTERM is sent?

QEMU will send an event on the monitor when it shuts down cleanly
via 'SIGQUIT' - we already handle that.

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 :|


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]