ATS (Atomic Set and Test)

• Supported – There is a need to provide clustered file-system semantics and locking for the Config VVOL (VM home object). Therefore ATS is used for locking.

XCOPY (Cloning, Linked Clones)

• Supported – vSphere has the ability (via API calls) to instruct the array to clone an object (Virtual Volume) on our behalf

UNMAP

• Supported – Keep in mind that there is no file-system with VVols. Therefore any space in the storage container that is reserved by a Virtual Volume, can be automatically reclaimed by Storage Array upon the deletion of that VVol.
• [Update] On further discussion internally, this additional benefit of VVols was highlighted. Without VMFS as a layer in between, UNMAP commands generated by the Guest OS now go straight to the array. That means Windows Server 2012 (and, I understand Windows 7 as well) will immediately be sending UNMAPs to the storage (for block-based VVols).

Thin Provisoning Out of Space (OOS)

• Supported – The storage container ‘Out of Space’ warnings will be advertised to vSphere
• A few additional notes about VAAI and VVols. A common question is whether or not VVols and LUNs/datastores from arrays that use VAAI can be presented/co-exist on the same ESXi host. The answer is absolutely, yes. In this case, should there be a request to clone a VMDK from datastore to VVol, VAAI will be used to clone from VAAI enabled datastore to a Virtual Volume
• The other interesting point is around VAAI-NAS, which had a different set of primitives when compared to VAAI on block storage. VVols now levels the playing field. For example:
• NAS vendors are no longer required to write plug-ins. Array capabilities are simply advertised through the VASA API
• Historically, Storage VMotion operations on VMs with snapshots running on NFS were not offloaded. Virtual Volumes removes that limitation on NFS, allowing live migrations of snapshots to be offloaded to the array.
• VVol also brings *space efficient* Storage VMotion for an NFS (VVOL) based VM. It is now possible to determine the allocated (written-to) blocks and only migrate that data. Acquisition of the allocated blocks was not (and still is not) possible using traditional NFS.
• Conversely, when it came to Fast File Clone or Linked Clones (offload to native snapshots ), this was only available via VAAI-NAS primitives, not block. Virtual Volumes removes the NFS only restriction.
• [Update] The whole area of Storage VMotion offloads with VVols is quite detailed.

• Difference Between VASA1 and VASA2 is that VASA1 was a one way communication where the storage capabilities were just been reported to the vSphere stack whereas VASA2 is a bidirectional communication where not only the storage containers capabilities are reported to vsphere stack but vsphere policies and requirement of Objects are also reported back to the array which then places the objects accordingly based on storage array's capability.
• VASA Provider can come in two different flavors, embedded along with the Array and as a VM or appliance. In terms of if the VASA provider fails, everything which was running and configured earlier will continue running but let's say if we deploy a new VM, then we won't be able to define the capabilities. If VASA provider is coming as a VM/appliance, then recommendation is not to put it on a VVol and rather put it on VMFS or VSAN and provide availability.
• VASA Providers comes itself as in a High Availability framework mode as Active-Active or Active-Passive.
• In reference to SRM, SRM today does not work with VVols from an Array Based Replication standpoint because the SRA which does exists today do not talk or know how to talk to the VASA Provider. Vsphere Replication is fully supported.
• SDRS is not supported with VVols today. SIOC is also not supported with this release. SVmotion is supported only when VM is powered Off.