Why Virtual Volumes?

By on 03/25/2015.

How many times in the last 3-4 years have you heard “Virtual Volumes”, “VVols”, “Storage Policy Based Management”, or any of the other terms associated with VMware’s newest software-defined storage technology?  I first heard about VVols in 2011, when I was still a customer, and the concept of no longer managing my virtual machine datastores, but rather simply consuming storage as needed with features applied as requested, was fascinating and exciting to me.

Well, it’s here!  And it’s everything I hoped it would be 4 years ago.

Source: VMware blog post by Rawlinson Rivera

VVols has finally arrived!  It was shipped with vSphere 6.0 and brings the ability to leverage VM Storage Policies – and the array-specific features surfaced by the VASA Provider – to specify which storage features you want applied to your virtual machines. The best part? You can do this all the way down to the VMDK level!  I won’t go over the nitty-gritty details of the VMware parts, Cormac and Rawlinson have done a terrific job of that here and here.  I highly recommend you read their articles to learn about VMware’s perspective, implementation details, and overall expectations.

In the coming weeks we will be covering all aspects of the NetApp VVols implementation, how you can deploy them, and some early best practices, but right now I want to talk about…

Why you should care about VVols

For me, the most important reason is simplicity.  How many datastores do you have in your vSphere environment?  10?  100?  500?  How do you track which storage array, disk type, caching technology, efficiency features, and all of the other metadata that is important to differentiating that datastore from any other?  If you’re like most customers I talk with, you simply use word of mouth…”Hey, storage guy! What type of disk is LUN 12 on?”  At best, I see people using spreadsheets which track all of the important information so you know that “datastore 16” is on an aggregate with 10k SAS drives connected to a FAS8020 with Flash Cache and deduplication enabled, while “datastore 7” is on 7.2k SATA drives with compression and deduplication on a FAS3250.

Your job just got easier.  Create a VM storage policy, define the disk type, cache type, efficiency, and other features, then assign it to the VM and you’re done.  Need to change the policy?  Great, modify the assigned policy, then sit back and watch as the storage manages the VMDKs and ensures they are getting the features you have defined.

I’ll leave you with these teasers…the three things I’m most excited about:

  • Snapshots are now storage-based and VM granular. No more volume snapshots to protect individual virtual machines.
  • There is no more indirect NFS datastore traffic (which uses the cluster network). All VM storage traffic is always directed to the node which owns the FlexVol…even after moving the VVol between nodes.
  • I’ve already touched on the OnDemand features here, but they only get better with VVols. Moves, copies, clones, restores all instant within the same cluster, regardless of protocol.

STAY TUNED!

Andrew Sullivan
Andrew has worked in the information technology industry for over 10 years, with a rich history of database development, DevOps experience, and virtualization. He is currently focused on storage and virtualization automation, and driving simplicity into everyday workflows.

5 Comments