From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:53039) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QTXjB-0005hX-GH for qemu-devel@nongnu.org; Mon, 06 Jun 2011 07:12:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QTXj9-00048u-T8 for qemu-devel@nongnu.org; Mon, 06 Jun 2011 07:12:13 -0400 Received: from mail-gw0-f45.google.com ([74.125.83.45]:39528) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QTXj9-00048k-B6 for qemu-devel@nongnu.org; Mon, 06 Jun 2011 07:12:11 -0400 Received: by gwb19 with SMTP id 19so1699201gwb.4 for ; Mon, 06 Jun 2011 04:12:10 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4DECB538.7010901@redhat.com> References: <4DE60243.7050007@redhat.com> <8265567F-3763-41AB-AA1D-CFCA5473D894@suse.de> <4DECA2FE.3020002@redhat.com> <4DECB538.7010901@redhat.com> Date: Mon, 6 Jun 2011 12:12:10 +0100 Message-ID: From: Stefan Hajnoczi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] VMDK development plan for Summer of Code 2011 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Fam Zheng , Alexander Graf , qemu-devel@nongnu.org On Mon, Jun 6, 2011 at 12:08 PM, Kevin Wolf wrote: > Am 06.06.2011 12:53, schrieb Stefan Hajnoczi: >> On Mon, Jun 6, 2011 at 10:50 AM, Kevin Wolf wrote: >>> Am 02.06.2011 00:11, schrieb Stefan Hajnoczi: >>>> On Wed, Jun 1, 2011 at 10:13 AM, Alexander Graf wrote: >>>>> >>>>> On 01.06.2011, at 11:11, Kevin Wolf wrote: >>>>> >>>>>> Am 01.06.2011 10:49, schrieb Alexander Graf: >>>>>>> There is one very useful use-case of VMDK files that we currently d= on't support: remapping. >>>>>>> >>>>>>> A vmdk file can specify that it really is backed by a raw block dev= ice, but only for certain chunks, while other chunks of it can be mapped re= ad-only or zero. That is very useful when passing in a host disk to the gue= st and you want to be sure that you don't break other partitions than the o= ne you're playing with. >>>>>>> >>>>>>> It can also shadow map those chunks. For example on the case above,= the MBR is COW (IIRC) for the image, so you can install a bootloader in th= ere. >>>>>> >>>>>> Hm, wondering if that's something to consider for qcow2v3, too... Do= you >>>>>> think it's still useful when doing this on a cluster granularity? It >>>>>> would only work for well-aligned partitions then, but I think that >>>>>> shouldn't be a problem for current OSes. >>>>> >>>>> Well, we could always just hack around for bits where it overlaps. Wh= en passing in a differently aligned partition for example, we could just de= clare the odd sector as COW sector and copy the contents over :). Though th= at might not be what the user really wants. Hrm. >>>>> >>>>>> Basically, additionally to the three cluster types "read from this >>>>>> image", "COW from backing file" and "zero cluster" we could introduc= e a >>>>>> fourth one "read/write to backing file". >>>>> >>>>> Yup, sounds very much straight forward! Then all we need is some tool= to create such a qcow file :) >>>> >>>> If we want to implement mini-device mapper why not do it as a separate >>>> BlockDriver? =A0This could be useful for non-qcow2 cases like *safely* >>>> passing through a physical disk with a guarantee that you won't >>>> destroy the MBR. =A0Also if we do it outside of an image format we don= 't >>>> need to worry about clusters and can do sector-granularity mapping. >>>> >>>> In fact, if we want mini-device mapper, that could be used to >>>> implement the VMDK multi-file support too. =A0So if Fam writes a gener= ic >>>> BlockDriver extent mapper we can use it from VMDK but also from >>>> command-line options that tie together qcow2, qed, raw, etc images. >>> >>> Does it really work for Alex' case, where you have some parts of an >>> image file that you want to be COW and other parts that write directly >>> to the backing file? >>> >>> Or to put it in a more general way: Does it work when you reference an >>> image more than once? Wouldn't you have to open the same image twice? >> >> Here is an example of booting from a physical disk: >> >> [mbr][/dev/zero][/dev/sda] >> >> mbr is a COW image based on /dev/sda. >> >> /dev/zero is used to protect the first partition would be. =A0The guest >> only sees zeroes and writes are ignored because the guest should never >> access this region. >> >> /dev/sda is the extent containing the second partition (actually we >> could just open /dev/sda2). >> >> Here we have the case that you mentioned with /dev/sda open as the >> read-only backing file for mbr and as read-write for the second >> partition. =A0The question is are raw images safe for multiple opens >> when at least one is read-write? =A0I think the answer for raw is yes. >> It is not safe to open non-raw image files multiple times. > > Yes, it would work for raw images. But should we really introduce > concepts that only work with raw images? > >> I'm also wondering if the -blockdev backing_file=3D option that >> has been discussed could be used in non-raw cases. =A0Instead of opening >> backing files by name, specify the backing file block device on the >> command-line so that the same BlockDriverState is shared, avoiding >> inconsistencies. >> >> The multiple opener issue is orthogonal to device mapper support. > > Well, no. If the only use case for the device mapper thing means that we > need to open images twice, there's no point in implementing it without > solving the multiple opener problem first. Protecting physical disk partitions is one use case, the other use case was for implementing VMDK multi-file support, which is why I mentioned Fam. Stefan