There’s a lot of noise in the marketplace about VMware vSphere Virtual Volumes (VVol). If you want to turn up the (virtual) volume, then you’ve got to find the signal. To get your head around VVol, start with the fundamentals— the Five Ws + HOW of VVol.
Before VVol, the Virtualization admin and Storage admin would have to work together to assign VMs to LUNs that could (hopefully) deliver the right performance characteristics. They needed a spreadsheet with a list of LUNs and volumes with their settings so they could choose the right location for each VM. After VVol, the Storage admin creates storage containers with specific policies—think ‘tiers’ like gold, silver and bronze. Later, the Virtualization admin provisions a new VM and assigns desired policies. The VVol API then communicates with the storage containers to find the right location—that’s part of the VVol magic.
VVol is not a product that you deploy, it’s an API that your storage provider ‘exposes’. And so the VVol capability you receive depends entirely on your vendor’s underlying structure and ability to implement VVol.
Check out this simple table to see the difference between conventional (LUN and volume-based) storage with NO VVol, conventional storage with VVol, and Tintri.
There are lots of reasons why VM-level storage management is attractive. Here are three of the most commonly cited benefits:
1. Dynamic Resource Scheduling. VVol will help you determine how to rebalance storage space and I/O load for better performance.
2. Snapshots and Clones. VVol let you take snapshots and create clones at the VM level (instead of the LUN or volume level).
3. Less back and forth. The storage admin sets up the containers. The virtualization admin selects their desired feature sets. VVol handles the ‘negotiation’ that matches VMs to containers so the admins don’t have to.
As noted above, most conventional storage providers will struggle to fully implement the VVol API. Here are a few specific scenarios where they simply cannot deliver:
A. You have a hypervisor other than vSphere 6. If you have vSphere 4 or 5, or Hyper-V, RHEV or OpenStack you are out of luck... well, unless you use Tintri, which offers VVol-like capabilities for all of the above.
B. You need to guarantee Quality of Service. VVol lets you ‘select’ desired Quality of Service... it does NOT let you ‘set’ precise QoS. So, it improves the likelihood of getting the right performance, but certainly doesn’t let you guarantee it.
C. You need a large number of VVol. You won’t need a few VVol; you’ll need thousands. Since most storage providers have built their arrays to manage dozens or hundreds of LUNs and Volumes, this is a massive increase in the number of ‘units’ to be managed. To truly implement VVol, those providers will need to re-write their entire operating system—so, most will look for shortcuts.
A lot of people think you need 1 VVol per 1 VM. A lot of people are wrong. Here’s a simple formula for calculating the number of VVol needed for a specific VM.
Phew—in brief, you’ll need a minimum of three VVol for every VM, and as many as hundreds or thousands of VVol for every one VM. So, if your average VM needs 400 VVol, and your storage array supports 10,000 VVol, then it can only store 25 VMs.
To find a storage provider that can help you fully realize the potential of VVol, ask them these four questions. To save you the trouble, we’ve inserted our answers:
Unique control with VM-level actions for infrastructure functions including snapshots, replication and QoS make protection and performance certain in production, and accelerate test and development cycles.