- ONTAP 9
- VMware vSphere
Once a LUN is provisioned, the storage array only knows about areas of a volume that have been written on the LUN. ONTAP, for example, reports this information for each volume. Space allocation grows automatically due to application data writes. Later, if the application frees up space, the space used by the LUN is not marked as free by the storage array unless ESXi sends a SCSI UNMAP command to de-allocate the storage.
Hence, there will be a difference in views between the VMFS file system and Data ONTAP. Indeed nearly all host file systems and storage arrays operate in a similar fashion.
How it works with VMware:
With VMware, this occurs because when you create a VM, say with a 100GB disk, 100GB is not written to the array unless you choose the eager zeroed option.
If you choose the lazy zeroed option, 100GB is deducted from the file system metadata on the VMFS volume. The array can only report how much data has been actually written to the volume. Eventually, it will go the other way. As data is written and deleted, the used space in the array will be greater than what ESXi or vCenter reports. That is because when a file is deleted, that is a WRITE to the allocation table that only ESX can see. There is a SCSI command called
UNMAP that will correct this behavior.
In practice, everything is working as intended. Lazy, Eager, and Thin provisioned VMDKs are all supported features for which ONTAP provides storage.
VMware vSphere 5 Documentation Center