From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49021) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yqds4-0005IM-5b for qemu-devel@nongnu.org; Fri, 08 May 2015 04:43:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yqds3-0007bC-1g for qemu-devel@nongnu.org; Fri, 08 May 2015 04:43:00 -0400 Date: Fri, 8 May 2015 09:42:50 +0100 From: Stefan Hajnoczi Message-ID: <20150508084250.GA11717@stefanha-thinkpad.redhat.com> References: <20150424020149.GL2723@ad.nay.redhat.com> <5539A78D.1020206@cn.fujitsu.com> <5539F4F6.10507@redhat.com> <5539F702.7040708@cn.fujitsu.com> <20150424085841.GC2139@work-vm> <553A070E.8030909@redhat.com> <553A0F18.4010501@cn.fujitsu.com> <553A0EA3.9080400@redhat.com> <20150427093741.GA15658@stefanha-thinkpad.redhat.com> <20150505152355.GN2126@work-vm> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nFreZHaLTZJo0R7j" Content-Disposition: inline In-Reply-To: <20150505152355.GN2126@work-vm> Subject: Re: [Qemu-devel] [PATCH COLO v3 01/14] docs: block replication's description List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Dr. David Alan Gilbert" Cc: Kevin Wolf , Fam Zheng , Lai Jiangshan , qemu block , armbru@redhat.com, jcody@redhat.com, Jiang Yunhong , Dong Eddie , qemu devel , Max Reitz , Gonglei , Paolo Bonzini , Yang Hongyang , zhanghailiang --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 05, 2015 at 04:23:56PM +0100, Dr. David Alan Gilbert wrote: > * Stefan Hajnoczi (stefanha@redhat.com) wrote: > > On Fri, Apr 24, 2015 at 11:36:35AM +0200, Paolo Bonzini wrote: > > >=20 > > >=20 > > > On 24/04/2015 11:38, Wen Congyang wrote: > > > >> >=20 > > > >> > 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? > > >=20 > > > Only before starting up a new secondary. Basically you do a migration > > > with non-shared storage, and then start the secondary in colo mode. > > >=20 > > > But it's only for the failover case. Quorum (or a new block/colo.c > > > driver or filter) is fine for normal colo operation. > >=20 > > 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. > >=20 > > 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. >=20 > 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. That doesn't help, after the first failover is too late even if it's done by a program. There should be no window during which the VM is unprotected. People who want fault tolerance care about 9s of availability. The VM must be protected on the new Primary as soon as the failover occurs, otherwise this isn't a serious fault tolerance solution. Stefan --nFreZHaLTZJo0R7j Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVTHcKAAoJEJykq7OBq3PIbMAH/Apr4R76MPn6BGDpehpv1dmI DzPlZ5bBNJil8N7LRg6WH75x+1btJ9NHNt+vnANfDOiZ72OuGXuBlHfx1/bPQPoN U+5XrT3pKy7GbeA4wgGMsNa8PqpDttxntFyqPZFLhf6azuNXFMCUlxB+H2HWBch1 W0X2UXpQL9j/dWgSXCq5mnXtMBXpq9joiiAZ4KyqQyyhrxG3i/6Dp36AeiVjlrul 1tNiBV2v7f9mmBzvwr6s3UtV4rcjx6W6g2ThPOPw9upx7nWYkBv1+5QTHqOxE2g0 pha5BGGnHB+aI2Ru7SZVZrw32EwApqvXPKySw3UN5Oo5N4lOtMmn0AS1EsDmTlA= =t9ZN -----END PGP SIGNATURE----- --nFreZHaLTZJo0R7j--