From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:56340) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rv8zw-0006vp-5H for qemu-devel@nongnu.org; Wed, 08 Feb 2012 09:59:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rv8zm-0002zy-6K for qemu-devel@nongnu.org; Wed, 08 Feb 2012 09:59:51 -0500 Received: from mail-lpp01m010-f45.google.com ([209.85.215.45]:64674) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rv8zl-0002zu-Vb for qemu-devel@nongnu.org; Wed, 08 Feb 2012 09:59:42 -0500 Received: by lahi5 with SMTP id i5so593613lah.4 for ; Wed, 08 Feb 2012 06:59:40 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <73865e0ce364c40e0eb65ec6b22b819d@mail.gmail.com> <4F31153E.9010205@codemonkey.ws> <4F311839.9030709@redhat.com> <4F311BBA.8000708@codemonkey.ws> <4F312FD3.5020206@zerto.com> <4F3137DB.1040503@redhat.com> <4F3139CE.4040103@zerto.com> <4F314798.8010009@redhat.com> <4F3211D0.3070502@zerto.com> <4F323875.1000000@redhat.com> <4F3244C2.1040604@zerto.com> <4F32489A.80307@redhat.com> <4F32788C.60904@zerto.com> Date: Wed, 8 Feb 2012 14:59:40 +0000 Message-ID: From: Stefan Hajnoczi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC] Replication agent design (was [RFC PATCH] replication agent module) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ori Mamluk Cc: Kevin Wolf , =?UTF-8?B?16rXldee16gg15HXnyDXkNeV16g=?= , =?UTF-8?B?16LXldeT15Mg16fXk9ed?= , dlaor@redhat.com, qemu-devel@nongnu.org, Yair Kuszpet , Paolo Bonzini On Wed, Feb 8, 2012 at 2:59 PM, Stefan Hajnoczi wrote: > On Wed, Feb 8, 2012 at 1:28 PM, Ori Mamluk wrote: >> Hi, >> Thanks for all the valuable inputs provided so far, I'll try to suggest = a >> design based on them. >> The main inputs were about the use a new transport protocol between repa= gent >> and rephub. >> It was suggested to use some standard network storage protocol instead, = and >> use QMP commands for the control path. >> >> The main idea is to use two NBD connections per protected volume: >> NBD tap - protected VM is the client, rephub is the server, used to repo= rt >> writes. >> =A0 =A0The tap is not a standard NBD backing - it is for replication, me= aning >> that its importance is lesser than >> =A0 =A0the main image path. Errors are not reported to the protected VM = as IO >> error. > > You mentioned a future feature that sends request metadata (offset, > length) to the rephub synchronously so that protection is 100%. > (Otherwise a network failure or crash might result in missed writes > that the rephub does not know about.) > > The NBD tap might not be the right channel for sending synchronous > request metadata, since the protocol is geared towards block I/O > requests that include the actual data. =A0I'm not sure that QMP should > be used either - even though we have the concept of QMP events - > because it's not a low-latency, high ops communications channel. > > Which channel do you use in your existing products for synchronous > request metadata? BTW, your design makes sense to me. Stefan