Software-Defined Storage Virtual Volumes (vVols)

Getting Ready for Virtual Volumes

At VMworld this year one of the most common questions I was asked was “how can I get started with vVols”? In this blog we’ll cover a couple of key things you can do to get ready for vVols.

Taking vVols for a Test Drive

Hands-On

For those of you wishing to get a hands-on introduction to vVols VMware has published the following drive check out the following labs from VMworld:

These labs are a great way to try out vVols and get a quick introduction in just a few minutes.

Getting Started

When you are ready to get started with VVol in your own environment…

First: Check Your Storage

First on the list for vVols is figuring out if your storage system has vVols capabilities. With Virtual Volumes the virtual disks associated with a VM are now represented as native array objects. With this we can now offload operations like snapshots and clones directly onto the array itself, however arrays need to provide support for the appropriate vVols APIs so we can perform this offload. This integration is provided by a component called a VASA Provider that is supplied by the storage vendor.

To check if your storage vendor has a VASA Provider that supports vVols you can go to the VMware Compatibility Guide for vSphere APIs for Virtual Volumes (vVol). On this guide you can find the VASA providers that are certified for use with vVols and filter by Vendor, storage protocol, and supported features.

vvol_vcg

From the list of VASA providers you can drill down to view details of which storage models are compatible.

vvol_vcg_detail

[UPDATE]: The VMware Virtual Volumes Compatibility Guide has been updated to make finding compatible storage even easier.

Second: Check Your HBAs (for Block Storage)

Checking that their HBAs are compatible with vVols is a step that I know a few customers have skipped and then later had trouble getting their hosts properly connected to vVols storage. The reason for this is that Virtual Volumes with block based storage (FC & iSCSI) use something called a secondary LUN ID to communicate with the virtual volumes on the array. This enables ESXi hosts to connect to a very large number of vVols (up to 64,000 per host) via a small number of Protocol Endpoint LUNs. This scaled out approach to I/O does rely on your HBAs supporting this secondary LUN ID so a PE can distinguish the I/O to individual vVols associated with it.

You can check that your HBAs support vVols by going to the VMware Compatibility Guide for IO devices, selecting your HBA vendor and then selecting the feature support “Secondary LUNID (Enables vVols)”.

If your HBA vendor supports the Secondary LUN ID feature you can then drill down into the search results to view specific driver and firmware versions supporting this feature.

vvol_io_vcg

Third: Read Your Vendors Recommended Practices

Many storage vendors are publishing their recommendations for deploying vVols. As with any storage deployment it is always worth reading those documents so you can be sure you are building on a solid foundation and taking advantage of the differentiated capabilities of your storage.

Dive in!

Virtual Volumes makes storage a first class citizen in the Software Defined Data Center. With growing support for vVols across the industry now is a great time to take a look at vVols and bring the benefits of policy based, fine-grained control of storage to your data center.