For the last few years, VMware Virtual Volumes (VVOLs) have been "on the way." VVOLs are a transformational way...
to manage storage for virtual machines and aim to erase all of your storage management pain. Senior technical workers at VMware have definitely been talking up VVOLs, and now, with vSphere 6, you can finally access the feature. So, what do you need to have in place in order to deploy VVOLs?
Before you start anything, you should check VMware's hardware compatibility guide for VVOLs and check whether your array supports VVOLs. Most likely, it will be bad news, because there is a very short list of supported vendors and array models. At the time of this publication, fewer than a dozen vendors support VVOLS, and VMware's parent company, EMC, is notably absent. This reminds us that VVOLs support requires a lot of engineering work by storage vendors. As with previous vStorage API for Array Integration support, your array vendor is going to need to build VVOLs into their array.
This means that your array will need a firmware upgrade in order to support VVOLs. This isn't going to be a five-minute job. Upgrading array firmware is a high-impact activity that needs planning and careful execution.
The next thing you will need to do is upgrade to vSphere 6. Again, this is a significant upgrade and needs to be executed with careful planning and lots of testing. Now that vSphere 6 has been out for six months, it is time for the more conservative enterprises to plan deployment. VMware recently released Update 1 for vSphere 6.0, and this will be an indicator for customers who follow an N-1 version deployment that they can now deploy 6.0 to production.
The final piece is the vSphere API for Storage Awareness (VASA) provider. This piece of software is the conduit between vCenter and the array. The good news is that this is usually a trivial thing to deploy. Usually, a Windows Server gets some software installed, and it's often installed on the same machine that you use for conventional storage management, using your array vendor's tools.
You may already have a VASA provider deployed to help with policy-driven storage management in vSphere 5.5. This VASA provider will need to be upgraded in order to support VVOLs. The upgrade allows far better integration between the storage array and vCenter. An updated VASA provider is an essential part of having the array certified to support VVOLs.
Of course, if you wanted VM centric storage management that is like VVOLs, then you could have it on vSphere 5.5 -- but only if you deployed VSAN. VSAN allows you to set storage policies on a per-Vm basis on vSphere 5.5, and it continues to do so on vSphere 6.
The question then becomes, why do you want VVOLs? The answer should be that you have a significant storage management problem that will be addressed by VVOLs. There are undoubtedly significant issues managing storage in large vSphere environments. Many environments are unable to use Storage Distributed Resource Scheduler to ease these issues. VVOLs are VMware's way of addressing these problems. It puts much of the storage management back on the array vendors, who must now complete the engineering to make it happen.
VVOLs are a big change to storage management for VMs, and like any large change, there are risks that come with it. VMware vSphere 6 is the first mainstream release on VVOLs, and storage vendors will be releasing their first VVOLs support soon. The probability of problems with any technology is highest when it is new and fast-changing. You need to be ready for issues to arise, and you must also have great faith in the quality of your array vendor's development efforts.
VVOLs are still not a mainstream technology and require many component updates before it can be deployed. VVOLs will be beneficial to large customers once they complete a series of upgrades. But it is unlikely that any customer will undertake these upgrades just to get VVOLs. VVOLs will be a bigger benefit when other requirements drive the upgrades.
How array-based replication gives VVOLs 2.0 a boost