It has been over 7 years now since VMware Virtual Volumes (vVols) was released as part of vSphere 6.0 but adoption remains extremely low to this day. I’m going to cover the reasons for that, where vVols stands today, what the future looks like and what needs to be done to more rapidly increase adoption.
First let’s talk about the technology “Crossing the Chasm” which visualizes the customer journey of adopting new technology. With new technology you typically have a small group of innovators and early adopters that like pushing the envelope and trying new things right away. You then have a “chasm” that you must cross before more customers trust that the technology is worth adopting often looking towards other customers to see if they are using it yet. This chasm is the make or brake point for a product going mainstream and being successful.
Pure Storage did a recent Tech Field Day and used the Chasm metaphor to show where they see adoption is today. I frankly don’t agree with their assessment and the numbers back me up. They claim we are in the early/late majority stage right now which simply isn’t true. I have tracked it across several of our storage platforms since the very beginning and I can tell you it’s still in the range of about 5 percent of arrays are configured to use it. The VMware telemetry data across their customer base on vVols adoption backs this up.
If you look at the Pure illustration of the Chasm below they break it down into Gen1 and Gen2 vVols with Gen1 being the early market of Innovators and Early Adopters and Gen 2 being mainstream majority market.
The current adoption numbers simply don’t back this up though, we’re still very much in early adopters stage with less than 10% of arrays using vVols. I would argue that Gen 1 of vVols was the Innovators stage, Gen 2 of vVols is the Visionaries stage which we are currently in and Gen 3 would be the stage when vVols finally crosses the chasm.
After 7 years you would expect a feature or product to see mainstream adoption, so why isn’t vVols there yet? I presented a list to VMware a while back of what I felt were the barriers compared to VMFS and what needs to be done to overcome them.
Some of the above list is being taken care of, there is a new certificate mechanism coming in VASA 5.0 that should make it easier to manage but you will still have to deal with certificates. Stretched clustering is in the works as well as part of VASA 6.0, it’s still fairly far out though. As far as it being completely done and on par with VMFS the upcoming VASA 4/5/6 should take care of most of that but there are still a number of challenges that VMware and partners must tackle before it can approach mainstream.
One additional area that is not on my list is with backup and recovery. Not all backup vendors have full support for vVols and have limitations and restrictions. I feel VMware needs to work with backup vendors as well to get them to fully support vVols. Additionally VMware needs to treat vVols as prime time and a first class citizen when it comes to any support and new features. Historically things typically come first to VMFS and later on to NFS and vVols.
As far as driving faster adoption, I’ve told VMware over and over until they announce they are deprecating VMFS people are going to sit on it forever. Historically this has proven true, customers sat on their ESX Service Consoles until VMware forced them to give them up and switch to ESXi. I don’t feel that VMware will ever deprecate VMFS though so this is going to require other ways to motivate customers to move to vVols which will be challenging.
One solution to this is for partners and VMware to work together to gently force people to start using vVols. Dell/EMC has done a good job with this on their PowerStore platform by pre-configuring vVols on their arrays and documenting that it’s a best practice to use vVols for an optimal experience. I know on HPE with the new HCI Manager UI for dHCI we also only allow VM’s to be created on vVols datastores. VMware could do their part by prioritizing vVols in their client UI’s and documentation to encourage customers to use vVols over VMFS.
Another thing I have told VMware what they really need to do to get adoption going faster is to relaunch and/or re-brand vVols to reintroduce it to customers. vVols was launched to much fanfare over 7 years ago and I was heavily involved in that launch planning all sorts of deliverables jointly with VMware to market it. However back then nobody was ready for vVols, it had many limitations, it wasn’t close to being done so all that effort was really wasted. Customers that did try vVols back then often had a bad experience with it and have no desire to repeat that.
Now vVols has come a long way in 7 years from a product development perspective but until the major programs (VASA 4/5/6) that are currently being developed that add some major functionality to vVols are complete it’s still not the right time to re-launch vVols. Once VASA 6.0 goes GA it will be the perfect opportunity to re-launch it and re-introduce it to customers. I strongly feel that they should re-brand it as well, this is commonly done to distinguish an old product that customers may have had a bad experience with to a newly revamped product.
vVols will get mainstream at some point, the benefits are well defined and VMware has put a lot of recent development effort into improving vVols. It’s on partners as well to speed up and prioritize their development of vVols so they make for a compelling solution across all storage platforms. There are partners that have great vVols solutions today but there are others that have lagged behind. One reason for this is when a product has low adoption it becomes difficult to make the case to prioritize engineering resources to it.
Despite the low adoption to date, vVols has a bright future ahead of it and as someone who has been there from the very beginning I look forward to the day we get there and the majority of customers are using a storage model that is better aligned with today’s much different use cases than when VMFS first launched over 20 years ago.
I would put difficulties between Oracle and VMware as #1 reason we will never consider VVOLs.
A lack of agreement with VMware and Oracle on Oracle’s so called “soft partitioning” contention requires VMFS and eliminates any move to VVOL otherwise Oracle envisions Oracle licensing is required on all ESXI hosts across all vCenter Enterprise servers.
For Oracle, we will never move off of VMFS for a number of reasons (willing to review offline).
Due to Oracle, it is one reason we must never leave vCenter Standard as well as use underlying Storage SAN’s Host Assignments for LUNs to isolate which ESXI hosts can see them.
So we have a group of LUNs for Oracle OLTP / Standard Edition licensed binaries going to one vCenter Standard server and the SAN only allows the two hosts in that vCenter to see it.
Then we have a group of different LUNs for Oracle Data Warehouse / Enterprise Edition licensed binaries going to a different vCenter Standard Server and again, the SAN has all the DW LUNs only appear on a different pair of DW ESXi hosts in a separate vCenter server.
I forwarded this on to VMware’s vVols PM. Here’s the response from Sudhir who wrote the below blog posts, if you would like I could arrange a call with VMware to discuss it.
Oracle licensing on any platform has nothing to do with VMFS, rdm, vvol, iscsi, nfs or any other storage protocols or storage platform , its purely compute…Thanks to Oracle and their nonsense that they spread, this is the FUD we have to deal with….
Oracle on VMware Hybrid Multi-Clouds – Dispelling the Licensing myths
Oracle on VMware Hybrid Multi-Clouds – Preparing for an the Oracle Audit
Oracle on VMware Hybrid Multi-Clouds – Asks the Oracles
Being a Enterprise Storage Support Engineer/Design Architect and Vmware certified since 2.x…
You can design an environment anticipating all failure scenarios and building in resiliency to your design. Or you can build it assuming that everything is always going to work.
The sheer number of failure scenarios possible for a non hardware/bit related issue is considerably more with VVols. The available resources with expertise to fix VVol issues from a Vmware support side is almost non existent. I have seen Vmware destroy more data than recover it when dealing with VVols. Bizarre issues with protocol endpoints that we had to direct Vmware to that they weren’t aware of, arent documented except for literally 1 google hit.
Vvols are the devil. Anyone that tells you different…. is either selling you something or hasnt had a failure yet.