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

[Ori Mamluk <omamluk@zerto.com>]

On 08/02/2012 10:55, Kevin Wolf wrote:
> Am 08.02.2012 07:10, schrieb Ori Mamluk:
>> On 07/02/2012 17:47, Paolo Bonzini wrote:
>>>
>>> Why can't QEMU itself stream the full volume in the background, and
>>> send that together with any new I/O?  Is it because the rephub knows
>>> which parts are out-of-date and need recovery?  In that case, as a
>>> first approximation the rephub can pass the sector at which streaming
>>> should start.
>> Yes - it's because rephub knows. The parts that need recovery may be a
>> series of random IOs that were lost because of a network outage
>> somewhere along the replication pipe.
>> Easy to think of it as a bitmap holding the not-yet-replicated IOs. The
>> rephub occasionally reads those areas to 'sync' them, so in effect the
>> rephub needs read access - it's not really to trigger streaming from an
>> offset.
> So how does the rephub know which areas were touched by lost requests?
> Isn't qemu the only one who could know what it sent?
>
> Kevin
You're right. Currently only Qemu knows.
The problem is that if we move the responsibility to a layer below Qemu 
- then rephub will never know.
Our (Zerto's) solution for vmware has a different design, but it has 3 
parts relevant to this discussion:
1. Tapping to protected writes / read protected volume
2. Maintain a bitmap
3. Provide cross-VM consistency for recovery.

I want to simplify our design by taking it one step at a time.
My first goal for Qemu is to have only step 1 - meaning tap all 
protected writes, and be able to read.
I think it will be simpler for all of us to complete that first, and it 
provides a basic ability (though not optimal) for protection and recovery.

I think using an external streaming mechanism will make the next stages 
impossible.