In 2012, at VMworld, we first saw the “technology preview” for Virtual Volumes or VVOLs for short.  Here we are, nearly three years later, and VVOLs are part of vSphere 6.0 release!  So, what the heck is a Virtual Volume anyways? To answer that question we really need to understand how the storage and virtualization areas interact in today’s IT organization.

Today we have a pretty clear delineation between the roles of storage and VMware admin.  The storage administrator creates a LUN on a tradition storage array and presents it to the VMware environment for consumption.  The storage administrator is tasked with ensuring the array is working and the storage assigned meets the requirements given. Once the LUN has been assigned to the VMware environment, the allocation portion of the storage administrator’s job is done.  Now the VMware admin will create the datastore, assign virtual machines to reside on it, and managed its capacity. When the storage is consumed the VMware admin talks to the storage admin and the process starts all over again.

Tradition storage array based operations are LUN/Datastore centric, things like clones and replication are run against an entire datastore and all virtual machines residing on it. This has served us fairly well in the past, but as storage arrays and virtualization have become friendlier we need a new dynamic. We need to have VM level granular control of storage array operations like this.  Virtual volumes are the answer to this need.

A Virtual Volume is not a LUN and is not a datastore, but rather it’s a higher level of abstraction of the storage where vSphere stores VMDK natively on the storage array. The storage array then can preform data operations on the individual VVOL. There are three parts of virtual volumes: Storage Provider, Storage Container, Protocol Endpoint, and Datastore.

The storage provider, VMware APIs for Storage Awareness (VASA), is used to deliver information about the storage container capabilities to the vCenter server. This is party of the storage array and each vendor will have their own with unique requirements for use.

The second part is the Storage Container, which is simply the pool of storage on the array.  This can be simply raw storage or something more complex which spans multiple tiers of storage.   The storage administrator is responsible for creating the storage container or containers. These containers serve to group virtual volumes together based on storage capability requirements such as service level objective and data protection. In ESXi we see this as a virtual volume datastore.

Finally we have the Protocol Endpoint, or PE, which directs IO from a virtual machine to the storage container across the data path.  This is simply a pass thru and does not store data at all.

With virtual volumes we gain a level of abstraction of the storage array, which allow for better offloading of data management tasks to the array.  Array bases clones can now be done on a single virtual machine rather than an entire datastore. Array based replication no longer encompasses all VMs on a datastore but rather only the virtual machined you actually want to protect.  This level of collaboration will benefit storage and virtualization administrators alike.