tiero - Fotolia
What is a good replacement for VMware vVols?
The deprecation of VMware Virtual Volumes leaves a hole for some storage users. Substitute options include manually provisioning storage and using vSAN.
VMware vVols, or Virtual Volumes, were an attempt by VMware to make storage provisioning more dynamic than it had been in the past. Despite the benefits, though, Broadcom is discontinuing its support for vVols, and users should look elsewhere for similar capabilities.
According to Broadcom, VMware vVols capabilities were deprecated beginning with the release of VMware Cloud Foundation (VCF) version 9.0 and VMware vSphere Foundation (VVF) version 9.0, which launched in 2025. The vendor will fully remove the capabilities in VCF and VVF 9.1.
All vVols certifications for VCF and VVF 9.0 are discontinued, according to Broadcom. However, Broadcom has committed to continuing to provide critical bug fixes for vSphere 8.x, VCF and VVF 5.x, and other older supported versions until the end-of-support date for those products.
Why is Broadcom discontinuing vVols?
Broadcom's removal of vVols likely stems from low adoption. VMware introduced vVols with vSphere 6.0 in 2015. Even though this feature has been around for a full decade at this point, it hasn't been widely adopted.
Some analysts have also speculated that Broadcom may have decided to drop VMware vVols in an effort to drive customers toward adopting vSAN. This would increase licensing revenues and the potential for vendor lock-in since vSAN does not use native SAN features the way that vVols did.
What are good replacement options?
There are three main options available to organizations that seek a replacement for the VMware vVols feature.
The first option is to go back to the basics and manually provision storage within a VMware datastore. However, this option will probably be difficult to accept given that it lacks the benefits and conveniences that admins have been used to with vVols.
The second option is to work around the lack of support for vVols by implementing VM-level iSCSI platforms. This approach can theoretically replace any capabilities that might have been lost with the discontinuance of vVols, but it can be difficult to implement and it lacks any sort of native VMware integration.
The third option is to adopt VMware's vSAN as an alternative to vVols. This is VMware's preferred migration path. VMware vSAN delivers features that go well beyond those of a traditional datastore approach. Support will be better for vSAN storage than for custom, VM-level iSCSI.
Why is that kind of storage important?
Instead of multiple VMs sharing a common storage container, each one had its own virtual volume. Rather than carving up LUNs or data stores, admins would just tell VMware what level of performance the VM needed and storage would automatically allocate based on that need. This also enabled policy-based automation, giving admins the ability to perform tasks such as creating hourly snapshots. In addition, users could enable native support of storage array features with vVols rather than have VMware attempt to emulate those features.
Given the low adoption rate for VMware vVols, Broadcom's decision to remove the feature probably won’t have an impact on most customers. Even those organizations that do use vVols probably don’t use the feature across the entire enterprise. Even so, those organizations that do use vVols stand to lose granular controls and policy-based automation. As such, it is important to begin looking for a vVols replacement and a migration path.
Brien Posey is a former 22-time Microsoft MVP and a commercial astronaut candidate. In his more than 30 years in IT, he has served as a lead network engineer for the U.S. Department of Defense and a network administrator for some of the largest insurance companies in America.
