Shrink VMDK - VMware

bbigford

One thing I've had a personal issue with... compared to other hypervisors, VMware has not made things very simple with disk shrinking. To shrink a VMDK, one has to turn off the previously used VM (or use the Powered On option and try to run it concurrently... which may or may not turn off the old VM, I've saw both situations in different environments. DNS will have no issue because the new VM is on DHCP) use VMware Standalone Converter, create a new VM during the process, leave the old VM off for DNS reasons, change the name of the old VM to something like DC2 - OLD SHRUNK (new changed from DC2.domain.com to DC2), change the NIC adapter IP properties, go back in and change the gateway because even though I defined it, everything else will stick but not the gateway (if you're on 6.0... vCenter is upgraded to 6.5 but previous provider didn't install out-of-band so I have to stay onsite an hour from home for the EXSi upgrade).

Using Essentials Plus. Got everything squared away after hours knowing what was going to break based on previous experience, but what a goddamn hassle to shrink a VMDK.

Emad R

@bbigford

Yeah your right, but I think this effects other Hypervisors as well.

one thing i heard they did with 6.5 was UNMAP storage, which automatically frees up the disk space, but you need storage array that supports it.

https://www.opvizor.com/whats-new-in-esxi-6-5-storage-part-i-unmap/

For me I had to:

1) wipe free space from inside the guest os prior:

Windows --> SDelete –z C:
Linux   --> cat /dev/zero > zero;sync;sleep 1;rm -r -f zero

2) vmkfstools --punchzero Windows_7_x32.vmdk

But it takes some time and needs the VM to powered off at some point.

zachary715

Yeah you're definitely going the long way here. If these are Windows VM's, you can do the following, although it does require some downtime. Downtime depends on the size of the VMDK.

In a thin VM, it will only utilize the storage space that it actually needs at a time, even if you provision more for it as a whole.  However, once you have increased the amount of used storage, even if you later cleanup and delete files from that VM, the .vmdk file will not reduce automatically.  Once you have cleared space, you have to manually go through the process of reclaiming that disk space.

NOTE: THIS PROCESS DOES REQUIRE SOME DOWNTIME, SO PLAN ACCORDINGLY.

NOTE: At step 3, running the sdelete command will fill the .vmdk to the provisioned file size. For instance, if you have a thin provisioned VM with 100GB of provisioned space and are only using 40GB currently, the sdelete utility will zero out the unused space causing the .vmdk to fill up to the full 100GB.  As a result, ensure that you have enough disk space on the server for this temporary growth until you can get to step 6 and reduce it back down.

1) Install SDelete tool from Microsoft on the Windows machine you want to reclaim disk space.

2) From an elevated command prompt, cd to the location of the SDelete utility (e.g. cd C:/Users/admin/Downloads/SDelete)

3) From this location, run the following command...

	sdelete.exe -z drive:\  (e.g. sdelete.exe -z C:\)

	This process will take some time depending on the size of the disk and amount of space it has to zero out.

4) Once completed, you will then need to shut down the VM as the next process requires the VM to be off to run properly.

5) Once shut down, SSH into the VM host which houses the VM using Putty or other utility.  CD to the datastore and volume where the .vmdk file is located. (e.g. cd /vmfs/volumes/datastore1/Server1)

6) Once in the VM's folder, run the following command on the .vmdk file to reclaim disk space...

	vmkfstools -K (disk).vmdk (e.g. vmkfstools -K Server1.vmdk)

	NOTE: Attempting to run this command on a .vmdk with spaces in the name (Server 1.vmdk vs Server1.vmdk) may cause the command to not be able to successfully run.  If you have created a VM with a space or foreign character in the name and .vmdk file, you may need to modify it before you can continue.

	NOTE: The K in this command MUST be capitalized. A lowercase k implies different actions.

	Allow this process to continue and when it is finished, power on the VM and ensure the disk space has been recovered and no issues are found.

zachary715

Option 2 would be to migrate the VM to a different datastore with dissimilar block size and specify "Thin Provision" when moving. If you have or can create a datastore with a block size different than your current config, then you can do this without downtime.

bbigford

@zachary715 said in Shrink VMDK - VMware:

Option 2 would be to migrate the VM to a different datastore with dissimilar block size and specify "Thin Provision" when moving. If you have or can create a datastore with a block size different than your current config, then you can do this without downtime.

Funny you mention that. I had forgotten about that method until this morning. I ended up using that method on the server (after creating a datastore using NFS share on a Synology appliance), using it strictly as a backup for a couple days to make sure things are good. I'll likely not use the conversion in the future; though they both took around the same amount of time to complete, the conversion was such a pain.