VAAI UNMAP was introduced in vSphere 5.0 to reclaim the free space when the VMs had to be moved or deleted from a datastore that is thin provisioned at the storage level. vSphere 6.0 introduced some improvements to UNMAP that facilitated the reclaiming of stranded space from within a guest OS.
But, in this case, the reclaim operation was performed manually, as described on KB 2057513—Using the esxcli storage vmfs unmap command to reclaim VMFS deleted blocks on thin-provisioned LUNs at https://kb.vmware.com/kb/2057513.
In vSphere 6.5 and with the new VMFS6, there is now an automated UNMAP mechanism for reclaiming the dead or stranded space on datastores. Now UNMAP runs continuously in the background if enabled at the datastore level.
There are currently two settings available—None and Low. Reclaim priority is only on or off. Low implies reclaim is enabled, whereas with None it is disabled. With the default setting of Low, the expectation is that any blocks that are no longer used will be reclaimed within 12 hours. Space reclamation settings are available both in vSphere Web Client and also in the new HTML5 client, under datastore properties:
Or also from the command line, for example using esxcli:
esxcli storage vmfs reclaim config set -l Datastore _Name -p {none|low}
What does it mean? Finally, you can use think provision at the storage side, and have automatic space reclaim. But note that available space could still not match between vSphere and storage view because LZT VMDKs do not use storage space unless you are writing new blocks (at storage level those virtual disks are quite similar to thin VMDKs).
In vSphere 6.0, there was limited in-guest UNMAP (note that TRIM is the ATA equivalent of SCSI UNMAP) support for reclaiming in-guest dead space natively. This was limited to Windows 2012 R2 initially, primarily because of the vSCSI version. Linux distributions check the SCSI version, and unless it is version 5 or greater, it does not send UNMAPs. With SPC-4 support, as introduced in vSphere 6.5, Linux Guest OS will now also be able to issue UNMAPs.
What does it mean? Finally, you can use the thin provisions on the VMware side (maybe combined with the thin provision on the storage side) and have automatic space reclaim.
One way to monitor automatic UNMAP operations, is to use esxtop. Run this command and type u (switch to disk device), then f for define custom field, then select VAAI statistics with o. The DELETE column is related to UNMAP operations. Space reclaim remains manual for VMFS 5 datastores if you disable it at the datastore level, or if you disable it at the host level.