On Tue, Sep 27, 2016 at 10:48:48AM +0100, Daniel P. Berrange wrote:
> On Mon, Aug 29, 2016 at 11:06:48AM -0400, Stefan Hajnoczi wrote:
> > At KVM Forum an interesting idea was proposed to avoid
> > bdrv_drain_all() during live migration.  Mike Cui and Felipe Franciosi
> > mentioned running at queue depth 1.  It needs more thought to make it
> > workable but I want to capture it here for discussion and to archive
> > it.
> > 
> > bdrv_drain_all() is synchronous and can cause VM downtime if I/O
> > requests hang.  We should find a better way of quiescing I/O that is
> > not synchronous.  Up until now I thought we should simply add a
> > timeout to bdrv_drain_all() so it can at least fail (and live
> > migration would fail) if I/O is stuck instead of hanging the VM.  But
> > the following approach is also interesting...
> How would you decide what an acceptable timeout is for the drain
> operation ?

Same as most timeouts: an arbitrary number :(.

> At what point does a stuck drain op cause the VM
> to stall ?

The drain call has acquired the QEMU global mutex.  Any vmexit that
requires taking the QEMU global mutex will hang that thread (i.e. vcpu


Attachment: signature.asc
Description: PGP signature

Reply via email to