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

[Ori Mamluk <omamluk@zerto.com>]

On 07/02/2012 17:47, Paolo Bonzini wrote:
> On 02/07/2012 03:48 PM, Ori Mamluk wrote:
>>> The current streaming code in QEMU only deals with the former.
>>> Streaming to a remote server would not be supported.
>>>
>> I need it at the same time. The Rephub reads either the full volume or
>> parts of, and concurrently protects new IOs.
>
> 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.
>
> But I'm also starting to wonder whether it would be simpler to use 
> existing replication code.  DRBD is more feature-rich, and you can use 
> it over loopback or NBD devices (respectively raw and non-raw), and 
> also store the replication metadata on a file using the loopback 
> device. Ceph even has a userspace library and support within QEMU.
>
I think there are two immediate problems that drbd poses:
1. Our replication is not a simple mirror - it maintains history. I.e. 
you can recover to any point in time in the last X hours (usually 24) at 
a granularity of about 5 seconds.
To be able to do that and keep the replica consistent we need to be 
notified for each IO.
2. drbd is 'below' all the Qemu block layers - if the protected volume 
is qcow2 then drbd doesn't get the raw IOs, right?

Ori