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

  • mike

    How will SnapProtect work with the VVols? At the moment the backups are all volume based. So SnapProtect backs up VM1 on Datastore NFS1 and DFM creates and manages any vault/mirror relationships via the Dataset.

    It will be awesome and I hope it will work this way: Each VVOL will have a snapshot allowing fast revert option for restores. At the moment its a 1 datastore to many VM’s so the revert option will restore the entire volume and not the selected VM.

    Interested to see how SnapProtect will fit in the new world order if everything can be done in VMWare via the VASA.

    Thanks,

    Mike

    • Andrew Sullivan

      Hello Mike,

      Thank you for your question. We are still evaluating how SnapProtect will work with individual VVol objects. Snapshots on individual virtual machines change when using VVols, however it’s still possible to take a volume snapshot and manage backups at that level, when the backup occurs in conjunction with the VASA Provider.

      We will be providing more details about the implementation and details in the next few weeks, please keep reading and as we are able to release more details hopefully your question(s) will be answered.

      Thanks!

      Andrew

    • bbk

      I suppose SnapProtect will work with VVOLs the same way as they where RDM LUNs.

  • Hi Andrew,

    Am I right in thinking that you could change any of the following in a policy which would result in the VM needing to be moved to a different volume and ONTAP would instantly move the VM in the background:

    Replication schedule
    Dedupe and compression settings

    I hope that in a future version of ONTAP you will be able set the above policies at a VVOL level rather than FlexVol and therefore there would be no need to perform any move which would be much more efficient.

    I assume as well that once we can replicate at the VVOL level that SnapMirror could then be used with Long Distance vMotion so you do not need to copy all the data each time – I believe EMC will announce this at EMC World for VPLEX Geo.

    Also it would be useful to be able to move the active VVOL between sites with MetroCluster which would bring it much closer to VPLEX In terms of capabilities.

    I wrote more about this at http://blog.snsltd.co.uk/a-deeper-look-into-netapps-support-for-vmware-virtual-volumes/

    Your thoughts would be appreciated.

    Many thanks
    Mark

    • Andrew Sullivan

      Hello Mark,

      Thank you for taking the time to post your questions.

      When the policy for a VVol object is modified the VASA Provider will evaluate whether it needs to be moved into a different FlexVol and will take the appropriate remediation action automatically. It will not, however, modify FlexVol settings to accommodate the policy.

      I can not comment on road map, but rest assured that your concerns are known and that we are working to address the limitations of the current implementation.

      Thanks!

      Andrew