From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:44556) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rulgl-0007lL-By for qemu-devel@nongnu.org; Tue, 07 Feb 2012 09:06:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RulgY-00058U-De for qemu-devel@nongnu.org; Tue, 07 Feb 2012 09:06:31 -0500 Received: from mail-bk0-f45.google.com ([209.85.214.45]:49262) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RulgY-00058K-1T for qemu-devel@nongnu.org; Tue, 07 Feb 2012 09:06:18 -0500 Received: by bkbzu17 with SMTP id zu17so6289341bkb.4 for ; Tue, 07 Feb 2012 06:06:16 -0800 (PST) Message-ID: <4F312FD3.5020206@zerto.com> Date: Tue, 07 Feb 2012 16:06:11 +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> In-Reply-To: <4F311BBA.8000708@codemonkey.ws> 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: Anthony Liguori Cc: Kevin Wolf , =?UTF-8?B?16LXldeT15Mg16fXk9ed?= , dlaor@redhat.com, =?UTF-8?B?16rXldee16gg15HXnyDXkNeV16g=?= , qemu-devel@nongnu.org On 07/02/2012 14:40, Anthony Liguori wrote: > On 02/07/2012 06:30 AM, Ori Mamluk wrote: >>> In addition, I don't see that the listener thread holds any lock while >> it reads the image. I guess that during that period the guest runs >> and may >> race w/ this new thread. >> >> Yes - I mentioned that in the patch mail as one of the open issues. Can >> you direct me to the lock I need? The function I call from a new thread >> context is bdrv_aio_readv. > > One thing that has me confused about this proposal. Why not just make > rehub be an iSCSI target provider and call it a day? > You've got a point there. This also goes with what Kevin wrote about splitting the IOs with a block driver and not at the generic level. 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? 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? * 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? * What can you say about NBD via iScsi - with respect to our requirements- who is more mature in Qemu? 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. > Regards, > > Anthony Liguori > >> >> -----Original Message----- >> From: Dor Laor [mailto:dlaor@redhat.com] >> Sent: Tuesday, February 07, 2012 2:25 PM >> To: Anthony Liguori >> Cc: Ori Mamluk; Kevin Wolf; qemu-devel@nongnu.org >> Subject: Re: [Qemu-devel] [RFC PATCH] replication agent module >> >> On 02/07/2012 02:12 PM, Anthony Liguori wrote: >>> Hi, >>> >>> On 02/07/2012 04:29 AM, Ori Mamluk wrote: >>>> Repagent is a new module that allows an external replication system >>>> to replicate a volume of a Qemu VM. >>>> >>>> This RFC patch adds the repagent client module to Qemu. >>> >>> Please read http://wiki.qemu.org/Contribute/SubmitAPatch >>> >>> In particular, use a tool like git-send-email and split this patch up >>> into more manageable chunks. >>> >>> Is there an Open Source rehub available? As a project policy, adding >>> external APIs specifically for proprietary software is not something >>> we're willing to do. >>> >>> Regards, >>> >>> Anthony Liguori >> >> In addition, I don't see that the listener thread holds any lock >> while it >> reads the image. I guess that during that period the guest runs and may >> race w/ this new thread. >> >> About image ID for the replication hub, you can use the VM's pid or VM's >> uuid paired w/ the specific disk uuid >> >> Thanks, >> Dor >> >