[Top][All Lists]
[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: |
Fri, 17 Jun 2011 10:50:56 -0300 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Fri, Jun 17, 2011 at 10:36:21AM +0200, Kevin Wolf wrote:
> Am 16.06.2011 16:52, schrieb Marcelo Tosatti:
> > 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.
>
> Why maintain it in memory? We already have mechanisms to track this in
> COW image formats, so that you can even continue after a crash.
Which mechanism is that? You'd need separate metadata for image
streaming purposes, since you might want the destination-image to
use a backing image itself.
> We can still add a raw-cow driver that maintains the COW data in memory
> for allowing raw copies, if this is needed.
- Re: [Qemu-devel] Image streaming and live block copy, (continued)
- Re: [Qemu-devel] Image streaming and live block copy, Dor Laor, 2011/06/19
- Re: [Qemu-devel] Image streaming and live block copy, Stefan Hajnoczi, 2011/06/24
- Re: [Qemu-devel] Image streaming and live block copy, Dor Laor, 2011/06/26
- Re: [Qemu-devel] Image streaming and live block copy, Kevin Wolf, 2011/06/27
- Re: [Qemu-devel] Image streaming and live block copy, Dor Laor, 2011/06/27
- Re: [Qemu-devel] Image streaming and live block copy, Kevin Wolf, 2011/06/17
- Re: [Qemu-devel] Image streaming and live block copy, Stefan Hajnoczi, 2011/06/17
- Re: [Qemu-devel] Image streaming and live block copy, Kevin Wolf, 2011/06/17
- Re: [Qemu-devel] Image streaming and live block copy, Stefan Hajnoczi, 2011/06/17
- Re: [Qemu-devel] Image streaming and live block copy, Anthony Liguori, 2011/06/17
- Re: [Qemu-devel] Image streaming and live block copy,
Marcelo Tosatti <=
- Re: [Qemu-devel] Image streaming and live block copy, Marcelo Tosatti, 2011/06/17
Re: [Qemu-devel] Image streaming and live block copy (was: [PATCH 00/13] QED image streaming), Marcelo Tosatti, 2011/06/16