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

[Avi Kivity <avi@redhat.com>]

On 02/28/2011 08:56 PM, Marcelo Tosatti wrote:
> >
> >  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?

If you fail while qemu processes the command, you query it to see what 
it's current state.  You can simply re-issue the command; it's idempotent.

If qemu fails before you issue the switch you discard the new copy.  If 
it fails after the switch (whether it acked or not) you discard the 
original.

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

I think it has other advantages as well - code isolation, live migration 
compatibility, reduced switchover times.

Really the bad thing about the commit file is its un-documented-ness and 
ad-hoc nature which means the management tool is unlikely to get things 
right.

Qemu maintaining state is fine.  It already does - in block devices, and 
should do more.  We just have to take the right approach to do it (and 
be careful not to make it manage configuration).

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