In my company we are using VMware ESX servers (version 3.5.0 update 2) for our virtual environment. We have a couple of elderly Netapp filers which we use for shared NFS storage to host the virtual machines.

All in all we are quite happy with this solution, but as our storage capacity is running a bit low, I was extremely dissatisfied to find that moving virtual machines from storage to storage, would convert our thin provisioned disks to thick disks (a 30 gig harddrive with 10 gig data would fill 30 gig on the storage and not 10 gig).

As our Netapp filers are too old and slow to run deduplication I tried to use the “Shrink” function from the VMware Toolbox inside the virtual machines, hoping that this would convert the disks back to thin disks. But no luck there; this action actually expands the virtual disk to fill the maximum possible if it wasn’t already doing so!

I’m sure this behavior is not intended from VMware, and it will probably be fixed sometime in the future. But until then, I discovered a way to convert the disks back to thin disks while the virtual machines are running.

I take no responsibility for this procedure, and if you lose your virtual disks, don’t come blaming me, but roll back to your backup.

Here we go:

First of all, to get the most out of shrinking your disk, you should do the following inside the virtual machines.

1. Defragment your virtual disk

Use the build-in defrag-tool in Windows or a third part tool of your choice.

2. Shrink the disk using VMware tools inside the virtual machine

Go ahead and open the VMware toolbox and find the “Shrink” function

When you click the “Prepare to shrink” you start a two stage process; first the application fills all vacant space on the harddrive with large empty files

This process will take quite some time if you have a lot of unused space on your disk. If you look at the root of the harddrive, you’ll find that it simply generates a number of 2 gig files named “wiper0″, “wiper1″ etc..

These files are simply used to overwrite any “deleted” files on the disk; when Windows deletes a file, it doesn’t actually remove the data, it just removes any reference to it – therefore it still takes up space on your disk. The “wiper”-files allow ESX to identify truly unused blocks on your disk.

The next step the Toolbox is to supposed to do, is to tell the ESX host to do the Shrink

But unfortunately this is never done. Hence we need to do some additional work:

3. Take a snapshot of the virtual disk

This is done to have a static non-changing disk file to work on. When a snapshot is active, every change to the harddrive is written into a separate delta-file.

4. Open a session to an ESX host with access to the storage

Either use a SSH client or access the service console directly – make sure to be “root” before you try to proceed.

Change directory to where the virtual machines stores its files:

cd /vmfs/volumes/netapp10/Win2003helper/

In this example my storage is named “netapp10″ and the virtual machine is called “Win2003helper”.

A simple “ls -l” command reveals which files exists, the interesting ones are:

-rw-------    1 root     root     16795648 Oct  7 13:15 Win2003helper-000001-delta.vmdk
-rw-------    1 root     root          235 Oct  7 13:14 Win2003helper-000001.vmdk
-rw-------    1 root     root     8589934592 Oct  7 13:14 Win2003helper-flat.vmdk
-rw-------    1 root     root        19395 Oct  7 13:14 Win2003helper-Snapshot1.vmsn
-rw-------    1 root     root          406 Oct  7 12:59 Win2003helper.vmdk

The file “Win2003helper.vmdk” contains metadata about the actual harddisk file, which is named “Win2003helper-flat.vmdk”. As you can see we also have a snapshot in place; the .vmsn file contains metadata about the snapshot, and the aforementioned delta disk file is named “Win2003helper-000001-delta.vmdk” (with a matching metafile).

If you’re the curios type, you can do a “cat <filename>” to check out the content of meta files.

5. Make a “thin” clone of the snapshot

Now it’s time to do the magic! Use the “vmkfstool” command to make a clone of the virtual harddrive:

vmkfstools -i Win2003helper.vmdk -d thin Win2003helper_thin.vmdk

The “-d” option tells vmkfstools to make it a thin provisioned disk. The clone will be made from the non-changing snapshot (remember that changes are written to the delta-disk), so we don’t get into trouble with inconsistent drives.

Destination disk format: VMFS thin-provisioned
Cloning disk 'Win2003helper.vmdk'...
Clone: 100% done.

Wait for the cloning to finish. When it’s done, a “ls -l” will reveal the new disk:

-rw-------    1 root     root     8589934592 Oct  7 13:24 Win2003helper_thin-flat.vmdk
-rw-------    1 root     root          437 Oct  7 13:24 Win2003helper_thin.vmdk

You might be surprised to see that the file size is exactly the same at the bloated disk, you were hoping to shrink – but don’t panic, this is only due to the fact that the service console sees the size of the drive, and not how much space it occupies on the storage. Go ahead and browse the storage from the VMware Infrastructure Client, and you should see the true picture

6. Replace the thick disk with the thin clone

Go ahead and overwrite the thick disk with the clone just created:

mv -f Win2003helper_thin-flat.vmdk Win2003helper-flat.vmdk

And then remove the obsolete meta file “Win2003helper_thin.vmdk” either with the Datastore Browser or from the command line:

rm -f Win2003helper_thin.vmdk

7. Delete the snapshot

Finally you can delete the snapshot you created in the Snapshot Manager

Just press “Delete All”, and it will apply all changes that might have happened to the harddrive while we were cloning the disk.

8. Enjoy

If you take a look at the Datastore Browser, you will now find everything cleaned up, and the virtual disk shrunk to fit the actual usage in the virtual machine.

Of cause the file will grow as you add data to your virtual disk, and if you delete a lot of data, you might consider going thru the procedure again, to reclaim that space.