Next month VMware’s new Virtual Volumes (VVols) storage architecture will turn 3 years old as it was released as part of vSphere 6.0 in March of 2015. Since it’s initial release adoption has been very slow, I believe VMware estimates less than 2% of customers are using VVols. So will 2018 be the year of VVols and will we finally start to see more mainstream adoption? I’d really love to answer that question with a yes but to be realistic I’d probably have to answer it as no and the reason for that VVols has several things working against it which is the root cause of slow adoption.
Lack of VMware marketing
Now I know VMware has backed off on marketing VVols and I understand their rational as they see it as core architecture but it wouldn’t hurt to promote it now and then to help out the partner community. Except for the VMware VVols product team doing some occasional things you really don’t find many other people at VMware talking VVols up. VMware does have a VVols product page but it seems most of their marketing and promotion is focused on things like NSX, vSAN and AWS.
To be fair VMware did do a ton of marketing around VVols the first year or so after it was released, but the timing wasn’t right back then, partners weren’t ready (only 4 supported it), customers weren’t ready (nobody rushed to vSphere 6), heck even VMware wasn’t completely ready until vSphere 6.5 (no replication). Now is really the time for them to be marketing VVols as the maturity level for VVols has greatly advanced over the last 3 years for both VMware and especially the partner community.
Partners not ready
Developing a VVols solution is no easy task and represents a hugely significant development commitment for partners. Over the last 3 years partner solutions for VVols have been slowly emerging and improving in fact the last major storage vendor to not have VVols support (Pure) just finally released their VVols solution recently. This isn’t a knock against partners really, when you factor in the major changes that you have to make in your storage architecture to support VVols with all the other non-VVols development work that partners need to constantly do to improve their platforms it’s a heck of a challenge to deliver a robust and scalable VVols solution.
I know in my company we have spent 6+ years working on VVols with a dedicated engineering team focused on it. Scaling VVols is one of the biggest challenges and most block storage arrays were never equipped to handle tens of thousands of LUNs that VVols could potentially require (1000 VMs = 3,000 LUNs at a minimum). In addition the way storage arrays interact with Protocol Endpoints and VASA Providers requires a whole different approach from a storage array perspective compared to VMFS.
I think most partners are a lot more ready then they were 3 years ago but I don’t think you could point to any one partner and call them done with VVols completely. I’d have to say all of them still have VVols support roadmaps stretching out for months and years. Today there are about 20 storage vendors that show in the VVols HCL as support it on vSphere 6.0, 13 of them supporting it on vSphere 6.5 and only 3 that supports the VVols replication functionally in vSphere 6.5. However just being on the HCL speaks nothing of what you actually support with VVols which is different across every partner and how well you scale with VVols as well. Hopefully partners keep working hard to improve their VVols solutions.
And as a final comment, VMware is mostly done with the development of VVols, it’s not really on them anymore to deliver missing functionality. There really isn’t any roadblock for partners to engineer a complete VVols solutions at this point. From what I’ve seen the VVols roadmap going forward mainly centers around some optimizations of VVols operations and things like bringing bind operations in band. The upcoming vSphere release brings some minor improvements to VVols but it really is feature complete from a VMware perspective.
Bad first impressions
You only get one chance to make a first impression and that impression can have a lasting effect on people. For anyone who tried out VVols early on when most partners had new and incomplete solutions the VVols experience may not have gone all that great for them. Because of that bad first experience they may have already made up their minds about VVols and stick with what has been working just fine for them for years and years. As a result it’s hard to convince those people to give VVols another try on a more mature and feature complete VVols solution.
What is really at the root of this problem is that it typically takes years and years to completely engineer a VVols solution and if you release it too early when it isn’t complete and fully baked you risk giving users a bad VVols experience. VVols is a lot different from other VMware integration’s like VAAI and vCenter plug-ins. It requires a vendor to make big changes to their core storage arrays and to engineer a scalable solution that supports a wide variety of array capabilities advertised to SPBM takes a lot of effort. Most vendors I’ve seen have released solutions and have slowly improved them over time. Pure seems to be a notable exception to this as while they were showing off VVols years ago, they appeared to have held off on delivering their solution until recently.
So for anyone who may have had a bad first impression with VVols, I strongly encourage you to give it another try. VVols has some fantastic benefits over VMFS and partners have come a long way since the early days. Work with your partners, see where they are at today with VVols and how their roadmap looks. At some point I fully expect VMFS to go away and VVols will be your only option so don’t wait too long which leads me to my next point.
No sense of urgency
Right now there is no sense of urgency from VMware to switch to VVols and I don’t think we will get that sense anytime soon. If VMware really wanted to drive people to VVols they can do what they typically do when they offer two things that are similar in nature, announce the EOL of the old one to get people moving to the new one. Remember when so many people stuck with ESX as their hypervisor of choice despite there being a new and better option with ESXi? Some people simply don’t like change, they stick with what they know and are used to and are very resistant to switching to something new despite the benefits. Once the partner ecosystem caught up with supporting ESXi it took VMware to finally say enough is enough you have no choice in the next vSphere release it’s ESXi or nothing to get people motivated to switch.
The same holds true for other vSphere duplicate functionality, VMware made you give up your vSphere C# client, the days of vCenter running on Windows are numbered and soon HTML5 will be the only web UI. Now I know right now isn’t the time for VMware to announce any EOL of VMFS but at some point they’ll have to set a sense of urgency with customers to get them moving to VVols. It also wouldn’t hurt if VMware dropped some subtle hints as well at some point. Right now I don’t think customers know VMware’s strategic plans for VMFS and VVols, it’s more of you can choose either this or that and not you should move from this to that. Once VMware does set expectations accordingly and deprecates the old I think we’ll see a big wave of people moving to VVols.
Lack of support and documentation
I’ve heard this from many people, call VMware for VVols support and many times it’s hard to find someone who know enough about it to help resolve issues. I’m guessing this is more of VMware support not getting a lot of calls on VVols and therefore not having a lot of experience with it then a lack of VMware training support people on VVols. I’m thinking the same might hold true for partners supporting VVols as well. Also you have the potential for finger pointing between partners and VMware back and forth as well, in many cases customers are probably calling VMware first and the reality is many VVols support issues are probably partner related as most issues are probably related to partner implementations and not the VASA spec. All in all this can result in frustrated customers, I expect this to improve over time as support teams get more experience with VVols.
When it comes to documentation and other VVols support material (i.e. blogs, videos, white papers, etc.) some vendors have done a fairly decent job with this but from what I’ve seen other vendors have not done very well at all. I’ve looked around at some vendors when doing research and I constantly see either very dated or no material to help customers understand and implement VVols. I know at my company I’ve done all I can to get as much out there as a possible, that includes creating white papers, analyst reports, blogs, video, webinars, VMUG sessions and more. Lack of VVols documentation and materials can definitely frustrate and turn away customers wanting to check out VVols. I’d encourage all partners to do a better job with this, don’t put all that engineering effort into VVols and skimp out on documentation.
Lack of partner marketing
It truly is on the partners to promote their own VVols solutions. This isn’t VAAI where every partner integration is mostly the same thing supporting core primitives. At it’s core VVols is mainly VASA which is the specification that VMware writes that allows storage vendors to develop VVols solutions specific to their own arrays. As a result every storage vendor is going to have their own unique VVols solution where they can pick and choose what capabilities they want to advertise to storage policies and what features they want to implement to support with VVols. It’s up to each vendor to decide what they want to do with VVols, they can offer basic capabilities or they can get innovative with their solutions and do cool things that other partners aren’t doing.
Since every partner solution is vastly different with VVols, partners need to market their own unique solutions! If all partners stepped up their VVols marketing I bet we would see a lot more adoption. Right now many people don’t know what VVols will do for them and why they should switch to VVols. It’s on the partners to get the word out and make people want to move to VVols especially now that VMware has gone largely silent in promoting VVols themselves. How does any company sell something? They market it to raise awareness! Unless we see partners doing more promotion of VVols the slow adoption trend will continue.
Final thoughts
So 2018 may not be a big year for VVols but I know adoption will slowly continue to rise. As time progresses I believe that pace will be more rapid. As I’ve said over and over VVols has many benefits and is the future for external storage in vSphere. It’s not a matter of if people will switch to VVols it’s a matter of when they will switch. If VMware and partners work together and address some of the things I have talked about here it will go a long way to getting VVols to see more mainstream adoption. I for one want to see that sooner rather than later so I’ll continue to do my part and hope others do so as well. Viva Las VVols!
