Annoying, is the right word for this process. What it should involve is simply editing the settings of the VM in question, changing the size of the disk via the already provided UI widget, then hitting okay. Of course, you still need your OS or third party tool to resize the partition inside the virtual disk, but that should take care of the actual virtual disk sizing. Hey, it's not even too much of a stretch of the imagination to suggest you should be able to take a snapshot before attempting the resize so you can rollback if it fails.
But no. The UI widget does nothing. It looks cool, but making any changes results in precisely zero happening. It just reverts back to the original value when you click "ok". If you really want to resize the disk, you need to log onto the ESX server hosting the virtual disk and use the "vmkfstools" utility. So resizing a virtual disk from 4GB to 8GB is achieved like so: vmkfstools -X 8G virtualdisk.vmdk
Except that there's a few problems with this. Firstly, if your vm has any snapshots, kiss them goodbye, because you can't shrink the disk once it's explanded, and the snapshots now no longer match the underlying disk. Secondly, if you actually have any snapshots you can't remove them from inside the Virtual Infrastructure Client once you've resized the disk - it just errors out. Thirdly, it's likely that vmkfstools will not correctly resize the geometry parameters of the disk.
So how I fixed this was first of all, I manually edited the vmx file to remove the pointer to the incompatible snapshot. This involved changing the line that read "scsi0:0.fileName = "virtualdisk-000001.vmdk"" to "scsi0:0.fileName = "virtualdisk.vmdk"". I then deleted the snapshot files manually (the .vmdk and -flat.vmdk files associated with the snapshot.)
I then tried to get my partition utility to stretch the partition to fill the entire volume. Except it couldn't see past the existing size. I tried booting windows, and windows was able to see the full size and add another partition in the free space, but sadly couldn't stretch the active partition to fill the whole disk. [ I think Vista can do this, but probably not in 4GB of space ;) ]
Anyway, long story slightly shorter, turns out vmkfstools didn't adjust the geometry of the new disk correctly - the "cylinders" parameters were still on the old value of 522, not the new correct value of 1044. The specific lines were 'ddb.geometry.biosCylinders = "522"' and 'ddb.geometry.cylinders = "522"'. So then I was able to expand the partition, and everything was happy again.
Moral of the story is: resizing virtual disks is a lot harder than it should be and vmware could do more to ease the process (such as implement the scenario I outlined at the beginning of this post.)
No Comments