In version 4.1 of the ESX/ESXi software VMWare introduced a new feature called VAAI. As the name suggests it offers integration capabilities with the storage array to offload certain operations from the host to the array. I will discuss why this feature is needed first of all and what some of the use cases would be.
VAAI essentially is a logical step forward in virtualization where you reach a bottleneck in terms of the network and virtualization layer capabilities and uses the storage more efficiently to perform tasks that are truly at the storage layer anyways. So instead of getting the virtualization or network layer involved it allows the storage array to do more than it has traditionally done. Now, many organizations have storage arrays that are under-utilized and others have hyper active storage arrays. If you have hyper active storage arrays that cannot keep up with existing performance constraints I would ask that you tread carefully with your implementation of VAAI. In order to perform certain new tasks there will be a little more load on the storage controllers than you anticipated. It is important to understand what that extra load can do to your existing performance constraints.
If your trade off however is that you need the activity done soon (assuming your storage controllers don’t run at 90% utilization) then it is quite relevant that you would want to perform storage vMotions on the array instead of having to transfer data over the network or with the hypervisor involved. There are certain requirements to ensure your infrastructure supports VAAI – primarily storage arrays should storage based hardware acceleration. Most newer arrays support that but some legacy storage arrays might not be able to do that. VMware offers a hardware compatibility list that should be referenced.
In ESXi 5.x onwards VMWare made some changes to further improve VAAI. The goal was to encourage customers to use larger datastores and fewer of them. Note that fewer datastores also reduces processing overheard on storage arrays so your general storage performance will see an improvement anyways. Going back to the new improvements NAS Hardware Acceleration is now included with support for Full File clone, Native Snapshot Support, Extended statistics, and Reserve space. Previously, only thin disk provisioning (VMDK) was supported and now thick disks are also supported.
A cool feature is the support for Block Delete to reclaim dead space on thinly provisioned LUN’s. KB#2014849 offers more insight into reclaiming VMFS deleted blocks on thin provisioned storage. To confirm if SCSI UNMAP is supported on a LUN use the following command:
# esxcli storage core device vaai status get -d <naa>
If in the output ‘Delete Status’ is supported then the LUN is capable of sending SCSI UNMAP commands to the array.
To get the VAAI status from command line use the following command on ESXi 5.x
# esxcli storage core device vaai status get
On ESXi 4.x run the following command
# esxcfg-scsidevs -l | egrep “Display Name: |VAAI Status:”
Any changes to the VAAI settings can be viewed at /var/log/vmkernel or /var/log/messages
In conclusion, I do want to mention that VAAI cannot be used when the source and destination vmfs volumes have different block size, the source is RDM and destination is not similar (non-RDM). The source and target volumes should be formatted with the similar disk type – eagerzeroedthick or other options.
For more details refer KB#1021976 or visit the link here – bitly.com/nVkRFW