Home > Storage > PowerVault > Guides > Dell PowerVault ME5 Series: VMware vSphere Best Practices > VMware vStorage APIs for Array Integration
VMware vSphere recognizes that the underlying storage it is using may be capable of more than just storing data. Through its storage partners (including Dell Technologies), VMware developed a set of APIs which use the SCSI T10 specification to take advantage of the advanced capabilities of intelligent storage products such as PowerVault ME5 arrays.
This set of APIs is referred to as vStorage APIs for Array Integration (VAAI) and includes the following SCSI primitives:
A common day-to-day IT task involves deploying servers to support new business applications. Virtualization changed this task from a labor-intensive process of racking a server and installing the operating system to a simple task. With only a couple of mouse clicks, you could deploy a virtual machine from a preconfigured template. While this change has resulted in substantial time savings, there was still a significant amount of time spent watching the progress bar as the virtual machine deployed. Traditionally, deploying a virtual machine required reading its data from the array across the network to the ESXi host, and writing the data back across the network to the array. This placed a nonproduction workload on both the network and the ESXi host, concurrently with the production workload of the running environment. Now, with the full copy primitive, ESXi can offload this task to the array where it can be completed much more efficiently. This primitive also results in a significant workload reduction for the ESXi host and the network. The benefits of full copy do not end with deploying virtual machines from templates. Benefits also extend to virtual-machine tasks such as Storage vMotion and virtual-machine cloning.
Fault-tolerant virtual machines require VMDKs that are eager-zeroed thick. These VMDKs differ from standard thick or thin VMDKs in that the blocks are zeroed out when the VMDK is created. For large disks, this process can take a significant amount of time as each zero is written from the server to the array. Then, the array sends an acknowledgment of each write to the server, taking more time. With the block zeroing primitive, the ESXi host offloads to the PowerVault ME5 array the task of zeroing out the blocks. The primitive also permits the host to continue creating the fault-tolerant virtual machine while the storage completes the zeroing task in the background. By offloading the block zeroing to the PowerVault ME5 array, you can create fault-tolerant virtual machines much faster.
To protect Virtual Machine File System (VMFS) metadata, the hardware-assisted locking primitive provides a more granular method than traditional SCSI reservations. Previously, virtual-machine tasks would cause the ESXi host to issue a SCSI reservation lock to the underlying volume of the datastore. These VM tasks could include powering on or off a virtual machine, growing a thin-provisioned virtual disk, or moving a VM with vMotion to another host. The resulting SCSI reservation lock prevented other hosts from also issuing a SCSI reservation to service a similar request. While SCSI reservations are short-lived, the impact can be noticed when powering on many virtual machines simultaneously, as typically observed in a virtual desktop infrastructure (VDI) environment. The hardware-assisted locking primitive resolves this issue by working with the PowerVault ME5 array to lock only the necessary blocks rather than the entire volume. This feature enables other hosts to perform similar operations against that same volume simultaneously.
The thin provisioning space reclamation primitive, also known as UNMAP, enables thin-provisioned datastores to be rethinned to only consume the actual space they are consuming on the array. This action frees up space on the array that was deleted by ESXi, allowing thin-provisioned volumes to remain thin and reducing overall storage costs. Traditionally, the size of a thin-provisioned volume, as shown at the storage layer, reflects the maximum space consumption that occurred at some point since it was created. This behavior results because ESXi did not inform the array that distinct blocks of data had been deleted and no longer needed to be stored by the array. The T10 SCSI primitive UNMAP enables this information to be communicated to the array, through the SCSI storage stack. This UNMAP primitive is referred to as thin provisioning space reclamation by VMware.
With the release of vSphere 6.7, VMware updated the UNMAP API to run automatically in the background without user intervention as part of VMFS-6. This ability is dependent upon arrays using 1 MB or smaller pages. The PowerVault ME5 array uses 4 MB pages, and is incompatible with automatic UNMAP.