Why would a restored thin disk be smaller than original?

Short answer is that Ranger vddk backup-restore cycle produces smaller and cleaner disk.

Here is a long answer.

Thin disk generally takes less space on datastore. VMware allocates more blocks as requested by Guest OS. Thus thin disk may grow all the way until it hits provisioned size. What happens when Guest OS releases space, say, user deleted a huge number of files? From thin disk size point of view – nothing! Disk won’t shrink. At the moment there is no way to easily reclaim free space (check addendum 1).

There is another factor here – the way Windows treats deleted files. As we know, Windows does not clean space occupied by the deleted file right away but simply marks file as deleted. There are 3^rd party tools (undelete, unerase, etc.) that can recover deleted files. Thus we can’t claim that when some file is deleted, the blocks, occupied by the file, are clean. Microsoft has a special tool to clean those blocks – sdelete (addendum 2).

Now we have a bloated thin disk with bunch of clean blocks. How can we reclaim that unused space and make thin disk smaller? As per addendum 1, there are few suggestions, but in my tests not all of them worked. Suggestions are:

1. Run sdelete in Windows Guest and power VM down.
   sdelete -c -z
2. Clone bloated disk using vmkfstools. It did not work for me.
3. Migrate VM (Storage vMotion) to a datastore with a different block size. It makes no sense if VMFS5 is in use.
4. Migrate VM to an NFS datastore. Worked for me.

Ideally you should see much smaller thin disk.

What does Ranger do? Let’s clarify, we are talking about one of the vddk modes (SAN, HotAdd, NBD), not about COS (Service Console) based.

VDDK is smart enough to tell a dirty block from clean. If a clean block is identified, VDDK simply drops it and advances to the next one. Then VDDK pipes dirty (legitimate) blocks to the Ranger compression utility. Obviously, during restore thin disk will be restored with dirty blocks only, thus taking less space than original disk.

I conducted a following test that demonstrates this behavior:

1. VM1 with a single thin disk (8GB) was created. Server 2003 OS was installed. Thin disk was at 1.4GB
2. 2GB file was copied to the Guest, then deleted. Thin disk was at 3.4GB
3. sdelete utility was executed. Thin disk bloated more, 6.8GB. That is how sdelete works.
4. For clarity VM1 was powered down.
5. Ranger backup (Machine-based VDDK LAN) was taken.
6. VM (VM2) was restored from the backup taken at step 5. Thin disk is 1.6GB
7. Backup of restored VM (VM2) was taken.
8. VM (VM3) was restored from the backup taken in previous step. Thin disk is of the same size as in step 6 – 1.6GB.
9. VM (VM2) restored at step 6 has the cleanest and smallest thin disk with no clean blocks. Size of VM3 is another proof: no more clean blocks.

And for the final, does VMware do anything to make reclamation easy? Yes there is some progress. VMware is introducing a new feature in vSphere 5.1 (addendum 3) to help reclaim free space in Guests.

1. Addendums.
2. http://www.virtualizationteam.com/virtualization-vmware/vsphere-virtualization-vmware/vmware-esx-4-reclaiming-thin-provisioned-disk-unused-space.html
3. http://technet.microsoft.com/en-us/sysinternals/bb897443.aspx
4. http://www.vmware.com/files/pdf/techpaper/Whats-New-VMware-vSphere-51-Storage-Technical-Whitepaper.pdf
5. Commands to see a real size of a thin disk in ESX console:
   stat <disk>-flat.vmdk
   ls -asl <disk>-flat.vmdk
   du <disk>-flat.vmdk