The value of Virtual Volumes (VVols)

VVolsRegular readers will know that I normally blog about the technical aspects of storage, as opposed to doing opinion pieces. However there have been a number of articles published recently questioning the value of VMware’s Virtual Volumes, commonly referred to as VVols. In general, the pieces I have read ask whether or not VVols (or to be more accurate, per-VM granularity feature of VVols) adds value when NFS is already doing per-VM granularity in the form of files. The point that was missed in these pieces is that VVols is so much more than per-VM granularity. I’ve just come back from some great VMUG events in Frankfurt, Germany and Warsaw, Poland where I presented on the value of VVols to our users. I therefore thought it opportune to post about the other benefits of virtual volumes.

Storage Policies

Before I begin, I would like to give a shout out to my good friend over at Veeam, Luca De’Lorca. Luca already composed an excellent response to one such piece where he highlighted the benefits of SPBM, Storage Policy Based Management. If I can paraphrase Luca’s response, having the storage surfacing up its capabilities to vCenter, and then being able to compose policies based on these capabilities, enables you, our customers, to do successful initial placement of a VM’s storage each and every time. It also allows you, at a glance, to check whether the underlying storage is still meeting the requirements of the VM for the life-cycle of that VM. Maybe there was a failure at the storage layer, or perhaps the VM was migrated to a different datastore during some maintenance activity. Any number of things can impact the underlying storage of the VM. Historically, to be able to verify that a VM was on its correct storage, customers had to track datastore capabilities through various means. For example, we had customers who maintained a spreadsheet of datastores, capabilities and virtual machines. Similarly, we had customers creating really long datastore names to try to reflect a datastores capabilities. With SPBM (and of course VASA – storage awareness APIs) surfacing up these capabilities, and allowing policies associated with VMs to be pushed down to the storage layer, we make this whole management of storage so much easier.


Making storage management simpler for the vSphere Admin

I actually left a comment on Luca’s blog to try to highlight the fact that it is not just per-VM granularity and policies that gives VVols value. There are other aspects as well. With VVols, we introduce two new concepts; the Storage Container and the Protocol Endpoint, as shown in the previous diagram. Storage Container is easy to explain; you can think of it as an aggregate or pool of storage on the array with an associated set of capabilities. For example, these capabilities might be thin provisioning or/and deduplication or/and encryption or/and replication, etc, etc. The list goes on, but will be very much array dependent. This container or containers is surfaced in vSphere as a single VVol datastore. A vSphere admin now has the complete view of the array’s storage, which is now at his/her disposal. There is no longer a need to reach out the storage admin to carve up and present new LUNs or volumes when storage is required for new virtual machines.

Reducing storage complexity

The Protocol Endpoint (PE) is another feature that is aimed towards simplicity. Consider the traditional LUN or Volume, which is both an access point as well as the storage container. The objective of the PE is to decouple the access point from the storage container. What this means is that we can now address all the storage on the array through one or more PEs. This means that the storage presentation workflows that we had to do in the past for storage, such as initiator groups, ensuring LUN IDs matched across all hosts, making sure the LUN was presented correctly for ESXi hosts, etc, is now also greatly reduced.

On the vSphere side, making sure that the multipathing configuration across all LUNs and across all hosts is also simplified, as you now only need to concern yourself with the PE device. Note that this will be true for NFS 4.1 as well, as soon as this is supported with VVols. Right now we only support NFS v3. NFS v4.1, which was supported with the 6.0 release, supports multipathing.

Scaling storage

I also wanted to make a point about scale. Currently there is a limit of 256 LUNs per ESXi host. With the introduction of VVols and PEs, we can now have 256 PE devices from multiple different arrays presented to the same ESXi host. What this means is that we can now have many 1,000s upon 1,000s of VVols (array dependent of course) presented to an ESXi host. VVols allows us to scale to a size that was not achievable previously.

In conclusion

I hope this gives you an idea about the value of VVols. It is not only about per-VM granularity, which is an excellent benefit in its own right. Consider array based snapshot on a per VM basis and array based replication on a per VM basis when we support it. VVols is also about policy based management for storage which will ensure that storage is provisioned correctly for VMs. It is also about simplifying storage management for vSphere administrators and scaling storage for vSphere to a factor never before possible.

Maybe VVols isn’t for every array vendor – they have their priorities too. But for us at VMware, all of these factors form some of the main goals of our software defined storage vision and applies to VSAN, VVols, SPBM, VASA and VAIO.

  1. Great summary, spot on. Thanks, Cormac!

    I’ve heard customers in the past complain about QoS inversion, where they put so many VMs on overloaded “high performance” tier datastores that the lower performance tier datastores actually performed better. VVOLs along with the true QoS that SolidFire offers will eliminate that issue completely.

    • No – there is no requirement on NPIV. The granularity is achieved through supporting “Second Level LUN ID” capabilities of the adapter and array. This allows per VVol addressing.

  2. Cormac,

    As I discussed VVOLS with a storage vendor (name irrelevant) today they were shocked when I described how the Protocol Endpoint acting as a demux gives the storage array data segregated by VVOL allowing read-ahead and log VVOL non-caching. If the storage system is smart enough that un-blends the I/O blender.

    You guys could play that up a little too.


    LUN/datastore QoS is addressing the noisy neighbor problem by dividing the neighborhood into smaller gated communities.

      • Howard, Good QoS doesn’t put hard boundaries around datastores. It sets up guidelines by which all applications can play fairly, like a traffic cop. In Boulder we’ve got a new highway lane that switches direction depending on rush hour. That’s a great way to think of QoS. It more intelligently manages I/O traffic and exploits performance resources to the fullest. So no gated communities, sorry. Check out if you’re still in doubt.

    • Good point Howard. The opportunity is there for the storage partners to facilitate this level of I/O separation. It would be nice to see for sure.

  3. One open question I haven’t seen discussed is does vvols’s eliminate the metadata locking issues we used to worry about with standard block based volumes? I’m referring to the loose recommendation of no more than “x” VMs per datastore. I’m guessing it’s no longer an issue if you’re stating that we can run 1,000’s of VMs per PE.

    I suspect this too eliminates most concerns around the number of paths for a given. PE? There are some scale out arrays that could have up to 16 paths per lun. I’m sure the limit still exist but in theory you should now have fewer PE’s compared to what you would have had with standard volumes.

    • This was essentially resolved with the VAAI primitive, ATS (Atomic Test and Set). This did away with SCSI Reservations, which was the big issue with locking issues.

      There will still be limitations on the number of paths per host, but considering that there will be far fewer PEs than LUNs, you can certainly increase the number of paths for the PEs without reaching that limit.

  4. Great post, Thank you Cormac!

    Though, a subject I haven’t seen much discussion about is the advanced storage parameters like the Disk.SchedQuantum or Disk.SchedNumReqOutstanding for example.

    How does VVols affect these parameters? These parameters are used for fine tuning in case of multiple VMs running in the same Datastore, but in the case of VVols that fine tuning seems to be unneeded. So, Is that correct? How these parameters may/may not impact on performance?

    What about multi-path in case of VVols? Should I configure the MPP only for the PE?


Comments are closed.