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: Thu, 24 Feb 2011 17:28:20 +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/24/2011 05:14 PM, Marcelo Tosatti wrote:
>  >>   The problem with qemu config files is that it splits the
>  >>   authoritative source of where images are stored into two.  Is it in
>  >>   the management tool's database or is it in qemu's config file?
>  >>
>  >>   For the problem at hand, one solution is to make qemu stop after the
>  >>   copy, and then management can issue an additional command to
>  >>   rearrange the disk and resume the guest.  A drawback here is that if
>  >>   management dies, the guest is stopped until it restarts.  We also
>  >>   make management latency guest visible, even if it doesn't die at an
>  >>   inconvenient place.
>  >>
>  >>   An alternative approach is to have the copy be performed by a new
>  >>   layered block format driver:
>  >>
>  >>   - create a new image, type = live-copy, containing three pieces of
>  >>   information
>  >>      - source image
>  >>      - destination image
>  >>      - copy state (initially nothing is copied)
>  >>   - tell qemu switch to the new image

There is a similar situation with atomicity here. Mgmt app requests a
switch and dies immediately, before receiving the command reply. Qemu
crashes. Which image is the uptodate one, source or live-copy?

live-copy (or it's new name, RAID-1). Once you've created it it is equivalent to source. Once it switches to state=synced you can switch back to either source or destination (I guess by telling qemu to detach the one you don't want first, so it falls back to state=degraded).


>  You could hot-unplug the image and hot-plug it later (continuing the
>  copy with qemu-img),

Then there's no need for live copy. qemu-img does that already.

It will start from the beginning.

>  or live migrate it.

You can live migrate (but not live migrate with live block migration)
with live copy in progress, its just that its not supported yet.

A RAID-1 driver will work with block live migration too.

>  In fact I think a qemu RAID-1 driver
>  removes the restriction that you can't live-migrate and live-copy
>  simultaneously.

As mentioned its just an implementation detail.

I think it's an important one. It moves the code from the generic layer to a driver. It allows generic RAID-1 functionality (for high availablity).

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




reply via email to

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