Re: [Qemu-devel] [PATCH 1/2] vmdk: support vmfsSparse files

[Paolo Bonzini <pbonzini@redhat.com>]

----- Original Message -----
> From: "Fam Zheng" <famz@redhat.com>
> To: "Paolo Bonzini" <pbonzini@redhat.com>
> Cc: qemu-devel@nongnu.org, kwolf@redhat.com
> Sent: Monday, August 12, 2013 3:31:44 AM
> Subject: Re: [PATCH 1/2] vmdk: support vmfsSparse files
> 
> On Sun, 08/11 18:13, Paolo Bonzini wrote:
> > VMware ESX hosts use a variant of the VMDK3 format, identified by the
> > vmfsSparse create type ad the VMFSSPARSE extent type.
> > 
> > It has 16 KB grain tables (L2) and a variable-size grain directory (L1).
> > In addition, the grain size is always 512, but that is not a problem
> > because it is included in the header.
> > 
> > The format of the extents is documented in the VMDK spec.  The format
> > of the descriptor file is not documented precisely, but it can be
> > found at http://kb.vmware.com/kb/10026353 (Recreating a missing virtual
> > machine disk (VMDK) descriptor file for delta disks).
> > 
> I don't have access to this link

It only works from Google.  Try Googling for "vmfssparse delta".

> , could you include some documents to
> this descriptor format in comment or commit message? IIRC, it's only the
> type be "VMFSSPARSE", right?

Yes.  And "VMFS" for the base (patch 2).

> What version of ESX has this format?

At least 4.0 and newer.

> This needs to be rebased, vmdk_add_extent() signature has been changed
> in:
> 
>     commit 8aa1331c09a9b899f48d97f097bb49b7d458be1c
>     Author: Fam Zheng <famz@redhat.com>
>     Date:   Tue Aug 6 15:44:51 2013 +0800
> 
>         vmdk: check granularity field in opening
> 
>         Granularity is used to calculate the cluster size and allocate r/w
>         buffer. Check the value from image before using it, so we don't
>         abort()
>         for unbounded memory allocation.
> 
>         Signed-off-by: Fam Zheng <famz@redhat.com>
>         Signed-off-by: Kevin Wolf <kwolf@redhat.com>
> 
> Since the new function is a variant of vmdk_open_vmdk3(), would you
> consider doing a tiny refactor and reduce duplication? And l1dir_size
> and granularity need to be checked, as in vmdk_open_vmdk4().

I am not sure how to refactor it... in fact, since I'm on vacation I
wouldn't mind if somebody else fixes the patch.  I can test it either
tomorrow or next week.

Paolo