This is a multi-part series covering various aspects of VMware Virtual Volumes (VVols) from support to adoption to benefits to predictions and more. In part 1 we’ll take a look at what VMware has delivered so far with VVols and the VASA specification.
In the first part of this series on VVols let’s do a brief history of the timeline for VMware’s development of VVols:
- August 2011 – VMware first introduces the concept of VVols at VMworld
- August 2012 – VMware shows off tech preview of VVols at VMworld
- July 2014 – VMware make VVols available as a public beta
- March 2015 – VVols 1.0 makes its initial debute as part of vSphere 6.0
- November 2016 – VVols 2.0 is released as part of vSphere 6.5 with support for array replication
- November 2017 – vSphere 6.7 includes minor VVols enhancements
- August 2018 – VMware announces VVols support for SRM
From this timeline we can see that VMware has been working on the development of VVols for over 7 years and it has been part of vSphere for almost 4 years. That’s a pretty long time but what’s important to note is it’s been a bit of a work in progress as VVols required massive engineering on VMware’s part, to get VVols to work VMware had to request changes to the SCSI T10 specifications and also filed patents on the new architecture.
The initial release of VVols in vSphere 6.0 had some shortcomings, the biggest being lack of support for VVols replication. In addition there was very limited partner support for VVols early, only 2 major storage vendors supported it at launch. vSphere 6.5 brought both maturity for VVols and support for array replication and I consider that to be the release that was ready for prime time. The support for array replication however came with an important caveat, there was no support for SRM and all BC/DR operations had to be manually scripted using PowerCLI which made the solution unappealing.
vSphere 6.7 further enhanced VVols in small ways and today VVols is pretty rock solid from VMware’s side. Now it’s really on the partners to build out their solutions for VVols, the only barriers that exist today for partners to do whatever they want with VVols are their engineering resources. As VVols represented a massive engineering feat from VMware the same is equally true for partners as well. VVols represents a fundamental change in how storage arrays interact with vSphere and the greatly increased number of objects that a storage array needs to support for VVols. As a result this put a pretty hefty burden on partners to engineer their arrays to support this new architecture.
The introduction of VVols also had a ripple impact on other VMware products as well, one of the biggest challenges to VVols adoption has to do with support for VVols across VMware products such as SRM, vROps, vCloud Director and more. As those products were in other BUs from the core storage development team it was up to the other product teams to prioritize their support for VVols. As a result support for VVols in other VMware products has come at varying paces. Today almost all VMware products support VVols, the lone exception being SRM but that is in the works and is expected to come next year.
So what’s next for VVols? As I mentioned VMware is mostly done with the current VASA spec for VVols and there are no longer any limitations or barriers for partners to build solutions. It may seem like VMware isn’t doing that much further development with VVols today but that’s simply not true. While VMware is waiting for partners to play catch up, I have seen the VVols roadmap going forward and there is plenty on it to optimize and enhance VVols further and support some newer storage technologies. I also know that VMware has even beefed up their VVols engineering team.
I feel that VVols is in a very good place today and VMware has done a great job to get to this point as this was no easy feat and represents almost a decade of work on their part. VVols has a bright future ahead of it and at some point I would expect that VMFS will eventually go away much like the old ESX hypervisor did when it was replaced by ESXi. The burden is mostly on partners at this point but continue to look for further refinements from VMware going forward as storage policy based management becomes the de facto standard in the virtual data center.
