In 2015, VMware introduced a groundbreaking concept called vVols (Virtual Volumes), A bold reimagining of how storage should work in virtualized environments.
On paper, it was everything infrastructure teams had dreamed of: a move away from cumbersome LUNs and datastores toward a per-VM, policy-driven storage model that offered granular control, array-native snapshots, automated provisioning, replication, and even QoS enforcement, all tied directly to individual virtual machines. A truly elegant architecture.
But as every seasoned product leader knows, even the most visionary design can fall flat without ecosystem readiness and most critically, timing.
🚀 Vision Ahead of Its Time
VMware vVols aimed to abstract storage operations from the underlying physical infrastructure in a way that gave unprecedented control to the virtualization layer.
The key value proposition?
Treat each VM as a first-class citizen in storage, with its own policy, lifecycle, and native services without the need to carve out monolithic LUNs or worry about file systems like VMFS.
It was software defined storage in its purest form, tightly integrated with the vSphere API for Storage Awareness (VASA). In theory, it enabled infrastructure teams to build smarter, more automated, more resilient storage environments.
For anyone who’s lived through the operational tedium of managing massive datastores, the promise of vVols was seductive.
🔍 But Then Reality Hit
Despite the initial fanfare, real world adoption lagged, and serious challenges emerged as customers attempted to implement vVols at scale.
Here’s where the rubber met the road:
🚫 Object Limits
Storage arrays, especially early on, placed strict caps on the number of vVols supported. Each VM could consume 3–5 vVols (or more with snapshots), and arrays that maxed out at 20,000 objects simply couldn’t scale for large environments.
That number disappears quickly in any enterprise with hundreds or thousands of VMs.
⛔ Snapshot Constraints
While vVols supported array-native snapshots, many implementations had surprisingly low limits per VM. This became a major roadblock for backup vendors and DR workflows that relied on frequent or multi-level snapshotting.
🧵 Protocol Endpoint Bottlenecks
All traffic to vVols flows through what’s called a Protocol Endpoint (PE) and these often became contention points in environments with high IOPS or large VM densities. Vendors had to implement workarounds to improve performance, but those arrived late.
🧩 Operational Friction
Tasks like certificate rotation or volume expansion sometimes required downtime in vVol-based environments, A nonstarter in mission-critical data centers.
Storage vendors didn’t uniformly embrace the vVol spec, leading to wildly inconsistent behavior and management complexity across arrays.
⏳ Too Little, Too Late
By the time many of these limitations were addressed through firmware updates, better VASA support, and broader ecosystem alignment… the infrastructure world had already changed.
Kubernetes was rising.
While vVols was working to gain traction in the virtualization ecosystem, a more profound and disruptive shift was taking place across the infrastructure landscape: the rise of Kubernetes.
Kubernetes didn’t just change how we deploy applications, It fundamentally redefined how infrastructure is provisioned, consumed, and abstracted.
At the core of this shift was a philosophical divergence from vVols:
vVols was tightly coupled to the VM-centric world of vSphere. Kubernetes brought in a container first mindset, where storage is ephemeral by default and persistent volumes are dynamically provisioned via CSI (Container Storage Interface).
This introduced a completely different developer led consumption model: storage is no longer provisioned by IT administrators via GUIs or LUN assignments, it’s declared as code. Infrastructure became programmable, dynamic, and abstracted.
More importantly:
Kubernetes decoupled storage from the hypervisor entirely. DevOps teams began treating infrastructure as cattle, not pets. CI/CD pipelines took priority over legacy vCenter workflows.
For vVols, this meant irrelevance by design. It wasn’t just about timing anymore , It was a mismatch of models.
While vVols required deep integration with traditional storage vendors through VASA providers, Kubernetes created an open, extensible plugin architecture via CSI that allowed cloud-native storage providers to flourish.
The momentum was unstoppable:
Developers stopped asking for “per-VM policies” and started asking for persistent volume claims. Storage vendors shifted R&D efforts to Kubernetes native integrations. Enterprises prioritized agility over deep, VM centric control.
In a world that now runs on YAML and GitOps, vVols’ elegant design simply didn’t fit the bill.
The cloud-native paradigm, based on containers, CSI, and S3-style object storage made the core premise of vVols feel increasingly dated.
What was once revolutionary now seemed like a solution looking for a problem, especially as newer platforms abstracted storage in entirely different ways.
📉 Broadcom Puts the Final Nail in the Coffin
In June 2025, Broadcom officially announced that vVols will not be supported in upcoming versions of vSphere+ and Cloud Foundation+. While support will remain in legacy 8.x versions, this effectively signals the end of the road for vVols as a strategic part of VMware’s storage vision.
A quiet exit for what was once one of VMware’s most forward-thinking features.
🎓 Product Strategy Takeaways
So what can product managers, founders, and infrastructure architects learn from this?
1. Elegant Design ≠ Market Success
vVols was brilliantly engineered, but elegance isn’t enough. Scale, reliability, ecosystem integration, and operational simplicity ultimately determine enterprise adoption.
2. Timing Is Everything
vVols wasn’t just early, it was too early. By the time vendors and VMware ironed out the limitations, the world had moved on. In the MVP lifecycle, timing often trumps technology.
3. You Can’t Out-Engineer Market Shifts
Even if vVols had worked flawlessly, the platform migration to Kubernetes and cloud-native paradigms made it less relevant. Products live within ecosystems and when ecosystems shift, products must adapt or become obsolete.
4. Ecosystem Buy-In Is Make or Break
Storage vendors, backup vendors, and infrastructure teams need to pull in the same direction. Without clear alignment across the ecosystem, even the most promising innovations stall.
5. MVP Must Deliver Immediate, Urgent Value
The early vVols MVP was more promise than payoff. It demanded a lot of heavy lifting (and risk) from users without delivering dramatic, immediate wins.
🧠 Bottom Line
vVols will go down as a classic example of how great technology can fail if the ecosystem isn’t ready and the value proposition doesn’t land fast enough.
Sometimes, being too early is worse than being too late.
Sometimes, engineering is the easy part.
Sometimes, the hardest problem is timing.
RIP vVols, A beautifully engineered idea that just didn’t align with the rhythms of the infrastructure market.
MVP too early, ecosystem too late. ⏰