Re: [Qemu-devel] [RFC PATCH] replication agent module

From: Ori Mamluk <omamluk@zerto.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: "Kevin Wolf" <kwolf@redhat.com>, "עודד קדם" <oded@zerto.com>,
	dlaor@redhat.com, "תומר בן אור" <tomer@zertodata.com>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [RFC PATCH] replication agent module
Date: Tue, 07 Feb 2012 16:06:11 +0200	[thread overview]
Message-ID: <4F312FD3.5020206@zerto.com> (raw)
In-Reply-To: <4F311BBA.8000708@codemonkey.ws>

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
>>
>