Take Five With Tom Fenton

5 Reasons To Adopt vSphere Virtual Volumes

If you haven't yet looked into the technology, it's time.

• By Tom Fenton
• 10/30/2015

At VMworld 2014, there was a lot of chatter about vSphere Virtual Volumes (VVols). After the show, I spent a fair amount of time investigating VVols and came away impressed with the technology. As part of this investigation, the company that I worked for, Taneja Group, created a market landscape report of the storage companies that had announced that they would be supporting VVols on their arrays. We identified 23 storage companies total, 11 of whom responded to our survey and answered our follow-up questions. From this information we created a market landscape report of these companies and categorized the VVols providers into three groups. That report can be found here. 

It's now been a year a year since VVols was announced, and I've come to the conclusion that if you use vSphere, you should adopt vSphere Virtual Volumes. Here are five reasons why.

• Data movement. One of the features of VVols that doesn't get enough attention is its ability to instruct the array on which it's running to change a virtual machine's storage policy in the background. If you want to increase the performance or resilience of a virtual machine (VM), you can change the storage policy in vSphere and the array; if it has the capability to do so, it will in the background. No longer do you need to use vMotion or interact directly with the array to change the characteristics of your VMs.
• Industrial adoption. The industry is behind VVols. More than 23 storage companies have announced that they would be supporting VVols on their arrays, and eight have already released VVol-capable arrays. A list of the companies on VMware's HCL can be found here. These companies are betting VVols will be big, and I haven't seen that any are charging for this functionality on their arrays.
• Unlimited capabilities. VMware is very liberal with the array capabilities they're allowing storage vendors to surface up with VVols. These range from the characteristics expected from arrays (e.g., performance and resilience) to ones that we don't usually associate with storage, such as allowing storage costs to be used in storage policies. Basically, any capability that an array has can be surfaced up to a policy.
• Efficient use of storage. Due to the storage granularity of VVols, you no longer need to carve out and provision an entire LUN and consume a portion of it; you only use the portion of the array you'll actually be consuming.
• Lifecycle management of VMs. VM lifecycle management is tedious work that often gets overlooked. It takes dedication and planning cycles to make sure that a VM is on the right storage during its lifecycle. With VVols, it's trivial to move a VM from being serviced on high performance, highly resilient storage during its production phase to be being delegated to lower performance, lower resilient storage when it enters its retirement phase. And if the array supports these capabilities, it can be done transparently, without user interruption and data migration, by simply changing the storage policy.

So there you have it: five solid reasons why you will be using VVols. Be sure to check the VMware HCL to see if your array is currently supported. If it isn't, ask your vendor how soon it will be.