From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:32906) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rv7be-0002rG-Su for qemu-devel@nongnu.org; Wed, 08 Feb 2012 08:30:48 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rv7ba-0008U3-LG for qemu-devel@nongnu.org; Wed, 08 Feb 2012 08:30:42 -0500 Received: from mail-pz0-f45.google.com ([209.85.210.45]:63584) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rv7ba-0008Tv-EX for qemu-devel@nongnu.org; Wed, 08 Feb 2012 08:30:38 -0500 Received: by dadp14 with SMTP id p14so584839dad.4 for ; Wed, 08 Feb 2012 05:30:37 -0800 (PST) Message-ID: <4F3278F7.3000804@codemonkey.ws> Date: Wed, 08 Feb 2012 07:30:31 -0600 From: Anthony Liguori MIME-Version: 1.0 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> <4F3271E3.50704@zerto.com> In-Reply-To: <4F3271E3.50704@zerto.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] Replication agent requirements (was [RFC PATCH] replication agent module) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ori Mamluk Cc: Kevin Wolf , dlaor@redhat.com, Stefan Hajnoczi , =?UTF-8?B?16rXldee16gg15HXnyDXkNeV16g=?= , qemu-devel@nongnu.org, =?UTF-8?B?16LXldeT15Mg16fXk9ed?= , Yair Kuszpet , Paolo Bonzini On 02/08/2012 07:00 AM, Ori Mamluk wrote: > Hi, > Following previous mails from Kevin and Dor, I'd like to specify the high level > requirements of a replication agent as I see them. > > 1. Report each write to a protected volume to the rephub, at an IO transaction > granularity > * The reporting is not synchronous, i.e. the write completion is not delayed > until the rephub received it. > * The IOs have to be the raw guest IOs - i.e. not converted to any sparse format > or another filter that alters the size/offset For now. I'm sure you'll eventually have a synchronous replication requirement. We're doomed to reinvent all of the Linux storage layer it seems. I think we really only have two choices: make better use of kernel facilities for this (like drbd) or have a proper, pluggable, storage interface so that QEMU proper doesn't have to deal with all of this. Gluster is appealing as a pluggable storage interface although the license is problematic for us today. I'm quite confident that we shouldn't be in the business of replicating storage though. If the answer is NBD++, that's fine too. Regards, Anthony Liguori