When vSphere 6.0 came out earlier this year, there was a lot of hubbub about one feature in particular, and rightfully so. VVols, or virtual volumes, are a way to virtualize storage arrays and have them dynamically move and configure alongside your virtual machines.
VVols don’t replace traditional virtual storage methods, so you can keep using your existing storage strategies and hardware along with VVols. Basically, no matter what kind of storage you’re using in the data center, vSphere treats it as a datastore logical object. Previously, each time you needed to configure a VM for performance or availability, you’d have to move it to a different datastore.
A virtual volume is attached to your virtual machine, so when you pause, delete, or move it, the storage goes along for the ride without you having to mess with configuration. VVols abstract your NAS or SAN into pools that can be scaled over multiple storage arrays or, on the other side, virtual machines. These pools don’t require a file system.
VVols can be configured automatically with Storage Policy-Based Management, which is set up ahead of time to define capacity, performance, availability in template form. This helps provide a steadier SLA to cloud customers, and it also lets your storage admins work more efficiently. For example, when an application is set up in testing, it may not need as high of IOPS as in production. Once it moves into production, the administrator can simply change its storage policy.
VVols have the added benefit of faster and easier snapshots and clones, as well as greater insight into exactly which virtual machines are using which pieces of your storage array, down to individual virtual drives. That visibility is available to hardware, too, so vSphere immediately reclaims open storage when a virtual machine is moved or deleted.
Even though VVols sound pretty useful, you’ll likely want to start off by playing around with them, setting them up in some test environments or with non-critical workloads. For one thing, you can expect some refining and bugs as it has only just been released recently.
VVols do not yet support storage array replication with Site Recovery Manager or vSphere Metro Storage Cluster, so if that’s mandatory for your storage environment you will want to hold off. Some vendors do support array replication, but some storage vendors don’t support VVols period—you can check the VMware Hardware Compatibility guide for more details.
The vendor question is also one of licensing. As you virtualize additional components of your data center, you have to license more features to realize full functionality. In this case, you’d have to license vSphere features like snapshots and I/O controls for your storage arrays. It’s kind of common sense, but just do your research first as far as compatibility with your existing hardware and what features are already available or being worked on.