qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Image streaming and live block copy


From: Marcelo Tosatti
Subject: Re: [Qemu-devel] Image streaming and live block copy
Date: Thu, 16 Jun 2011 11:52:43 -0300
User-agent: Mutt/1.5.21 (2010-09-15)

On Thu, Jun 16, 2011 at 03:08:30PM +0200, Kevin Wolf wrote:
> Am 16.06.2011 14:49, schrieb Avi Kivity:
> > On 06/16/2011 03:35 PM, Kevin Wolf wrote:
> >> * Image streaming is a normal image file plus copy-on-read plus a
> >> background task that copies data from the source image
> > 
> > Or a block-mirror started in degraded mode.
> 
> At least not in the same configuration as with live block copy: You
> don't want to write to the source, you only want to read from it when
> the destination doesn't have the data yet.
> 
> >> * Live block copy is a block-mirror of two normal image files plus a
> >> background task that copies data from the source image
> > 
> > = block-mirror started in degraded mode
> 
> >> The right solution is probably to implement COR and the background task
> >> in generic block layer code (no reason to restrict it to QED) and use it
> >> for both image streaming and live block copy. (This is a bit more
> >> complicated than it may sound here because guest writes must always take
> >> precedence over a copy - but doing complicated things is an even better
> >> reason to do it in a common place instead of duplicating)
> > 
> > Or in a block-mirror block format driver - generic code need not be 
> > involved.
> 
> Might be an option. In this case generic code is only involved with the
> stacking of BlockDriverStates, which is already implemented (but
> requires -blockdev for a sane way to configure things).
> 
> Kevin

What are the disadvantages of such an approach for image streaming,
versus the current QED approach?

blkstream block driver:

- Maintain in memory whether given block is allocated in local image,
if not, read from remote, write to local. Set block as local.
Local and remote simply two block drivers from image streaming driver
POV.
- Once all blocks are local, notify mgmt so it can switch to local
copy.
- Writes are mirrored to source and destination, minding guest writes
over copy writes.

Over this scheme, you'd have:

1) Block copy. 
Reopen image to be copied with
blkstream:/path/to/current-image:/path/to/destination-image,
background read sectors 0...N.

2) Image stream:
blkstream:remote-image:/path/to/local-image,
background read sectors 0...N.

Where remote-image is remote accessible image such as NBD.




reply via email to

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