[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 1/2] vmdk: support vmfsSparse files
From: |
Fam Zheng |
Subject: |
Re: [Qemu-devel] [PATCH 1/2] vmdk: support vmfsSparse files |
Date: |
Mon, 12 Aug 2013 17:10:25 +0800 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Mon, 08/12 03:40, Paolo Bonzini wrote:
>
>
> ----- Original Message -----
> > From: "Fam Zheng" <address@hidden>
> > To: "Paolo Bonzini" <address@hidden>
> > Cc: address@hidden, address@hidden
> > 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 <address@hidden>
> > 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 <address@hidden>
> > Signed-off-by: Kevin Wolf <address@hidden>
> >
> > 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.
>
OK, I'll take it for your happy vocation. :)
--
Fam