The ability to do array based replication of VVols via SPBM was introduced in vSphere 6.5 but it came with a catch. That catch is while you can automate VVol replication with SPBM, there is no client side interface to perform any type of failover or failback operations like you have with SRM. To do those types of operations you have to manually script those actions using PowerCLI.
Back in November I wrote about the new PowerCLI cmdlets that support VVol replication operations, this provides a way to manage VVol replication until VMware provides a more elegant solution using vRealize Orchestrator/Automation or SRM. While the PowerCLI cmdlets provided the means to do all the basic operations that you might have to do with replication it was missing a very important function that is a must have for most, the ability to perform a test failover.
That missing function to do a test failover is now part of the recently released new version of PowerCLI (6.5.1 R2). So if you’re lucky enough to have a array that supports VVol replication, you should have everything you need now to use it effectively. With the recent HPE acquisition of Nimble Storage there really is only one vendor that supports VVol replication at the moment as 3PAR & Nimble are the only ones listed in the VVol HCL for array based replication.
The new PowerCLI cmdlets to support VVol replication only are listed below:
- Start-SpbmReplicationPromote – This cmdlet promotes a target replication group from InTest to FailedOver state.
- Start-SpbmReplicationTestFailover – This cmdlet performs a test failover of a target replication group. If the operation succeeds, the replication state of the replication group becomes InTest.
- Stop-SpbmReplicationTestFailover – This cmdlet stops the test failover on the specified replication groups and tries to perform a cleanup on the target site. After successful completion the replication group state returns to Target.
So what actually happens when you do a VVol test failover? When VVols are replicated to another array, they remain hidden to vSphere on the target array. All the VVols of a VM (except the swap VVol) must be replicated to the target array this includes the config VVol, data VVols (disk and snapshots) and other metadata. When you perform a test failover you are not doing an actual failover, replication continues and the primary site VVols and secondary site VVols are not impacted.
What happens when a test failover is initiated at the target site using the Start-SpbmReplicationTestFailover command is that virtual copies of the replicated VVols on the target array are created and vSphere performs a fix-up on them so they are in a usable state.The fix-up operation updates the VM config to reflect the new VVol IDs and storage container information. Those newly created copies are then exposed to vSphere so you can interact with them, power up VMs and test them to make sure the VMs are recoverable.
Once you are finished you run the Stop-SpbmReplicationTestFailover command which will tell the VASA Provider to stop the test and clean up all the VVols that were created as part of the test. The Start-SpbmReplicationPromote can also be used if for some reason you want to make the test permanent and have the VM’s at the target site be actually failed over and not just a test.
Now that the ability to perform a test failover is part of PowerCLI, VVol replication is much more usable as who would want to replicate data to another array and just hope things work without being able to actually verify it. I expect the support around these operations will continue to mature in vSphere and I wouldn’t be surprised if VMware added VVol replication support to SRM or vRealize Orchestrator/Automation at some point. You can read more about how to use these new PowerCLI cmdlets in the VMware documentation and look for a detailed white paper on using VVol replication coming from HPE very soon.
