While it is a somewhat known fact that you used to be able to shrink disks using vmkfstools -X in ESX 2.x, the option was removed as of ESX 3.0. The reason for this probably stems from those few customers that were not familiar with using the command properly and ended up cutting off too much of the disk and corrupted their Guest OS file system as a result.
Ever since the option was removed there have been more experienced users wanting the option to be added back to vmkfstools as they are aware of the risks and want that ability again. For those people I just mentioned, I have a treat for you:
** Use this technique at your own risk. I do not and will not take responsibility for your corrupted vmdk’s as a result of following this process, whether correctly or incorrectly **
If you have ever taken a look at the descriptor file for a vmdk file, you will the “Extent description” section:
# Extent description
RW 52428800 VMFS “foo-flat.vmdk”
The value between ‘RW’ and ‘VMFS’ is the size of disk when divided by 512:
52428800 * 512 = 26843545600 (25G)
-rw——- 1 root root 26843545600 Sep 18 19:10 foo-flat.vmdk
-rw——- 1 root root 370 Sep 18 19:11 foo.vmdk
If you want to shrink (or increase) the size of your vmdk file, alter this value in the descriptor file to reflect your new desired size*. You can do with this ‘vi’ or ‘nano’:
* For this example I will to shrink the disk to 12.5G
# Extent description
RW 26214400 VMFS “foo-flat.vmdk”
After making this change you can use ‘vmkfstools -i’ to clone this disk:
# vmkfstools -i foo.vmdk foo_1.vmdk
Destination disk format: VMFS thick
Cloning disk ‘foo.vmdk’…
Clone: 100% done.
You will discover that the cloned disk now reflects the new size of 12.5G:
-rw——- 1 root root 13421772800 Sep 18 19:13 foo_1-flat.vmdk
-rw——- 1 root root 372 Sep 18 19:13 foo_1.vmdk
-rw——- 1 root root 26843545600 Sep 18 19:10 foo-flat.vmdk
-rw——- 1 root root 370 Sep 18 19:11 foo.vmdk
This technique will also work if you try to cold migrate the VM or Storage VMotion it. This would be less cumbersome than trying to play around with another disk at the command line during a simple shrink process. Change your values and then migrate the disks via VI Client/VC to a different datastore. This will reduce disk space required for this operation and it will be a whole lot cleaner than a manual clone with vmkfstools and then a remove of the original.
SVMotion would be the a favourable option for those that do not want to incur downtime for their VM.
I am just finding for this solution. Thank you so much for this useful post.
I was just looking for this idea. Very good study material. keep posting like this. Thanks.
It's *sick* how easy this was versus the other solutions I found. Bravo!
It's *sick* how easy this was versus the other solutions I found. Bravo!
I've used this method on vSphere to shrink a VMs HDD. Edited vmdk file to new size, cloned using 'vmkfstools -i' and then removed the old .vmdk and -flat.vmdk and replaced with the newly cloned one. It works fine but there is one problem I have not been able to solve: When you go to “Edit Settings” in vCenter and click on the “Hard disk 1”, there it still shows the old size. Does anyone know where from this information is read?
Where can I find the descriptor file ?
You can clone the VM. The VM cloned show the new size.
You can clone the VM. The VM cloned show the new size.
thanks very much, very helpful !
Great Post, very useful, thanks for sharing you’re knowledge.
my vmdk is 40gb but only 5gb was used so I tried to shrink it to 6gb (RW 12582912). The vmdk was cloned but grub bootloader failed to locate the boot partition (this is a linux VM)
Any idea why this is happening?
Hi all
Been trying this on a Windows 2008 R2 VM on a vSphere 4.1.0 host but the VM refuses to start.
I was reducing a thick 40 Go vmdk to a thick 25 Go (only 10 Go used in the original VMDK).
I have changed the information in the descriptor file and used vSphere Client to cold migrate it to another VMFS datastore.
The destination file was indeed doing 25 Go but the result is : unable to load operating system.
Any idea to help me making this work in vSphere 4.1 are welcomed.
I don’t really want to import those VMs
Thanks for your help
The technique seemed to work fine. Did you happen to shrink the filesystem within the guest OS first?
“The reason for this probably stems from those few customers that were not familiar with using the command properly and ended up cutting off too much of the disk and corrupted their Guest OS file system as a result.”
Basically, from the sound of it, you chopped the end off your windows filesystem. Unfortunately there is not much I can do to help you out of that one. If you still have a copy of the VM or a good set of backups, try using gparted to shrink NTFS first, then use the above method to shrink the VMDK.
Thanks for sharing, this works great!
yes you are spot on about shrinking the filesystem. with win2k8 there is buildin tool in server management under storage | disk management, right click and shrink.. we shrinked the thick 40G to thin 12G.
Online Storage vMotion made my Windows 2008 VM crash and then the vMotion failed. Offline works fine.
The procedure described is very dangerous, indeed. If you have not shrunk your partition within the operating system, you will be left with a corrupt filesystem. Any data that existed outside of the new extent size will be gone. Windows has a habit of scattering “immovable” system files well away from the start of the partition. If any of these file existed outside the extent, these will be lost and the system will most likely left unbootable.
Play it safe. Use Vmware converter to clone out to a new machine with your desired disk sizes. This is the only supported method of reducing the size of thick provisioned vDisks. If the operation fails, you still have your source VM to fall back on.
This method works like a champ! Just be double-triple sure to resize the Guest OS partition smaller before starting this. I also rounded the partition size up by 0.1GB to allow for calculation variances, e.g., 20GB = 20.1GB. Don’t forget to multiply by 1024 to get from GB to MB to KB to B then divide by 512 to get the value. 20.1GB x 1024 = 20582.4MB x 1024 = 21076377.6KB X 1024 = 21582210662.4B / 512 = 42152755.2, round up to 42152756 (value to use in VMDK file. CP your VMDK file first in case you mess up with VI! Also, the ‘cold migrate’ method shown above moves the VMDK file and deletes the original, so if you mis-calcuated and corrupted your Guest OS then you are out of luck. The VMKFSTOOLS method is safer, just connect the cloned disk to the VM, that way if it doesn’t boot you can go back to the original VMDK file and descriptor (that you copied before modifying, remember?) **This information is provided “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT.**
Nice shot man! It’s quite insane but when you have someone hanged by his balls this is very usefull!
Ok, so I have a vm that has 100GB allocated to it. I’ve already shrunk the filesystem on the vm-os to 50GB, now I need to run the procedure you have here to reduce the size of the .vmdk as needed. Here’s the problem: the datastore only has about 781MB free. Will I be able to run the procedure in this article, or do I need to have 50GB free for the clone?
This worked for me this morning – using Windows Server 2012 / vSphere 5.1.
Although its worth noting that the clone process changes the ddb.uuid value and the ddb.longContentID in the vmdk file – these can be changed back manually … something to be mindful of if your using apps that particular about the specific hardware – e.g. backup, or in my case DFSR.
I couldn’t get this to work, the volume remained the same size. I created a new vmdk of the size I wanted and used ghost.
As expensive as this software is I am really surprised that this has not been made easier by VMWare.
# vmkfstools -i foo.vmdk foo_1.vmdk
Destination disk format: VMFS thick
Cloning disk ‘foo.vmdk’…
Clone: 100% done. <— the correct number would be 50% done.
becose is half of the cloning of 25GB.
Lets say you have a 100 GB VMDK and you had it completely full at one point and started deleting 90% of the data. How do you know whether or not bits of data are at the end of the disk for you to shrink it and then cut the VMDK? Would you need to first defrag it to make sure all the data goes to the beginning?