Re: [Qemu-devel] Re: [patch 2/3] Add support for live block copy

[Avi Kivity <avi@redhat.com>]

On 02/28/2011 07:33 PM, Anthony Liguori wrote:
>
> >
> > You're just ignoring what I've written.
>
> No, you're just impervious to my subtle attempt to refocus the 
> discussion on solving a practical problem.
>
> There's a lot of good, reasonably straight forward changes we can make 
> that have a high return on investment.
>

Is making qemu the authoritative source of configuration information a 
straightforward change?  Is the return on it high?  Is the investment low?

"No" to all three (ignoring for the moment whether it is good or not, 
which we were debating).

> The only suggestion I'm making beyond Marcelo's original patch is that 
> we use a structured format and that we make it possible to use the 
> same file to solve this problem in multiple places.
>

No, you're suggesting a lot more than that.

> I don't think this creates a fundamental break in how management tools 
> interact with QEMU.  I don't think introducing RAID support in the 
> block layer is a reasonable alternative.
>
>

Why not?

Something that avoids the whole state thing altogether:

- instead of atomically switching when live copy is done, keep on 
issuing writes to both the origin and the live copy
- issue a notification to management
- management receives the notification, and issues an atomic blockdev 
switch command

this is really the RAID-1 solution but without the state file (credit 
Dor).  An advantage is that there is no additional latency when trying 
to catch up to the dirty bitmap.

-- 
error compiling committee.c: too many arguments to function