From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:53296) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rv8zF-0006Dp-G8 for qemu-devel@nongnu.org; Wed, 08 Feb 2012 09:59:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rv8zB-0002uB-6R for qemu-devel@nongnu.org; Wed, 08 Feb 2012 09:59:09 -0500 Received: from mail-lpp01m010-f45.google.com ([209.85.215.45]:44119) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rv8zA-0002tu-SU for qemu-devel@nongnu.org; Wed, 08 Feb 2012 09:59:05 -0500 Received: by lahi5 with SMTP id i5so592950lah.4 for ; Wed, 08 Feb 2012 06:59:03 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <4F32788C.60904@zerto.com> 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:03 +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 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 repag= ent > and rephub. > It was suggested to use some standard network storage protocol instead, a= nd > 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 repor= t > writes. > =A0 =A0The tap is not a standard NBD backing - it is for replication, mea= ning > that its importance is lesser than > =A0 =A0the main image path. Errors are not reported to the protected VM a= s 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. I'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? Stefan