In the VMware ESXi 5.0 patch released on 15 December the VAAI support for Thin Provisioning is now disabled by default. This is due to several reported performance problems.
The other VAAI options for cloning and other remains functional as before, so the patch only disable one part of VAAI.
One of the new features in ESXi 5 was the extended VAAI options for helping SANs with “thin LUNs”, that is the SAN presents a LUN of some size, e.g. 1 TB, but on the actual disk arrays only allocates the amount of disk space that is consumed by the system attached to the LUN. From the ESXi host this looks like full sized LUN which the host uses just as usual, but the SAN administrator hopes to save disk space, reducing backups and perhaps less replication.
When VMDK files are added to the VMFS datastore the LUN get dynamically expanded in the background, but transparent for the ESXi host. Very similar to the way ESXi could present a thin virtual disk to a guest operating system and only extend the vmdk file when needed.
If one or several large VMDK files are later moved away by Storage vMotion or just deleted we will only logically remove the file, that is by erasing the information from the VMFS file table, called the metadata, but the actual data are still left on the physical disk surface.
A problem for the SAN array is that it only knows which parts of the thin LUN that holds any data, but does not know what is actually used by the ESXi hosts. Since it does not understand the VMFS filesystem it has no knowledge which parts of the disk are in real use and which part are considered deleted. For a full provisioned LUN this is no problem, but a “thin” LUN will now hold data which is not necessary to keep.
From ESXi 5.0 with the updated VAAI support the Vmkernel will send commands called SCSI Unmap when files are moved or deleted. This will inform the array which sectors are no longer in use by VMFS and if wanted the SAN array could reclaim those. (SCSI Unmap is quite similar to the TRIM command found on SATA SSD for the operating system to inform the SSD device which parts of the disk that could be reclaimed.)
Unfortunately there has been various issues with the VAAI Thin Provisioning since the ESXi 5.0 release earlier this year and with the new patch (KB 2007671) released yesterday the feature is changed to disabled by default. Hopefully the problems will later be resolved and the option could be used in the future. As noted earlier, the other VAAI options is still active and is not affected by the patch change.
It is also possible to enable or disable the feature manually through the ESXi shell for each host by using the esxcli command.
esxcli system settings advanced set –int-value 0 –option /VMFS3/EnableBlockDelete
If you want to re-enable the feature after the patch set the int-value to 1. This might be if you know that this has in fact worked well with your SAN array.
Use “esxcli system settings advanced list” to display the value of setting. This is a ESXi local setting, so it has to be enabled/disabled on every host. See Knowledge Base article 2007427 for more details.
Stupid question… but I’m assuming this only affects storage arrays that are using iSCSI and not NFS ?
Hello Oliver,
you are correct that this is not for NFS but only for block based arrays, i.e. iSCSI or Fibre Channel, for the reason that only with the latter the VMkernel has control over the actual disk sectors and the file table. With NFS the problem is not really the same since the NFS server controls much more. If you move a VM from a NFS store then the file is “deleted” and the NFS server could do what ever it wants with the physical remains, which a block based array could not do.
Regards, Rickard