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@virtualbox.org > https://www.virtualbox.org/mailman/listinfo/vbox-dev > _______________________________________________ vbox-dev mailing list vbox-dev@virtualbox.org https://www.virtualbox.org/mailman/listinfo/vbox-dev