Unique Features with vVols and SRM

When SRM 8.3 added support for vVols it did a few things.

Show the commitment to vVols, by continuing to add ecosystem support.
Enable unique features for SRM not available with traditional storage.
Remove the requirement for an SRA when using array-based replication.

No need for an SRA.

When you use traditional, array-based, replication (LUN of Volume level) SRM requires the use of an SRA (Storage Replication Adapter). The SRA, which is vendor-specific, communicates between the array and vSphere for SRM specific API calls used for array-based replication.

With vVols, array-based replication is built into the VASA Provider and managed using Storage Policy Based Management or SPBM. Subsequently, once you have defined an SPBM replication policy, array-based replication is used for a VM where that policy has been applied and is called a vVols Replication Group. Because vVols already has and manages arra-based replication, there's no need for an SRA.

Automatic VM Protection

Once you have defined an SPBM Replication policy and set up an array replication partner, you can begin protecting VMs. When you apply the replication policy to a VM that resides in a supported vVols datastore, that VM will then be replicated to a partner array. To add the replicated VMs to an SRM protection group, you only need to associate SRM with the vVols Replication Group (SPBM Replication Policy) you defined. Once you associate the SRM with the replication policy, the VMs are automatically protected by SRM, no need to migrate to a specific replicated datastore. Another benefit with this process is any VM associated with the vVols Replication group/SRM Protection Group will automatically be protected by SRM with no further action required.

VM Granular Replication, Failover, and Failover testing.

Being able to do a single VM, application, or small group of VMs' failover or testing is unique to vVols and SRM. Typically, with SRM and traditional array-based replication, failover is at a datastore level, and all VMs inside that datastore. Subsequently, if you want to do a test or failover of a single VM, you would have to have a datastore for a single VM. Obviously, that's not an efficient use of resources. But, because vVols replication is managed at a VM granularity it's possible. If a single VM is associated with Replication Group/Protection group, you can do failover or testing of that single VM! This allows you to have different RPOs for different VM or applications across multiple VMs. You no longer have to get buy-in from all affected VM owners to do a failover or testing for one owner's VMs.

vVols Replication is One to Many arrays.

Don't forget that with vVols replication, it isn't a one-to-one replication, it is a one-to-many. You can set up multiple vVols partner arrays with a single source array, all using array-based replication and managed via SPBM policies. This allows you to set up not only different RPO policies for different VMs but also different destinations!

Lightbaord videos on vVols and SRM

Conclusion

As you can see, the unique features available with SRM and vVols can greatly enhance your DR capabilities and control. If you have an array that supports vVols and vSphere 6 or above, you can add vVols to your environment and test some of these features.

@jbmassae