OSX 10.11.6 : vboxmanage createhd fails when using options --variant Fixed,Split2G => fixed in SVN/5.1.x

[Karl]

When using vboxmanage the createhd fails when used with Fixed and Split2G. This works without these variants specified. This appears to have come into effect sometime between OSX 10.10.5 and OSX 10.11.6.

Basic things like disk space and volume type for the OSX installation were checked without any obvious issues like file size etc.

To replicate use the command

VBoxManage createhd --format VMDK --filename junk.vmdk --size 8192 --variant Fixed,Split2G

Full trace is :

$ VBoxManage createhd --format VMDK --filename build/junk.vmdk --size 8192 --variant Fixed,Split2G
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...
Progress state: VBOX_E_FILE_ERROR
VBoxManage: error: Failed to create medium
VBoxManage: error: Could not create the medium storage unit '/Users/x/DevBoot/Ubuntu-14.04/BaseBox/build/junk.vmdk'.
VBoxManage: error: VMDK: could not set size of new file '/Users/x/DevBoot/Ubuntu-14.04/BaseBox/build/junk-f005.vmdk' (VERR_INVALID_STATE)
VBoxManage: error: Details: code VBOX_E_FILE_ERROR (0x80bb0004), component MediumWrap, interface IMedium
VBoxManage: error: Context: "RTEXITCODE handleCreateMedium(HandlerArg *)" at line 449 of file VBoxManageDisk.cpp

[Socratis]

Actually, it's not the flags that are the problem. It's the size!

Something rang a bell when I realized that 8192 is exactly 4*2GB, so why would it fail on VMDK 5? There should be no need for a 5th VMDK. So, I started playing around with the size parameter and after (a lot of) trial and error I found out that the "magic" number is 8188 ^<1>. Below that it works. Above that it fails. So if I issue a '--size 8189', I get the same error as you. With '--size 8188' it works.

With (the latest as of this) build 109616, if I set '--size 8189', it simply gets stuck at 90% and 'VBoxManage' has to be killed -9, or Force Quit. The .vmdk files were already gone.

BTW, '--size 10230' works fine. I expect '--size 10240', which is exactly 5x2GB to fail.

^<1> Notice how 8188 is just short 4 MB of the goal of 4 VMDKs * 2GB/VMDK requested size. That would tell me that there's a 1 MB per VMDK header of sorts? And somewhere is not taken into account? Shooting in the dark here, but the same thing happens with 4GB; --size 4094 works, 4095 fails.

[aeichner]

Thanks for the report, this will be fixed in the next maintenance release (I ran into the same issue independently last week).

[Frank Mehnert]

Fix is part of 5.1.4.