Thin-provisioning is a method of optimizing storage performance efficiency by allocating disk space to each user based on the minimum storage space required by each user at any given time. One would expect that if the minimum storage space required by any given user were to decrease, the allocated storage on a thin-provisioned disk would decrease as well. The problem is it doesn’t.
At a time when virtualization, thin-provisioning and zero-detection SANs are becoming the de facto standards in corporate IT, there is a need for a simple tool that helps automate the recovery of wasted free space being held in virtual machines.
Deleting Data Alone Doesn’t Shrink a Thin-Provisioned Disk
If a customer creates a 100GB disk and only uses 20GB there will be a virtual disk on the ESX datastore that uses 20GB. If that customer performs an operation requiring another 40GB the virtual disk on the datastore expands to 60GB. When the 40GB of files are deleted, the user will find that the virtual disk is still 60GB in size. This means 40GB of space on the datastore is being wasted.
It is suggested that Sysinternal’s SDelete utility should be used to zero fill the free space on the virtual disk. SDelete is slow and resource intensive but it works by creating a file the size of the total free space on the disk and filling that file with zeros. If an application on the virtual machine needs to write to the disk while SDelete is running there may be insufficient free space to complete the write. If the virtual machine is running SQL Server or Exchange these applications need to be shut down. If the machine is running as a print server then print services need to be shut down.
When SDelete runs you will see some expansion of the used storage because SDelete is creating a file that consumes all the free space. Once SDelete completes, you need to run a Storage VMotion on the virtual machine. This needs to be done to move the virtual disk to another datastore in order for the SHRINK to take place. After the VMotion our sample virtual disk should be back to about 20GB.