The VVOLs Cometh

VMware has been taunting us with the promise of VM-level storage granularity through its Virtual Volumes (VVOLs) technology since 2011. Growing just a bit impatient last year, I compared VVOLs to the never-appearing title character of Samuel Beckett's masterpiece, Waiting for Godot.

Though VMware didn't formerly announce VVOLs at this summer's VMworld, it's strongly indicating that VVOLs will arrive sometime in 2015 (hence the reference to the Eugene O'Neill play The Iceman Cometh.)

The best indication of VVOLs' imminent arrival is the Fight Club-style beta process now going on for the next version of vSphere, including VVOLs. Anyone can sign up for the beta online and download the latest test code, but just as the first rule of Fight Club is "You do not talk about Fight Club," you have to agree to a nondisclosure agreement in order to join the beta.

VVOLs provide the context about virtual volumes that storage systems need to be able to provide data services at the VM level and, through VASA 2.0 (vSphere API for Storage Awareness), automate the provisioning of storage.

To perform this magic, VVOL technology adds two new elements to the communications channel(s) between a server and its storage. The VASA 2.0 Provider establishes an out-of-band command, control, and monitoring connection between servers and arrays. The storage arrays can tell servers what storage containers it houses, their capacity, and their capabilities such as data protection level and media type. The server can then provision VVOLs as needed.

Using VASA 2.0 as the control channel between the servers that consume storage and the systems that provide it significantly simplifies storage management. Providing per-VM data services on block storage devices also requires a solution to the limit of 255 connections from a server to storage devices.

VVOLs address this by having servers' iSCSI or Fibre Channel connections terminate at a Protocol Endpoint in the storage array. The Protocol Endpoint then dynamically binds VVOLs to server connections. Servers can then address as many VVOLs as they need over a single connection.

By providing VM awareness to storage systems, VVOLs are a big step forward in storage management. However, it's important to remember that VVOLs are really just an API, and that implementations will vary significantly from one storage system to another. Implementing VVOLs will be easiest for modern NAS storage systems that can map VVOLs to files in their current file systems.

Block storage vendors will have a harder time adding VVOLs to their designs, some of which are more than a decade old. Those systems were designed to manage a small number of LUNs and may not have metadata structures that will support thousands of VVOLs, each with multiple snapshots. I wouldn't be surprised if one or more vendors didn't support VVOLs until their next hardware platforms come out, and they can update the on-disk data format.

As far as I'm concerned, VVOLs are the next big thing in storage. It will be interesting to see how they affect the market dynamics.