[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH COLO v3 01/14] docs: block replication's descrip
Re: [Qemu-devel] [PATCH COLO v3 01/14] docs: block replication's description
Wed, 6 May 2015 02:26:46 +0000
> -----Original Message-----
> From: Dr. David Alan Gilbert [mailto:address@hidden
> Sent: Tuesday, May 05, 2015 11:24 PM
> To: Stefan Hajnoczi
> Cc: Paolo Bonzini; Wen Congyang; Fam Zheng; Kevin Wolf; Lai Jiangshan; qemu
> block; Jiang, Yunhong; Dong, Eddie; qemu devel; Max Reitz; Gonglei; Yang
> Hongyang; zhanghailiang; address@hidden; address@hidden
> Subject: Re: [PATCH COLO v3 01/14] docs: block replication's description
> * Stefan Hajnoczi (address@hidden) wrote:
> > On Fri, Apr 24, 2015 at 11:36:35AM +0200, Paolo Bonzini wrote:
> > >
> > >
> > > On 24/04/2015 11:38, Wen Congyang wrote:
> > > >> >
> > > >> > That can be done with drive-mirror. But I think it's too early for
> > > >> > that.
> > > > Do you mean use drive-mirror instead of quorum?
> > >
> > > Only before starting up a new secondary. Basically you do a
> > > migration with non-shared storage, and then start the secondary in colo
> > >
> > > But it's only for the failover case. Quorum (or a new block/colo.c
> > > driver or filter) is fine for normal colo operation.
> > Perhaps this patch series should mirror the Secondary's disk to a
> > Backup Secondary so that the system can be protected very quickly
> > after failover.
> > I think anyone serious about fault tolerance would deploy a Backup
> > Secondary, otherwise the system cannot survive two failures unless a
> > human administrator is lucky/fast enough to set up a new Secondary.
> I'd assumed that a higher level management layer would do the allocation of a
> new secondary after the first failover, so no human need be involved.
I agree. The cloud OS, such as open stack, will have the capability to handle
the case, together with certain API in VMM side for this (libvirt?).