Problem solve Get help with specific problems with your technologies, process and projects.

Thin provisioning space reclamation issues with vSphere

Learn about space reclamation in a VMware environment, including how vSphere's Thin Provisioning Stun primitive works.

With VMware thin provisioning, what space reclamation issues do storage administrators need to be aware of?

There are a number of issues to consider regarding space reclamation. First, thin provisioning may be implemented in the storage hardware used to support the data stores. In general, it is perfectly acceptable to use thin provisioning in VMware and on the underlying storage platform at the same time. In fact, some vendor thin-provisioning implementations use large thin block sizes, which can result in better optimization using thin provisioning in both places. However, that means that two sets of monitoring processes are required, one for VMware and one for storage.

Using thin provisioning on the storage array can result in something known as "hole punching," where virtual machines (VMs) and data deleted in a VMDK are not released by the storage array and not immediately reused within the data store. The Unmap, or Thin Provisioning Stun, primitive was added to the vStorage APIs for Array Integration (VAAI) to resolve this problem. This allows vSphere to inform the storage array when data has been deleted and can be released from the LUN on which the data store is created. This feature was originally added with vSphere 4.1, but support for it was withdrawn by some vendors because of performance issues, so check with your storage vendor in advance of using this feature.

NFS data stores are by default thinly provisioned, so you don't need to create a VMDK with the thin attributes at create time; that way, space reclamation efforts are greatly simplified. VMDKs in NFS environments are effectively files allocated directly on the network-attached storage appliance.

Storage Distributed Resource Scheduler reserves additional capacity in addition to the consumed space in VMDKs when calculating the effective size of a VMDK during rebalancing tasks. By default, this value is 25% of the consumed capacity but can be overridden by changing the PercentIdleMBinSpaceDemand advanced parameter. In environments where data growth is low, a lower setting will result in more efficient space allocations.

Dig Deeper on Storage optimization