[vbox-dev] VMDK inflation and grain alignment/padding
michal.necasek at oracle.com
Thu Feb 18 15:35:16 UTC 2016
You can read the specification yourself at
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.
On 2/18/2016 11:48 AM, Christian Svensson wrote:
> 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
> 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?
> vbox-dev mailing list
> vbox-dev at virtualbox.org
More information about the vbox-dev