Way back in the vSphere 4.1 days, VMware introduced vStorage APIs for Array Integration (VAAI). VAAI is a set of APIs that provide the vSphere hypervisor with a level of direct control over supported storage arrays. Each feature – known as a primitive – provides a discrete service to the virtual environment and serves to help administrators gain additional benefit from the significant investments made in storage technology.

Primitives are anything but

The table below outlines the critical primitives that form VAAI. You will notice that three functions were introduced with vSphere 4.1 and the remainder shipped with vSphere 5. Note that one item, Thin Provisioning Out of Space Suspend / Stun has a yellow check box in the vSphere 4.1 column. This primitive was added in vSphere 4.1, but was undocumented and only officially added in vSphere 5.0. Some array vendors did support it in 4.1

Click table to enlarge.

As you look at what happens behind the scenes with VAAI, the technical benefits that can be achieved when using a VAAI-enabled array with vSphere 4.1 or 5 become clear. Let’s consider the Full Copy primitive. This primitive enables the hypervisor to move what can be extremely impactful copy operations away from the hypervisor layer of the virtualization stack and right to the storage. There are major benefits here, which you can see as you compare the two operations. Figure A gives you a very simple pictorial representation of how VAAI Full Copy is of major benefit.

Figure A

VAAI Full Copy vs. non-VAAI comparison

In the left hand figure, you will note that the file copy is three operations… at first glance. In reality, it’s many more, since each step is repeated for each block of data that needs to be copied as a part of the operation:

  1. Issue a read command to the storage array.
  2. The storage array returns to the hypervisor the requested data. The hypervisor processes this information.
  3. The data is written back to the array in its new location.

However, with VAAI, the following takes place:

  1. Issue a read command to the storage array along with the location to which the copy should be written.
  2. The array internally performs the copy operation without further intervention of the host or the storage fabric.

It’s clear from the diagram that the VAAI-enabled storage option has much less impact on the hypervisor and the storage fabric than the non-VAAI option. The non-VAAI option needs to involve the hypervisor and the storage fabric for every block read and written. This means that the hypervisor has to expend CPU cycles on this operation and it means that the copy operation could potentially take longer than it needs to.

By freeing up hypervisor CPU cycles, there is the potential to create more dense virtual environments since there is more CPU to service workloads.

With VAAI, the array simply handles the work and many environments see much greater speeds in the copy operations than they would without. This can translate to the ability to support larger workloads in the virtual environment.

For other primitives, there exists the opportunity to ensure higher levels of availability in the virtual environment. This is most obvious with the Thin Provisioning Out of Space Suspend / Stun primitive, which can help administrators better manage storage that is thin provisioned and avoid out of space conditions that bring down workloads.

Summary

This article is not intended to describe every VAAI primitive in detail, but to demonstrate some of the real business-positive outcomes that can be enjoyed through the use of a VAAI-enabled array.