When VMware vSphere 4 introduced thin provisioning for the virtual machine disk files (VMDKs), many vSphere administrators were very excited to introduce this feature into the virtualized infrastructure. Thin provisioning basically consumes space only as the guest operating system consumes it. I like to equate this to the pie chart that Windows assigns for a drive letter to represent the usage. If a 40 GB C:\ drive is only using 18.5 GB, the pie chart would be almost half full. The VMDK file only consumes this amount as well when thin provisioning is in use.This is fine for initial provisioning and normal organic growth of a VMware virtual machine. One good representation of a virtual machine's disk usage is in the vSphere Client's Resources section, where a virtual machine's provisioned and used storage amounts are displayed. Figure A shows a file server in my personal lab displaying these allocations. Figure A
Click the image to enlarge.
From an ongoing planning perspective, this virtual machine has a lot of unallocated space, which can cause a problem if other virtual machines like this start to consume more of their allocation. The link to refresh storage usage is interesting; it will state how the virtual machine's consumption has increased, but it doesn't help much in reflecting decreased consumption.
The thin provisioned VMDK is really a one-way traffic phenomenon. While it can go down, if a large amount of disk consumption is removed, the storage usage display may not necessarily go down. Further, tricks like Storage vMotion (even converting the VMDKs to thick and back to thin) tasks don't necessarily decrease the consumption either. Because of this, a virtual machine can be created that may only consume 30 GB within the guest operating system, yet are displayed in the vSphere Client and within a VMDK of consuming much more.
In my lab, I have a SQL Server virtual machine that had a 100 GB database on it. I deleted the test database, and the size of the virtual machine within Windows went down to the 30 GB range. The vSphere Client still reports the 100 GB of data being used, even after a Storage vMotion task. The good news is that subsequent writes to the virtual machine (say, if I added a 40 GB database) would work within that already consumed allocation.
The only way to really decrement the usage is to have a new region within the VMDK, which is realistically best done with a new VMDK; this is impractical for day-to-day operations. If there is a special situation where a large amount of storage is reclaimed, that is maybe a reason for a one-off task.
Thin provisioning is not a holy grail of efficiency, but rather a convenience to help keep utilization high. From the storage perspective of thin provisioning, read a post by Chris Evans at the Storage Architect blog on this topic. Further, thin provisioning of VMDKs can cause undue contention for I/O resources on a datastore, which is an entirely separate discussion.
What experiences have you had with thin provisioning virtual machines and reclaiming space? Let us know in the discussion.
Rick Vanover is a software strategy specialist for Veeam Software, based in Columbus, Ohio. Rick has years of IT experience and focuses on virtualization, Windows-based server administration, and system hardware.