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

[Ori Mamluk]

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.