October 2022 archive

The Past, Present and Future of VASA and VMware vVols

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.

Share This:

Why are so many VMware customers still on vSphere 6.5 & 6.7?

vSphere 6.5 and 6.7 is set to go end of support next week and vSphere 7.0 has been released for over 2 and a half years now while vSphere 8.0 is due out next week.  Despite this a large percentage of the VMware customer base is still running 6.x versions even with them going end of support very soon. In this article I’ll take a look at some adoption stats and try to answer the question of why so many customers are still on vSphere 6.x.

First let’s look at the key timeline milestones for the major vSphere releases.

Product release General Availability End of General Support End of Technical Guidance
vSphere 7.0 2020-04-02 2025-04-02 2027-04-02
vSphere 6.7 2018-04-17 2022-10-15 2023-11-15
vSphere 6.5 2016-11-15 2022-10-15 2023-11-15
vSphere 6.0 2015-03-12 2020-03-12 2022-03-12
vSphere 5.5 2013-09-22 2018-09-19 2020-09-19

Now lets take a look at some version stats. We track the vSphere versions that customers use from the telemetry data of our storage arrays, VMware also tracks this as well via their vCenter analytics. Below is a look at that data from recent time periods to show what versions of  vCenter and ESXi customers are running.

April 2022

vCenter version
6.7 4,487 46.2
7.0.3 3,131 32.3
7.0.2 910 9.4
6.5 843 8.7
7.0.1 133 1.4
6.0 106 1.1
5.5 54 .6
7.0 46 .5
ESXi version # %
6.7 33,225 47.9
7.0.3 12,702 18.3
6.5 11,555 16.7
7.0.2 6,811 9.8
7.0.1 2,724 3.9
6.0 1,910 2.8
5.5 364 .6
7.0 168 .3

From these numbers we can see that about 6 months ago 56% of customers were running vCenter 6.x and 67% are running ESXi 6.x bringing the majority of the VMware customer base on the older major release of vSphere. If we contrast this to today here’s what the numbers look like.

October 2022

vCenter version # %
7.0.3 5,578 50.5
6.7 3,781 34.2
6.5 724 6.6
7.0.2 691 6.3
7.0.1 112 1.0
6.0 84 .8
5.5 44 .4
7.0 40 .4
ESXi version # %
7.0.3 28,717 37.7
6.7 28,223 37.0
6.5 9,925 13.0
7.0.2 5,462 7.2
7.0.1 1,850 2.4
6.0 1,532 2.0
5.5 365 .5
7.0 185 .2

We can see as of today that 41% of customers are running vCenter 6.x and 52% are running ESXi 6.x. So customers are finally starting to get off 6.x as it nears it’s end of support date next week. But there is still a very large percent using 6.x, especially on the host side.

I’ve always wondered why customers sit on those older versions so long instead of upgrading and gaining the new features and benefits that newer releases offer. Here are a few reasons I can think of why they stay on older releases.

  • If it’s not broke, don’t fix it. Hey if it works, meets your requirements and you don’t care about new features then why upgrade which always carries a risk of something not working after the upgrade or issues while doing the upgrade. You also run the risk of compatibility issues as well.
  • It takes time to upgrade. Larger enterprises with hundreds/thousands of hosts can take a very long time to do upgrades and the process can move very slowly to plan it out and get it done.
  • Older hardware doesn’t always support newer software. Often times vendors will not qualify and certify newer versions of their software on older hardware platforms as they don’t have resources to test that many versions.
  • Issues with licensing. I’ve heard in the past some applications like Oracle are more licensing friendly on older vSphere versions due CPU socket limits. Also upgrading typically means you have to invest in more licensing costs.
  • Compatibility issues with apps and hardware. Sometimes certain applications or hardware is not cross compatible with newer versions of vSphere. In some cases it can take a while to achieve application cross compatibility nirvana across all your software and hardware as you wait for vendors to support newer versions. Also sometimes customers might be fearful that something may not work properly on newer versions.
  • Refresh cycles can be along time coming. Some customers only do hardware refreshes every 5+ years and they typically wait to upgrade to newer vSphere versions until then. It can be a lot easier to stand up a whole new hardware environment running the latest versions of vSphere and then slowly migrate your VMs to it. Performing upgrades in place can carry some risk that customers may want to avoid.
  • Nobody wants to deal with bugs. Newer software inherently carries the risk of being buggy until it has been thoroughly tested by the install base over a long period of time. As software products get more and  more complicated the risks can increase and some customers want to play it safe and wait until it has matured before diving in.

So which version will most customers eventually migrate to? From the looks of it 7.0 U3 is where most customers are heading as it’s the latest and most stable release. With vSphere 8.0 releasing next week it’s doubtful that customers will move to that release in mass as historically most customers avoid new major releases until they mature and updates are released. With the past trends we have seen with vSphere 5.x & 6.x it will most likely be years before vSphere 8.0 becomes the majority release.

So if you’re one of those customers on vSphere 6.x or were very slow to migrate to vSphere 7.0 I’d be interested to hear your reasons for staying on the older versions so long. I’m sure there are other reasons that I have not covered here, so leave a comment and let me know.

Share This: