After all the sound and fury, when will VVOL start to rock?

Not so VVOLuminous?

As a corollary to this, note that the number of VMs supported by a VVOL array will be rather lower than the number of VVOLs it supports.

Central role of VASA in VVOL scheme

This is all starting to look quite complex^*. However, all of a storage admin’s processes for VM storage creation, such as creating a LUN, defining the access path and recognising volumes, are done automatically with VVOLs. VMs should then receive faster storage provisioning with fewer errors, individual storage service management, automated protection and more easy scalability. There can be automated tiering and better optimisation of storage resources for each VM, improving overall storage efficiency and VM operations.

VMware introduced VVOLs with vSphere 6.0 in February this year, together with VASA 2.0. Storage array providers, both for blocks (SAN) and files (NAS), then had to introduce array controller software which could:

• Announce VVOL services via VASA,
• Support vSphere APIs for Array Integration (VAAI) which offloads specific storage operations from the ESXi VMs to supported arrays, allowing vSphere to get storage operations done faster while consuming less host CPU and memory resource,
• Respond to incoming VVOL set up requests via VASA from ESXi hosts,
• Service VVOL IO requests from VMs,
• De-provision and tear-down VVOLs are requested through VASA.

In other words they had to have VASA provider software functionality added. For example, Fujitsu ETERNUS array users have downloadable ETERNUS SF Storage Cruiser v16 software to provide this (ESF).

This needs a Windows-based installation.

VMware has a VVOL compatibility search facility on its web site to list suppliers which have done this:

VMware VVOL compatibility guide search screen

For each listed VASA supplier you can obtain more details:

VASA supplier details

A third-party storage supplier VVOL support list can be found at Virten.net.

Obviously support is tied to an VSphere release level, an individual vendor’s physical or virtual storage array software release level, and to actual VVOL services. It is not simply all or nothing.

A VVOL problem identified by George Crump of Storage Switzerland is that VVOLs are “only a half step to automation. … there is no middle ground between manual management and automation.”

Also VVOLs are VMware-specific and don’t function with other hypervisors. Crump states “SDS needs to advance to address the broad performance and capacity management of the entire data centre beyond just LUNs and VVOLS. “

VVOLs clearly require the creation of VVOLs with their specific service attributes and levels. It would be better, Crump argues, if the storage pool was told to provide a capacity limit and performance requirement for a VM or set of VMs. The administrators setting up VM storage policies need to understand the capabilities of the storage arrays and what they can do in their data centre.

The more varied that storage estate is in terms of array products and suppliers the more complicated and difficult that is. Few data centres will have 100 per cent of their storage supplied by one vendor and within a single VVOL-aware, management domain.

Also, instead of moving storage admin provisioning responsibilities transparently to the VMware admin person, the VMadmin has to become a partial storage admin. VM admin staff might be resistant to taking on that burden.

However, within a VMware administration domain and in the domain’s VVOL-supporting storage estate, the use of VVOLs should significantly improve the speed, efficiency and manageability of VM storage. Once the foundational service catalogues have been set up then your data centre’s VM operations should be much more dynamic and efficient. And VMadmins should love that. ®

* To appreciate VVOL complexity at an array level check out this Fujitsu PDF slide deck.