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

[Daniel P. Berrange]

On Mon, Aug 22, 2011 at 12:49:48PM +0200, Michal Privoznik wrote:
> On 22.08.2011 12:27, Daniel P. Berrange wrote:
> > On Sat, Aug 20, 2011 at 01:06:10PM +0200, Michal Privoznik wrote:
> >> This patch introduces support for domain destroying via 'quit' monitor
> >> command which gives qemu time to flush caches and therefore prevent
> >> disks corruption. However, qemu can be unresponsive and to prevent
> >> waiting indefinitely, execute command in a separate thread and wait
> >> reasonable time (QEMU_QUIT_WAIT_SECONDS) on a condition. If we hit
> >> timeout, qemu is qemuProcessKill'ed which causes monitor close and
> >> therefore also thread being terminable.
> >>
> >> The synchronization between qemu driver and monitor-quit thread is done
> >> through mutex and condition. However, this alone is not enough. If a
> >> condition is signalized but without anybody listening signal is lost. To
> >> prevent this a boolean variable is used that is set iff nobody is
> >> listening but condition would be signalized, or iff driver is waiting on
> >> given condition.
> > 
> > If we want to talk to the monitor, then we can't do that in the
> > virDomainDestroy API call.
> > 
> > Your previous patches add a separate high priority queue to
> > libvirtd, for dispatch of RPC calls which do *not* use the monitor
> > which we need to always be processed immediately. virDomainDestroy
> > is one of those high priority calls. We can't do routing of the RPC
> > call based on flag values for the API, therefore, we must *never* use
> > the monitor from virDomainDestroy.
> > 
> > Regards,
> > Daniel
> 
> I don't think that's problem. High priority calls must be guaranteed to
> end in reasonably short time. And although we talk to monitor here, we
> are guaranteed to end. Therefore no need to change my previous patch.

In order to guarentee that it ends though, it is defining another
arbitrary timeout for the monitor commands, this time at 5 seconds.
What if the management app wants to wait more than 5 seconds before
falling back to kill(TERM) for QEMU ?

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.

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