I’ve been getting a number of questions around vSphere Storage APIs (VAAI and VASA) and Virtual Volumes and how they would interact with arrays that are compliant with both vSphere APIs (VAAI and VASA). So, instead of providing an individual answer to the question I figured it would be best to share with a broader audience since it’s probably something that a lot of people may also wonder about.
Virtual Volumes is based on vSphere Storage APIs – Storage Awareness (VASA) and some of the function of its operations are based on the ability to offloading operations directly to compatible storage arrays. The other vSphere Storage APIs – Array Integration (VAAI) also provide operation offloading capabilities, especially when it comes to cloning and migration operations. Listed below is the questions asked:
With VVols when a VM is cloned on an array that supports VAAI does VAAI & VASA complement each other or VASA is used for this operation?
That was a loaded question and figured that it would be better to explain and provide some illustrations and specific details around what happens, because the way in which the cloning operation will work depends on a few facts and scenarios.
Scenario A
When virtual machines are stored on a VVol container, anytime a virtual machine is cloned onto the same VVol container, the system will use the VASA API cloneVirtualVolume and offload the entire clone operation to the array.
Scenario B
If a clone operation is to be performed across different storage containers, in this case the operation may or may not offload the clone operation via the VASA API cloneVirtualVolume. This is all dependent on vendor implementation and environment constraints, for example;
If there is VASA Provider managing two different arrays from the same vendor and each array has a VVol container (VVol-a, and VVol-b), in this case if a clone operation is performed, the system will utilize the cloneVirtualVolume VASA primitive because the source and destination containers are both VVols. Changes are this operation will fail because the VASA provider has no way to offload the clone operation from the source array’s VVol (VVol-a) to the target array’s VVol (VVol-b).
Another example could be an array that has two VVol containers exported, depending on how the containers are configured, the array vendor may or may not be able to perform a MV clone operation across the two VVol containers due to constraints based on the vendors implementation where for example there are two independent VVol groups that are not compatible with one another and that prevents the clone operation from being offloaded across the two.
For both examples, if the VASA call cloneVirtualVolume fails, the system will then fail back to a host-driven mechanism using the bitmap APIs.
If the target does not support this type of workflow, the system will use a host-based bitmap copy (making use of the allocatedBitmapVirtualVolume and/or unsharedBitmapVirtualVolume VASA API) and use the vmkernel data mover to service the operation request.
Scenario C
Another possible scenario is cloning from a VMFS datastore on a VAAI enabled array to a VVol container on the same array. In this scenario, the system will use the XCOPY VAAI offload to accelerate the clone. Note that this is a one way workflow, in other words, VVol > VMFS VAAI does not use the XCOPY.
I hope this answers the questions is helpful for everyone else.
– Enjoy
For future updates on Virtual Volumes (VVols), Virtual SAN (VSAN) and other Software-defined Storage technologies as well as vSphere + OpenStack be sure to follow me on Twitter: @PunchingClouds
I’ve been getting a number of questions around vSphere Storage APIs (VAAI and VASA) and Virtual Volumes and how they would interact with arrays that are compliant with both vSphere APIs (VAAI and VASA). So, instead of providing an individual answer to the question I figured it would be best to share with a broader audience since it’s probably something that a lot of people may also wonder about.
