VMware announced the release of Virtual Volumes 1.0 with the release of vSphere 6.0 late in 2015.  Since then, there have been have been numerous blogs and other sources about the benefits.  Many of these cover the obvious storage-related problems Virtual Volumes is intended to fix.

These changes have been downplayed by some storage vendors. What tends to get glossed over is the entire, end-to-end VM workflow management advantages with Virtual Volumes and its mandatory use of VM-Aware Storage APIs (VASA).  This is an intentional change by VMware as they attempt to take more control of and simplify all aspects of VM management.

Virtual Volumes provides a variety of new benefits.

Providing an out-of-band control channel allows offloading the creation and manipulation of VM objects, such as configuration info, virtual disks and snapshots, and memory images. This new mechanism gets rid of the need for a VMware file system (VMFS) on an LU provided from a storage system.

Getting rid of VMFS provides a handful of benefits: Datastores no longer represent a fixed-sized file system with a fixed data connection. Instead, a storage container defined by the storage system represents a VMware datastore. Protocol endpoints, also defined by the storage system, represent data path endpoints. However, there doesn’t have to be a correlation of storage containers and protocol endpoints, meaning storage capacity and throughput can be managed by VM requirements rather than storage system limitations. Getting rid of the VM file system also eliminates metadata contention that had long limited the number of VMs that can coexist on a single VMFS filesystem.


Some storage vendors equate this limited set of the Virtual Volumes features as simply making block storage look like NFS. Satisfied that they have all all the answers with NFS already, they’ve shown little interest in Virtual Volumes. (This also ignores that VMware provides a complete Virtual Volumes implementation that works integrally with NFS). Others have taken a self-serving and lazy approach that “Virtual Volumes isn’t catching on, and VMware isn’t doing more to promote it.” The second sentiment is categorically wrong. VMware provides enablement of  VVols for free in vSphere 6, in stark contrast to the per-instance license cost associated with their own storage offering, VSAN. Virtual Volumes was one of the hottest topics at VMworld US 2016, and VMware is actively fostering development.

The simple truth is that it’s up to us, the storage vendors, to provide compelling use cases for Virtual Volumes.

To do that, we have to look at the true benefit of Virtual Volumes: simplified, centralized VM workflow management, end-to-end. VVols with VASA provides a VMware administrator the ability to provision and organize VMs and virtual disks without involvement of a storage administrator. VM datastore tagging allows automatic placement of new VMs in the datastore they belong in. Storage Policy-Based Management (SPBM) allows dynamic VM policies to be immediately reflected by underlying storage, in many cases with no data movement required.

NetApp SolidFire designed Virtual Volumes support from the ground up, not trying to patch existing features to “look like” VVols. At the same time, several of the NetApp SolidFire implementation details matched VVols design goals. The SolidFire volume design is entirely congruous with the requirements of virtual volumes. Storage containers are a concept important to VMware admins. As such, NetApp SolidFire treats them as logical separation in a cluster, not tied to any underlying storage construct. Storage containers are tied to storage accounts but otherwise scale as the cluster scales.

Similarly, protocol endpoints are used for throughput scale, not as a way to represent underlying storage. NetApp SolidFire takes the approach of adding protocol endpoints as the cluster grows and managing them without any intervention of the storage administrator.

The VASA provider is built into the services that run on every NetApp SolidFire node and achieves its high availability the same way all of the services on a cluster do. This means it isn’t run as a separate virtual machine like other vendors implement it, vulnerable to infrastructure and network outages.


We at NetApp SolidFire are taking the additional step of providing a vCenter plug-in that allows creation of new storage containers directly within vCenter. This means that once VVols is enabled on a NetApp SolidFire cluster, there is no reason to open the storage UI again for any VM operations.

SPBM really is the key to making the most of your Virtual Volumes environment at scale. The ability to apply granular VM or virtual disk policies means different classes of VMs can have completely different capabilities. Even with a single VM, the virtual disks can serve different purposes and therefore,might require different levels of guaranteed QoS or other capabilities. These policies can be applied individually through the vSphere web client or en mass via the vSphere API. (NetApp SolidFire has PowerCLI scripts pushed to GitHub to allow you to do just that.)

Now you, as the VMware admin, have the capability to custom-configure your virtual infrastructure and have storage automatically comply, even if that configuration changes frequently or even job by job.

None of this is accidental.

VMware understands that they have strong and growing position in managing the next generation data center. VASA is currently in its second generation, adding the full set of Virtual Volumes calls in VASA 2.0. The next generation of VASA is in the works and is likely to include much more management, in terms of full data-center and multi-data-center capabilities.


It’s important to remember that VMware uses VASA APIs to manage their own hyper-converged storage offering enabled with VSAN.  That means the same VASA calls going forward are to be used to provision and manipulate storage, regardless of whether it is small-scale VSAN configurations or large-scale Virtual Volumes setups. It’s a safe bet that VMware will start shipping orchestration tools that make use of VASA calls for automation, cloud management, and disaster recovery. To move forward in a VMware infrastructure, you’re going to need storage that can be managed at a granular level via VASA.

Right out of the box, Virtual Volumes provides a lot.

Right out of the box, VVols gives us a load of efficiencies: less wasted storage by removing fixed-sized LUs; less wasted SAN bandwidth by fully offloading copying, snapshotting, and VM creation operations; less filesystem overhead; and less interaction between VMware administration and storage administration to perform everyday operations. It improves organization by making VMware datastores actual logical collections of VM components, rather than artifacts of the underlying storage architecture.

Right now, probably the biggest benefit of Virtual Volumes is the granular, dynamic ability to manipulate and provide capabilities to individual VMs and virtual disks. But going forward, the most important aspect of Virtual Volumes is the ability to use VMware management tools and and agents to automate the management and consumption of storage in your VMware virtual infrastructure.

Contact me or your NetApp SolidFire rep if you’re interested in find out more.

Andy Banta