[vbox-dev] VMDK inflation and grain alignment/padding

[Michal Necasek]

    Hi Christian,

  You can read the specification yourself at

  https://www.vmware.com/support/developer/vddk/vmdk_50_technote.pdf

  According to my reading of it, qemu-img produced an rater suspect 
image. You have a supposedly 64K grain but after decompression, there is 
only 49K of data. That's obviously a problem because what do you do with 
the missing 15K? You could make something up, but what? Zeros? All bits 
set? Random noise? There's no good answer.

  If I understood it correctly, in your case the inconsistent grain 
occurs at the end of the disk. Does that mean that the size of the disk 
in grains is larger than the size in sectors?

  At the end of a disk it would be possible to guess "what the user 
wanted" but if such a grain occurred in the middle, how do you deal with it?

  It might be interesting to check what VMware actually did with it -- 
what happened with the missing 15K of data? Is it actually in the 
imported disk or not?

  To be fair you probably asked qemu-img to do an impossible task. The 
grain size must be a power of two and greater than 4K, but your disk 
image apparently has a size that's not even a multiple of 2K. The VMDK 
spec also says that the capacity of the disk (extent) should be a 
multiple of the grain size. So you created a disk image that cannot be 
very well be represented as a VMDK.


     Regards,
        Michal

On 2/18/2016 11:48 AM, Christian Svensson wrote:
> Hi,
>
> I was debugging why my VMware products were able to accept an OVA but
> not VirtualBox.
> Turns out that the problem was that my underlying hard drive image was
> not aligned to the grain size (128 sectors in my case) and that caused
> VirtualBox to throw VERR_VD_VMDK_INVALID_FORMAT.
> For the record, this is a stream optimized VMDK generated by qemu-img.
>
> This is the code snippet from src/VBox/Storage/VMDK.cpp:vmdkFileInflateSync:
>
>      if (cbActuallyRead != cbToRead)
>          rc = VERR_VD_VMDK_INVALID_FORMAT;
>      return rc;
> }
>
> cbToRead is set to VMDK_SECTOR2BYTE(pExtent->cSectorsPerGrain). In my
> VMDK generated by qemu-img (qemu HEAD as of a few days back) this check
> fails for the last grain:
> cbActuallyRead: 50176, cbToRead: 65536
>
> Removing this check seems to provide a working result. The VM boots at
> least.
> For now I made sure to align my underlying drive image to a 64KiB
> boundary which solves the problem I'm having.
>
> Long term however my question is: Is this a problem on qemu-img's side
> or VirtualBox?
> Even if qemu-img shouldn't generate these VMDK files, is there any merit
> to removing the check out of compatibility with VMware products? Does
> the standard take a stance in any direction?
>
> Thanks,
> Christian
>
>
> _______________________________________________
> vbox-dev mailing list
> vbox-dev at virtualbox.org
> https://www.virtualbox.org/mailman/listinfo/vbox-dev
>