From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:59469) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RumLr-0007Hy-E4 for qemu-devel@nongnu.org; Tue, 07 Feb 2012 09:49:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RumLl-0006ez-LT for qemu-devel@nongnu.org; Tue, 07 Feb 2012 09:48:59 -0500 Received: from mail-bk0-f45.google.com ([209.85.214.45]:58369) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RumLl-0006em-5v for qemu-devel@nongnu.org; Tue, 07 Feb 2012 09:48:53 -0500 Received: by bkbzu17 with SMTP id zu17so6339862bkb.4 for ; Tue, 07 Feb 2012 06:48:51 -0800 (PST) Message-ID: <4F3139CE.4040103@zerto.com> Date: Tue, 07 Feb 2012 16:48:46 +0200 From: Ori Mamluk 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> In-Reply-To: <4F3137DB.1040503@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH] replication agent module List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Kevin Wolf , =?UTF-8?B?16rXldee16gg15HXnyDXkNeV16g=?= , =?UTF-8?B?16LXldeT15Mg16fXk9ed?= , dlaor@redhat.com, qemu-devel@nongnu.org On 07/02/2012 16:40, Paolo Bonzini wrote: > On 02/07/2012 03:06 PM, Ori Mamluk wrote: >> The main issue about it is that the Rephub also needs the other >> direction - to read the protected volume. I get the feeling that with >> live block copy and NBD there's probably something that might fit >> this need, no? > > Yes, with two NBD sockets you could do it. But would you use both at > the same time? I would have thought that either the rephub is > streaming from the protected volume, or QEMU is streaming to the rephub. > > The current streaming code in QEMU only deals with the former. > Streaming to a remote server would not be supported. > I need it at the same time. The Rephub reads either the full volume or parts of, and concurrently protects new IOs. >> With a 'new' agent like I need this is relatively easily achieved by a >> bidirectional protocol, but I agree a more generic protocol would be >> more elegant, although it will probably require a socket per >> direction, no? >> >> I Some smaller questions: >> * Is there already a working iScsi initiator as a block driver (I hope >> I'm using the right terminology) in Qemu, or do I need to write one? > > Yes, there is one using libiscsi. But I think Anthony was not > referring to iSCSI in particular, NBD would work just as well. > >> * This driver would need to be added in run-time - to allow starting to >> protect a running VM. Maybe via a monitor command. I guess that's OK, >> right? > > Yes, I think you can detach a block device from a drive and reattach > the new mirroring device. > >> * What can you say about NBD via iScsi - with respect to our >> requirements- who is more mature in Qemu? > > Personally I prefer NBD because it is lighter-weight and there is a > server inside QEMU (so you can use it easily with non-raw images). It > is more mature, but it is a bit less extensible. > I think we don't need an extensible or rich API, so NBD may fit. I'll look deeper into it. >> One more thing about the iScsi initiator - it will not be a standard >> backing for a drive, because the 'production' drive (i.e. the original >> image) is more important than the replicated one. This means that even >> though we use iScsi, this is still a replication agent - not a generic >> 'additional' iscsi backing. > > Yes, understood. > > Paolo