qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Kevin Wolf
Subject: Re: [Qemu-devel] [RFC PATCH] replication agent module
Date: Wed, 08 Feb 2012 11:04:10 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0

Am 08.02.2012 10:47, schrieb 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.

How could it change later on? If the network is down, qemu can't
communicate it to anyone else, so it stays the only one who 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.

Well, then we need to discuss all stages now. If you tell only part of
what you're going to do, you'll get a design that will only work for
part of what you need.

Kevin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]