VMware Virtual Volumes has been in development for quite a long time, almost 10 years now if you count the development before it launched as part of vSphere 6.0. I personally have been involved with it from a partner perspective for that long so I have had a behind the scenes view of how it has evolved.
So let’s start at the beginning, before there was vVols, there was VASA, the vStorage APIs for Storage Awareness. VASA was introduced as part of vSphere 5.0 as a way for storage arrays to pass information to vCenter about array hardware and software features. Prior to VASA vCenter just saw a LUN that was presented to it and no information about it was available, was it a spinning disk or SSD, what Raid level did it have, was it thin or not, etc.
So VASA 1.0 was introduces as a way for storage arrays to pass a string on information to vCenter that described the LUN’s characteristics. Armed with that knowledge you could then build storage profiles using those characteristics and assign them to VMs based on requirements and SLA’s. The initial release of VASA was very basic, the array had to provide a single string to vCenter that had the capabilities of the LUN together inside of it, so something like: “HPE_STORAGE, DriveType_FC, RAID5, ThinProvisioned, PhysicalCopy, NotInRemoteCopy” was passed to vCenter.
Below is a clip from the original VASA 1.0 Programming Guide describing it:
The original VASA 1.0 was not used by many as it was pretty basic but it was a step in the right direction, VMware took that VASA framework and greatly expanded it to create Virtual Volumes. While Virtual Volumes launched as part of vSphere 6.0 in 2015, it actually was announced at VMworld 2013 as part of their storage announcement keynote.
Virtual Volumes then launched as part of vSphere 6.0 with great fanfare, I remember working closely with VMware on a whole slew of deliverables to support the launch. Not many vendors supported it at launch, at that point it had been in development for almost 5 years and only 4 vendors supported it on day 0 (HP, IBM, NEC and SANBlaze).
The initial reaction to vVols was lukewarm, there was a lot of interest but not many vendors supported it and there were many limitations back then. One of the key limitations was that it did not support array based replication. That was then fixed by the release of vSphere 6.5 which included support for replication, but only HP supported it at launch and it would be many years before more vendors supported it.
After that it was relatively quiet for a long period of time, there was a minor spec increment (VASA 3.5) as part of vSphere 7.0 U1 but many partners were still trying to develop their support for vVols so VMware was holding off adding more big features to the roadmap until more partners caught up.
That brings us to the present and the launch of vSphere 8.0 which includes the VASA 4.0 specification which adds support for NVMeoF to vVols. Initially this support is for FC only but VMware plans to release additional protocol support as part of updates to vSphere 8.0.
Looking to the future, VMware has a VASA 5.0 program in the works which greatly improves the certificate framework that vVols uses between the host, vCenter and storage arrays. After that comes the long awaited support for stretched clustering as part of VASA 6.0. This has been a key one that many customers are waiting for before they will consider using vVols.
VASA 6.0 is a huge engineering effort both by VMware and it’s partners to deliver the same stretched storage architecture that is used with VMFS in a vMSC config. Before VASA 6.0 existed we looked into how we could support this using the current VASA 3.x spec and it was very complicated and a massive amount of work to pull it off.
VMware recognized the need to support this and proceeded to modify the spec to support new objects like stretched storage containers and stretched vVols across various host connectivity configurations. Thus VASA 6.0 was born which created the framework to support stretched clustering and made it easier for storage vendors to develop their own implementations.
Below is the complete timeline history of vVols:
So we’ve come a long way with vVols and there is more good stuff coming soon. vVols is not what it was when it launched 7 years ago, it has become more mature, more robust and more capable than ever before. VMware is really putting in a lot of effort right now into vVols, their have been numerous small improvements under the covers with each release. I predict by next year we will see faster adoption of vVols and we will finally get to mainstream adoption.
It’s been a long journey with vVols and it has greatly evolved since those early days. I’ve been on that journey with VMware since the beginning and I look forward to seeing it through to the end.
