Re: [Qemu-devel] [RFC] Replication agent design (was [RFC PATCH] replication agent module)

[Stefan Hajnoczi <stefanha@gmail.com>]

On Wed, Feb 8, 2012 at 2:59 PM, Stefan Hajnoczi <stefanha@gmail.com> wrote:
> On Wed, Feb 8, 2012 at 1:28 PM, Ori Mamluk <omamluk@zerto.com> 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 repagent
>> and rephub.
>> It was suggested to use some standard network storage protocol instead, and
>> 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 report
>> writes.
>>    The tap is not a standard NBD backing - it is for replication, meaning
>> that its importance is lesser than
>>    the main image path. Errors are not reported to the protected VM as 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?

BTW, your design makes sense to me.

Stefan