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

[Marcelo Tosatti]

On Mon, Feb 28, 2011 at 07:47:13PM +0200, Avi Kivity wrote:
> 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

How do you know if QEMU performed the switch or not? That is,
how can the switch command be atomic?

> 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.

So you're implementing a virtual block driver not visible to the user as
an image format. The image format would allow storage of persistent copy
progress, etc. so you lose all that.

All of that to avoid introducing a commit file which is not part of
global qemu state.