Why can't I resize a dynamic VDI with modifyhd command?
To use VBoxManage modifyhd
we have the following caveats:
- Drives need to be in .VDI or .VHD format.
- Drives must be in dynamic format, not fixed (a fixed disk can be converted to dynamic by creating a clone).
- Drive size will only affect the logical size, not the physical size.
- Shrinking a drive to equal or below its physical size is not possible.
- For shrinking the physical size we have to fill unused drive space with
0
. - A Windows VDI may have to be defragmented before shrinking its physical size.
In the example above it was tried to resize a dynamic disk with a physical size of 4693 MB to 2000 MB, which is not possible. Hence the error.
This workaround worked for me:
- Shutdown the machine
- Create a new drive via the admin interface with the size you want
Use VBoxManage clonemedium with the
--existing
flagVBoxManage clonemedium <source-guid> <destinatin-guid> --existing
Note: Now the new disk will be having the excess space as unallocated, and you will need to use gparted to extend the size to maximum.
Not sure why the VirtualBox guys couldn't use the above to implement this instead of throwing VBOX_E_NOT_SUPPORTED
... at least link to this :)
Here is the whole process, I will try to be as detailed as possible
- Make sure that the machine that you are going to grow in size is in "Shutdown" state (not in "saved" or any other state)
In my case it is a 32 GB size machine and will call it the SMALL VM
- Create a new Virtual Machine with the new desired size
In my case I decided to make a new a 70 GB Virtual Machine, while restoring the contents of the small machine inside this new VM and I will refer to this as the LARGE VM
- Run the command
VBoxManage list hdds
or Open the Virtual Media Manager to obtain the the GUID of the SMALL VM (origin) and also the GUID of the LARGE VM (destination)
With those GUIDs build the following command
VBoxManage clonemedium SMALL_VM_GUID LARGE_VM_GUID --existing
In my case ORIGIN - SMALL VM is: 39143127-42b6-478a-afb2-5e58f14218b
In my case DESINATION - LARGE VM is: bb808b5b-b88c-49b2-a646-3414af906d84
Of course your GUIDs are going to be different than mine
Make sure you dont invert the GUIDs otherwise the brand new machine will replace the contents of your existing machine !!!!
After making sure you did not mix origin with destination run this command:
$ VBoxManage clonemedium 39143127-42b6-478a-afb2-5e58f14218b2 bb808b5b-b88c-49b2-a646-3414af906d84 --existing
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
Clone medium created in format 'VDI'. UUID: bb808b5b-b88c-49b2-a646-3414af906d84
Start the new LARGE VM that you created on step 2.
Check in the Computer Managment window tool that the machine has in fact more size unused/unformat space
If you prefer you can run the "chkdsk" on the C drive to make sure everything is ready (this might take you two reboots on the LARGE VM)
Using the gparted-live*.iso, "insert it" into the new virtual machine and reboot it
Boot into the gparted environment
Grow your partition and save changes
"Eject" the gparted-live*.iso to boot again into Windows
Check in the Computer Management window tool that the machine now has a bigger C drive to solve your spece issues
I had the screenshots of these process but decided not to include them since it will make my answer to big and intimidating for people who are "in a hurry" to get free space on their Windows virtual machine