As I’m following closely the growth and evolution of this new technology for vSphere environments, and I’m still in search of a solution to play with VVOLs in my lab, I’ve found an article on the blogosphere and some additional comments on Twitter that made me re-think a bit about the real value of VVOLs.
It’s just a “per-VM” storage?
The original article comes from one of my favorite startups, Coho Data. In this article Suzy Visvanathan explains how Coho being an NFS-based storage doesn’t really need to support VVOLs. To me, this article sounded strange from the beginning, especially considering Suzy just joined the company and she was previously at VMware exactly in the VVOLs team as a product manager.
I’m not going again to explain what VVOLs are and how they work, there are plenty of articles around. What I see some of those articles are missing, and the one from Suzy is no exception, is one half of the story.
Indeed, the biggest and most visible effect of VVOLs is the per-VM management now possible in the storage. No more huge LUNs holding dozens of VMs, where every activity needed to involve all the VMs in the same storage. Now with VVOLs each VM has its set of dedicated “volumes”, and any operation like a snapshot or a replica for example can be targeted at that specific VM. Is it such a great innovation? To me yes, but for people using NFS storage arrays this is something already possible before VVOLs: each VM file (a vmdk virtual disk, a configuration file, a log…) was already visible as a single distinguished file in the file system, and as such used as the atomic unit of storage even before VVOLs for any operation. And since Coho exposes its storage as an NFS share, here comes probably the bias of the article.
It’s all about policies
Yes, per-VM storage management is great, no doubt (thanks to HP Storage for the nice graph):
But this same picture shows also the other, and in my opinion even more important, part of the architecture: Policy-Based Management.
SPBM, Storage Policy Based Management, is in my opinion the real big innovation of VVOLs as much as it’s the VM granularity of the storage layout. Said even more explicitely: the real innovation is probably the SPBM, and simply without per-VM management it wouldn’t be possible or so effective, thus the new storage layout has simply been a requirement to enable SPBM.
VM deployments and management are now policy driven: storage capabilities are surfaced up to vSphere, admins build policies by selecting the desired capabilities, the policy is chosen when the VM is deployed, and finally the VM’s VVOLs are created in the correct position of the storage array to comply to the policy requirements. These capabilities vary from storage vendor to vendor, but since there is no hard list of VVOLs capabilities, it all comes down to the array itself and what specific or unique features it has. And thanks to the VASA Provider exposing these capabilities to vCenter, all it’s in control of the Storage vendor: vSphere will simply consume the capabilities the storage has.
And because of this, I think it doesn’t matter if your storage already supports per-VM layout in the storage array. You still want to support VVOLs to expose your features to vSphere and have it consume them. Say you are a startup with some great features nobody else has, well this is exactly the reason to support VVOLs and have vSphere use your features.
Per-VM granularity and policy-driven management has taken indeed a lot of time to arrive in VMware environments, but now that they are available, it would be a shame to ignore them just because your storage is NFS-based.