qemu-devel
[Top][All Lists]
Advanced

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

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


From: Avi Kivity
Subject: Re: [Qemu-devel] Re: [patch 2/3] Add support for live block copy
Date: Tue, 01 Mar 2011 11:45:15 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Thunderbird/3.1.7

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




reply via email to

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