From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:54220) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QRhPz-0005Gu-Fr for qemu-devel@nongnu.org; Wed, 01 Jun 2011 05:08:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QRhPw-0005vh-60 for qemu-devel@nongnu.org; Wed, 01 Jun 2011 05:08:46 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42592) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QRhPv-0005vG-Cn for qemu-devel@nongnu.org; Wed, 01 Jun 2011 05:08:43 -0400 Message-ID: <4DE60243.7050007@redhat.com> Date: Wed, 01 Jun 2011 11:11:31 +0200 From: Kevin Wolf MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Alexander Graf Cc: Stefan Hajnoczi , qemu-devel@nongnu.org, Fam Zheng Am 01.06.2011 10:49, schrieb Alexander Graf: > > On 01.06.2011, at 06:29, Stefan Hajnoczi wrote: > >> On Sun, May 29, 2011 at 2:19 PM, Fam Zheng wrote: >>> As a project of Google Summer of Code 2011, I'm now working on >>> improving VMDK image support. There are many subformats of VMDK >>> virtual disk, some of which have separate descriptor file and others >>> don't, some allocate space at once and some others grow dynamically, >>> some have optional data compression. The current support of VMDK >>> format is very limited, i.e. qemu now supports single file images, but >>> couldn't recognize the widely used multi-file types. We have planned >>> to add such support to VMDK block driver and enable more image types, >>> and the working timeline is set in weeks (#1 to #7) as: >>> >>> [#1] Monolithic flat layout support >>> [#2] Implement compression and Stream-Optimized Compressed Sparse >>> Extents support. >>> [#3] Improve ESX Server Sparse Extents support. >>> [#4] Debug and test. Collect virtual disks with various versions and >>> options, test qemu-img with them. By now some patches may be ready to >>> deliver. >>> [#5, 6] Add multi-file support (2GB extent formats) >>> [#7] Clean up and midterm evaluation. >> >> Thanks to Fam's work, we'll hopefully support the latest real-world >> VMDK files in qemu-img convert within the next few months. >> >> If anyone has had particular VMDK "problem files" which qemu-img >> cannot handle, please reply, they would make interesting test cases. > > There is one very useful use-case of VMDK files that we currently don't support: remapping. > > A vmdk file can specify that it really is backed by a raw block device, but only for certain chunks, while other chunks of it can be mapped read-only or zero. That is very useful when passing in a host disk to the guest and you want to be sure that you don't break other partitions than the one 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 there. 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. Basically, additionally to the three cluster types "read from this image", "COW from backing file" and "zero cluster" we could introduce a fourth one "read/write to backing file". Kevin