qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v14 7/8] Implement new driver for block replicat


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [PATCH v14 7/8] Implement new driver for block replication
Date: Tue, 2 Feb 2016 14:34:13 +0000
User-agent: Mutt/1.5.24 (2015-08-30)

On Mon, Feb 01, 2016 at 09:13:36AM +0800, Wen Congyang wrote:
> On 01/29/2016 11:46 PM, Stefan Hajnoczi wrote:
> > On Fri, Jan 29, 2016 at 11:13:42AM +0800, Changlong Xie wrote:
> >> On 01/28/2016 11:15 PM, Stefan Hajnoczi wrote:
> >>> On Thu, Jan 28, 2016 at 09:13:24AM +0800, Wen Congyang wrote:
> >>>> On 01/27/2016 10:46 PM, Stefan Hajnoczi wrote:
> >>>>> On Wed, Jan 13, 2016 at 05:18:31PM +0800, Changlong Xie wrote:
> >>> I'm concerned that the bdrv_drain_all() in vm_stop() can take a long
> >>> time if the disk is slow/failing.  bdrv_drain_all() blocks until all
> >>> in-flight I/O requests have completed.  What does the Primary do if the
> >>> Secondary becomes unresponsive?
> >>
> >> Actually, we knew this problem. But currently, there seems no better way to
> >> resolve it. If you have any ideas?
> > 
> > Is it possible to hold the checkpoint information and acknowledge the
> > checkpoint right away, without waiting for bdrv_drain_all() or any
> > Secondory guest activity to complete?
> 
> There is no way to know that secondary becomes unreponsive.

I meant whether it is necessary for the Secondary to vm_stop() and apply
the checkpoint before acknowledging the checkpoint to the Primary?

> > I think this really means falling back to microcheckpointing until the
> > Secondary guest can checkpoint.  Instead of a blocking vm_stop() we
> > would prevent vcpus from running and when the last pending I/O finishes
> > the Secondary could apply the last checkpoint.  This approach does not
> > block QEMU (the monitor, etc).
> > 
> 
> If secondary host becomes unresponsive, it means that we cannot do 
> mocrocheckpointing.
> We should do failover in this case.

This is dangerous because it means that a delay/failure in the Secondary
would cause the Primary to fail over to the broken Secondary.  All the
more reason not to perform blocking operations on the Secondary in the
checkpoint code path.

Stefan

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]