From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:36875) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QXUUq-0006Ep-0b for qemu-devel@nongnu.org; Fri, 17 Jun 2011 04:33:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QXUUo-000351-Qc for qemu-devel@nongnu.org; Fri, 17 Jun 2011 04:33:43 -0400 Received: from mx1.redhat.com ([209.132.183.28]:1030) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QXUUo-00034u-BI for qemu-devel@nongnu.org; Fri, 17 Jun 2011 04:33:42 -0400 Message-ID: <4DFB1205.9040408@redhat.com> Date: Fri, 17 Jun 2011 10:36:21 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <1308075511-4745-1-git-send-email-stefanha@linux.vnet.ibm.com> <4DF9F899.5050301@redhat.com> <4DF9FBE4.9080300@redhat.com> <4DFA004E.9010001@redhat.com> <20110616145243.GB12173@amt.cnet> In-Reply-To: <20110616145243.GB12173@amt.cnet> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Image streaming and live block copy List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Marcelo Tosatti Cc: Anthony Liguori , Stefan Hajnoczi , jes sorensen , Dor Laor , qemu-devel@nongnu.org, Avi Kivity , Adam Litke 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. We can still add a raw-cow driver that maintains the COW data in memory for allowing raw copies, if this is needed. > - 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. Image streaming shouldn't write to the source. But adding a flag for this isn't a major problem. > 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. I think that should work. By the way, we'll get problems with the colon syntax. Without -blockdev we'll have to invent a new syntax, maybe with brackets: blkstream:[nbd:localhost]:out.qcow2 Kevin