Virtual Volumes (vVols)

Whats New in Virtual Volumes (vVols) 2.0

With the release of vSphere 6.0 back in March 2015, VMware delivered the long anticipated Virtual Volumes feature (a.k.a. vVols). Over the past year and a half the vVols momentum has been quietly building with more and more customer interest and partner activity. The adoption of vVols has steadily increased as more and more customers move to vSphere 6, but one of the key inhibitors to widespread adoption had been its lack of support for array-based replication (ABR). Enter vSphere 6.5.

Announced this week, the release of vSphere 6.5 introduces enhancements to several of VMware’s storage management capabilities, including enhancements to Storage Policy-Based Management (SPBM), Storage IO Control (SIOC), virtual disk management, and of course the highly anticipated 2.0 version of vSphere Virtual Volumes. In this post I will walk through what’s new in vVols 2.0 and VASA 3.0. Any guesses what feature made the top of the list?

Array-Based Replication Support

You guessed it! The vSphere 6.5 release introduces vVols support of array-based replication, but unlike legacy array-based replication that required explicit placement on specific datastores to ensure a VM was replicated, vVols replication provides fine grained control over VM replication. This means you have the flexibility to replicate a group of virtual machines (Replication Group) or you can replicate at an individual VM level.

Replication Group

A Replication Group is a group of replicated storage devices as defined by a storage administrator (perhaps acting on behalf of an application owner) to provide atomic failover for an application. In other words, a Replication Group is the minimum unit of failover. In vSphere 6.5, Replication Groups are created and managed by a storage administrator using the storage vendor’s tools.


Let’s take a closer look at how this works:

  • Vendor-specific replication capabilities are communicated up to vSphere via VASA (vSphere APIs for Storage Awareness)
  • VI administrators create granular VM storage policies containing the desired replication capabilities available from the underlying storage system
  • When VMs are being provisioned the user:
    1. Selects a policy containing the replication capabilities
    2. Chooses the compatible datastore
    3. Chooses a replication group in which to place the VM (to support multi-VM consistency)
    4. Completes the provisioning

The replication group that the user selects allows them to place multiple VMs intentionally in the same consistency group. The replication groups are advertised by the VASA provider. The storage system can also advertise a special “Automatic” replication group that will place the VM into an empty replication group by itself to support per-VM replication.

Virtual Volumes replication also supports multiple replication targets. In the example below, the source in Manchester UK (Repl. Group A) is replicating to London (Repl. Group A1) and Berlin (Repl. Group A2)


Automating Disaster Recovery

vSphere 6.5 also offers public APIs for triggering DR operations as well PowerCLI cmdlets for administrator-level orchestration and automation.

Replication Workflows

  • Replication Discovery – vVols disaster recovery discovers the current replication relationships between two fault domains.
  • Sync Replication Group – Synchronizes the data between source and replica.
  • Disaster Recovery and Planned Migration – For planned migration, on-demand sync can be initiated at the recovery site.
  • Setting up protection after a DR event – After the recovery on a peer site, administrators can set protection in the reverse direction.

Line of Service

VASA 3.0 introduces a new concept called “line of service.” A line of service is a group of related capabilities with a specific purpose, such as inspection, compression, encryption, replication, caching, or persistence (storage). Now in addition to configuring replication at the individual SPBM policy level, I can create a line of service for replication and assign it to multiple policies. As an example, imagine I have 3 storage policies: Gold, Silver and Bronze. While these three categories have very different storage capabilities assigned, I can manage the replication once with a replication line of service instead of 3 times by configuring replication at the VM Storage policy level.

Virtual Volumes Support for Oracle RAC

In addition to all the array-based replication functionality, vVols 2.0 is also now validated to support Oracle RAC workloads (similar to validation for VMFS) delivering policy-based, VM-centric storage for Business Critical Applications like Oracle RAC.

Are you ready?

As I mentioned earlier, the lack of support for array-based replication was a significant inhibitor for mass adoption of vVols. Now with vSphere 6.5, customers can protect their vVols environment with array-based replication while experiencing how vVols can greatly simplify storage management and provide greater granularity over the existing operational model. There’s no need to wait anymore, so get ready for the vVols revolution! 

More resources

For the latest information on vSphere Virtual Volumes be sure to check the following locations

Virtual Blocks

Virtually Speaking Podcast


14 comments have been added so far

  1. Hello Pete,
    This was really long awaited…thank you for spreading good news 🙂
    Hopefully, storage vendor will offer support soon.

    Here, I need to know about the next part at DR site. What about SRM support? (for VMs recovery at DR site)


  2. Thanks Aadi,

    Excellent question. As you know Virtual Volumes in 6.5 now offers support for all DR workflows (discovery, sync, test, test cleanup, failover failback) with public API and PowerCLI cmdlets. This will meet the DR needs of our larger customers who prefer custom automation for their DR needs. The good news is SRM is now offering support for VVols for customers using vSphere Replication. SRM support for VVol array-based replication is a popular request that we hear and hopefully soon we will be able to share more publicly, but for today I will just say…. watch that space. 🙂

  3. Hi Pete,

    This is fantastic news, thanks for sharing it with us.

    Looking at the release notes it seems that VVOL interoperability with SRM and VROPS have been addressed in this release and I applaud this effort.

    Citing from, VVOL 1.0 is not interoperable with the following features and products:
    Fault Tolerance (FT)
    Microsoft Failover Clustering
    NFS version 4.1
    Raw Device Mapping (RDM)
    Storage Distributed Resource Scheduler (SDRS)
    Storage I/O Control

    VMware vSphere 6.0.x
    VMware vRealize Automation 6.2.x (formerly known as VMware vCloud Automation Center)
    VMware Horizon 6.1.x
    VMware vSphere Replication 6.0.x

    I was wondering which other of above incompatibilities have been addressed in this release?
    Are there any new incompatibilities being introduced with VVOL 2.0 and vSphere 6.5?


  4. Hi Daniel,
    Regarding your question “Are there any new incompatibilities being introduced with VVOL 2.0 and vSphere 6.5?” I would answer that VVols in vSphere 6.5 is backwards compatible with VVols in 6.0, therefore everything that worked with vSphere 6.0’s VVols should continue to function with vSphere 6.5’s version of VVols.

    In your comment you list a few items as incompatible that are in fact compatible, namely:
    – VMware vSphere 6.0.x
    – VMware vRealize Automation 6.2.x (formerly known as VMware vCloud – Automation Center)
    – VMware Horizon 6.1.x
    – VMware vSphere Replication 6.0.x

    When vSphere 6.5 and, other VMware products, are released then details of interoperability will be updated.

    I would also note that some of the items listed, like SDRS for example have less applicability with VVols, see for more details.


  5. Is VSAN or vsphere replication going to support vvol 2.0 replication public APIs? in same way you are now offering public apis for people that prefer to build custom DR orchestration for vvol 2.0 we want to do the same with vsphere replication, we need public API to automate vsphere replication instead of having to buy SRM.

  6. in powercli I only see cmdlets for failover, preparefailover and reverse failover. Where is the Test cmdlet?

  7. The first set of PowerCLI cmdlets did not include test. I know this is on the roadmap but no official dates to share just yet. As they say, watch that space. 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *