A test recovery is a slightly different concept with the SRM stretched storage feature, as the workflow from a migration/storage operation is not quite the same.
A recovery (more on this in a bit) is either:
- Cross vCenter vMotion
- Register and Power-on of VMs on target vCenter
In both cases there is no copy of the datastore-the VMs are recovered on the exact datastores they are on in the source vCenter. This makes it impossible to really test the entire work flow. Instead, the SRM test recovery is focused on VM recovery order, reconfiguration, placement, connectivity, relationships, and of course any scripts/customizations you might have in the recovery plan.
If you plan on leverage the Cross vCenter vMotion feature, you should attempt this process manually with a VM configured like the protected VM (stretched volume) as described in the next section as well as the official SRM test recovery process.
At this time, cross vCenter vMotion is not supported with RDMs in SRM 8.5.
Testing Cross vCenter vMotion
For specific requirements for this feature, refer to the following VMware KB.
Right-click on a test VM and choose Migrate.
|
|
Choose "Change compute resource only" and click Next.
|
|
Then choose a destination host or cluster.
|
|
It is important to pay attention to the Compatibility box. If there is a prerequisite missing it will be listed there. If there are no errors or warning, click Next. If there are warnings, check the VMware KB linked above for requirements. Common reasons are no vMotion vmkernel port on the target hosts, incorrect network names, incompatible CPUs, or a VM resource that is not present in the target site.
Complete the wizard and verify a successful vMotion.
|
|
Lastly, verify the networking is correct for the target VM. Perform the vMotion in the opposite direction to confirm backwards compatibility.
If the VM you tested is part of the SRM recover plan, it is important to remember to re-apply the storage policy to it when you vMotion it back. The vMotion process does not preserve the policies across vCenters.
|
|
Testing the SRM Recovery Plan
To test the recovery plan, click Test on the plan in SRM.
|
|
Unlike with active/passive storage the "Replicate recent changes to the recovery site" does not have any effect with stretched storage as the data is always in sync. Though if this recovery plan has SRM protection groups in it that do include datastores protected via asynchronous replication, it is applicable. For a purely stretched recovery plan though, it does not need to be selected (though it does no harm being enabled).
|
|
The test recovery process will create a copy of all of the volumes in the recovery plan with a prefix of the pod name and a suffix of "-puresra-testFailover".
|
|
The datastores will be mounted and resignatured with the prefix of "snap-XXXXXXXX-" in the name. This can be automatically in the SRM advanced settings discussed here SRM User Guide: Site Recovery Manager Advanced Options.
|
|
Verify the recovery plan result.
|
|
When done, click Cleanup in SRM.
|
|
The VMs and corresponding datastores will be removed and the volumes will be destroyed and eradicated on the FlashArray.
|
|