From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55257) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aQc2B-00078m-57 for qemu-devel@nongnu.org; Tue, 02 Feb 2016 09:34:24 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aQc25-0000Dj-SH for qemu-devel@nongnu.org; Tue, 02 Feb 2016 09:34:23 -0500 Received: from mx1.redhat.com ([209.132.183.28]:52789) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aQc25-0000DR-Kz for qemu-devel@nongnu.org; Tue, 02 Feb 2016 09:34:17 -0500 Date: Tue, 2 Feb 2016 14:34:13 +0000 From: Stefan Hajnoczi Message-ID: <20160202143413.GA32084@stefanha-x1.localdomain> References: <1452676712-24239-1-git-send-email-xiecl.fnst@cn.fujitsu.com> <1452676712-24239-8-git-send-email-xiecl.fnst@cn.fujitsu.com> <20160127144644.GL26163@stefanha-x1.localdomain> <56A96B34.9090906@cn.fujitsu.com> <20160128151543.GH9825@stefanha-x1.localdomain> <56AAD8E6.8020208@cn.fujitsu.com> <20160129154648.GE11427@stefanha-x1.localdomain> <56AEB140.3060509@cn.fujitsu.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="W/nzBZO5zC0uMSeA" Content-Disposition: inline In-Reply-To: <56AEB140.3060509@cn.fujitsu.com> Subject: Re: [Qemu-devel] [PATCH v14 7/8] Implement new driver for block replication List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Wen Congyang Cc: Kevin Wolf , Changlong Xie , Fam Zheng , zhanghailiang , fnstml-hwcolo@cn.fujitsu.com, qemu devel , Max Reitz , Gonglei , Paolo Bonzini --W/nzBZO5zC0uMSeA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 t= he > >>> Secondary becomes unresponsive? > >> > >> Actually, we knew this problem. But currently, there seems no better w= ay to > >> resolve it. If you have any ideas? > >=20 > > 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? >=20 > 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). > >=20 >=20 > If secondary host becomes unresponsive, it means that we cannot do mocroc= heckpointing. > 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 --W/nzBZO5zC0uMSeA Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWsL5lAAoJEJykq7OBq3PI47gIAKhyX1WESS7SJvQJJ+8bALGF TP9wVd6dSc9MifD7//NtWTIHPSjyLI4cfCkbH0JAXxm2rm/NV+yOQElww1Fdfc6F 2GG75ZNcfEp23rc31JTIqPc/hCcY/uYqIqiLz6nmKCNZjCwvqMuf9u7+kpk6yW/3 KD7T49/zeQFNfllKizDvGW2hkOEp0NSoMsmrYjnfutVmtao6GKjmV7nJBlBIvZQs T5jcTjr9WpfVILl5I4r5DZ7ENaaVjlKyDqwFRoAYQPov7XSXOf6642ZrAwVKKwbg 4qmMUE6n7sQKnPjkchMiPrml7LcGzlvyX+iJQopx5zQXnBwhGaEwwF1ElWXAMOo= =T85H -----END PGP SIGNATURE----- --W/nzBZO5zC0uMSeA--