- Pods protected by SRM cannot be renamed. ActiveDR pods can be renamed. Pods in use with ActiveCluster to third site cannot be renamed.
- Virtual volumes are not supported in a pod protected by SRM.
- Failback or reprotect from an asynchronous target into a stretched pod is not supported. Pods much be first unstretched before a failback from an asynchronous distance target.
- Volume names must be less than 42 characters in length except for ActiveDR volumes--these can be up to full supported length of the FlashArray
- Non-VMware volumes cannot be in an ActiveDR pod controlled by SRM. All volumes in the pod must be present and in use as an RDM or VMFS in the VMware environment connected to the SRM pair.
- New volumes cannot be provisioned into a target pod during the test state, nor during the promoted "target"-side pod after a failover and before a reprotect.
- Verbose logging can fill up SRM data volumes. This is being investigated with VMware but will also be patched from the SRA side in an upcoming release. (Fixed in 4.1.0)
- If the ActiveDR replication link is paused, the syncOnce operation will continue indefinitely. This will be fixed in an upcoming release. If Synchronization steps in SRM test recovery, recovery, or reprotection is stalled, ensure the replication link is enabled and if not, enable it.
- If either FlashArray has been renamed after they have been connected, all test failovers, failovers and reprotects will not execute completely. The is due to the array pair naming not getting updated if either array is renamed (if
purearray list --connect is ran from the CLI, the previous names will show). Should an array be renamed, the recommend remediation if using only async replication is to disconnect the FlashArrays and reconnect them. Should ActiveCluster be enabled, the recommended remediation is to run through the
purearray connect process from the array that had the connection initiated from initially.
- If locks remain on virtual machine during a failover (meaning the virtual machines cannot be powered down gracefully) a SRM failover will not complete successfully as the source SRM server is down and cannot shut down the source VMs. Therefore the VM locks will still be held by the source ESXi host(s) and failover will not succeed. This can occur if 1) Source SRM server fails 2) Source vCenter fails 3) Network partition to ESXi hosts from vCenter. If the array fails, the SAN fails, or the compute fails entirely this issue does not occur. To resolve this, you will need to manually shut down the VMs on the source site or, if not possible, manually disconnect the storage on the source site on the source FlashArray from the host/host groups (a future release of the SRA will provide a function to attempt the latter of the two). (Fixed in 4.1.0)
- Best practice and recommendation from Everpure is to place volumes in protection groups for use with SRM protection groups and recovery plans. Using Hosts or Host Groups as placement for volumes to be protected by SRM has inconsistent behavior and support for this would be best effort. Everpure is working to improve these workflows for a future release of the SRA when using host or host groups, but at this time Everpure would recommend to avoid using Host or Host Group placement for FlashArray protection groups.