In case you’ve been head down, buried in work this week you may have missed the announcement of VMware vSphere 6. If you are a VMware admin, you have likely been tracking this release for over a year. However, if you are a storage admin or have broader responsibilities, it isn’t likely you have been following every VMware rumor. One of the long discussed features released is Virtual Volumes, or VVols.
I admit it; I love VMware’s new VVol capability. As analysts, we tend to be reserved with our praise of products. In part because we literally have seen most things before, usually several times and always with the claim of being “revolutionary” or “redefining” something. When something comes along that is truly new and revolutionary, it’s nice to be able to say so.
Right about now everyone is a hipster, claiming “I knew VVols were going to be cool long before anyone else did.” Well, I am no such phony. I have to admit that when I was first briefed on VVol’s over two and a half years ago (before VMWorld 2012), I was not taken with the concept.
In part, I believe it was because the concept was not fully baked, and hence VMware was not able to explain it fully. “Why would we want yet another I/O interface?” I thought. Also unclear was if VMware could really pull off creating yet another storage management interface in a year. Turns out they could not deliver that in one or two years. But they have done so in two and a half years, which is still a huge feat. (I got involved with SMI-S before Bluefin, so I have seen how long storage management interfaces take to evolve).
Now I am a bit ahead of the curve with VVols, because like some of you, as a VMware TAP member I had early access to VMware 6, along with VVols. So we have been investigating the capabilities for a while. Over the past few months I have been able to really dig into the details, by running tests with several vendors who support VVols in our lab.
After overcoming issues with beta products and beta documentation, along with a new vCenter web client, etc. we were able to really test the features of VVols. The more I saw, the more I liked. I found VVols to be easier to use than I anticipated, while also better integrated with each storage system, vCenter and vSphere than I anticipated. This is what hyper-visor based storage management should have always been: Pure, simple, but powerful.
Typically, a first release of anything is limited in scope. Many of the nice ideas promised are not fully baked, with a lot of hints of future greatness to come. Not so with VVols; everything I heard promised has been delivered and more.
Specifically, here are some of the reasons VVols are valuable:
• VVols work with any type of storage (block and file)
• Preserves (most) of a storage administrators control over storage, if they want to retain control
• Enables the Hypervisor admin to manage most aspects of storage, if they want to do so
• Reduces the complexity of managing hundreds or thousands of storage Volumes, along with the thousands of paths, multi-path controls etc.
• Adds the ability to perform policy based storage management within vCenter, using storage system specific capabilities
• Adds the ability to leverage storage system features (such as snapshots) within VMware, without needing to use yet another vendor plug-in
• Adds the ability to monitor storage performance on a per VM basis, down to the individual virtual disk within a VM, both from the hypervisor and storage system
• These and many other features make VVols a huge leap forward in storage access and management
VVols are here. Not only are they here, I believe they will soon dominate the VMware storage ecosystem. Why would you want chopped steak after eating filet mignon? Well, you wouldn’t, and soon you won’t want to use non VVol storage either. For once, someone delivered on their promise to “Redefine Storage.”
We have several VVol reports coming soon, so stay tuned for more details.