[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 1/2] vmdk: support vmfsSparse files
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [PATCH 1/2] vmdk: support vmfsSparse files |
Date: |
Mon, 12 Aug 2013 03:40:20 -0400 (EDT) |
----- 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.
Paolo