From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=53770 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Oszbw-0004sm-Jl for qemu-devel@nongnu.org; Tue, 07 Sep 2010 10:57:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Oszbs-00071K-Df for qemu-devel@nongnu.org; Tue, 07 Sep 2010 10:57:24 -0400 Received: from e5.ny.us.ibm.com ([32.97.182.145]:55728) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Oszbs-00071G-9h for qemu-devel@nongnu.org; Tue, 07 Sep 2010 10:57:20 -0400 Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by e5.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id o87Ebre2001050 for ; Tue, 7 Sep 2010 10:37:53 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o87EvJI0348542 for ; Tue, 7 Sep 2010 10:57:19 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o87EvHrI018113 for ; Tue, 7 Sep 2010 11:57:17 -0300 Message-ID: <4C8652CB.9060801@linux.vnet.ibm.com> Date: Tue, 07 Sep 2010 09:57:15 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] QEMU interfaces for image streaming and post-copy block migration References: <4C864118.7070206@linux.vnet.ibm.com> <4C864D65.6090004@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Kevin Wolf , "libvir-list@redhat.com" , qemu-devel , Stefan Hajnoczi On 09/07/2010 09:49 AM, Stefan Hajnoczi wrote: > On Tue, Sep 7, 2010 at 3:34 PM, Kevin Wolf wrote: > >> Am 07.09.2010 15:41, schrieb Anthony Liguori: >> >>> Hi, >>> >>> We've got copy-on-read and image streaming working in QED and before >>> going much further, I wanted to bounce some interfaces off of the >>> libvirt folks to make sure our final interface makes sense. >>> >>> Here's the basic idea: >>> >>> Today, you can create images based on base images that are copy on >>> write. With QED, we also support copy on read which forces a copy from >>> the backing image on read requests and write requests. >>> >>> In additional to copy on read, we introduce a notion of streaming a >>> block device which means that we search for an unallocated region of the >>> leaf image and force a copy-on-read operation. >>> >>> The combination of copy-on-read and streaming means that you can start a >>> guest based on slow storage (like over the network) and bring in blocks >>> on demand while also having a deterministic mechanism to complete the >>> transfer. >>> >>> The interface for copy-on-read is just an option within qemu-img >>> create. >>> >> Shouldn't it be a runtime option? You can use the very same image with >> copy-on-read or copy-on-write and it will behave the same (execpt for >> performance), so it's not an inherent feature of the image file. >> >> Doing it this way has the additional advantage that you need no image >> format support for this, so we could implement copy-on-read for other >> formats, too. >> > I agree that streaming should be generic, like block migration. The > trivial generic implementation is: > > void bdrv_stream(BlockDriverState* bs) > { > for (sector = 0; sector< bdrv_getlength(bs); sector += n) { > if (!bdrv_is_allocated(bs, sector,&n)) { > Three problems here. First problem is that bdrv_is_allocated is synchronous. The second problem is that streaming makes the most sense when it's the smallest useful piece of work whereas bdrv_is_allocated() may return a very large range. You could cap it here but you then need to make sure that cap is at least cluster_size to avoid a lot of unnecessary I/O. The QED streaming implementation is 140 LOCs too so you quickly end up adding more code to the block formats to support these new interfaces than it takes to just implement it in the block format. Third problem is that streaming really requires being able to do zero write detection in a meaningful way. You don't want to always do zero write detection so you need another interface to mark a specific write as a write that should be checked for zeros. Regards, Anthony Liguori