> -----Original Message----- > From: Dr. David Alan Gilbert [mailto:dgilb...@redhat.com] > 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; arm...@redhat.com; jc...@redhat.com > Subject: Re: [PATCH COLO v3 01/14] docs: block replication's description > > * Stefan Hajnoczi (stefa...@redhat.com) 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 > mode. > > > > > > 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?). Thx Eddie