As of the 4.0 release of the Everpure SRA, volumes not belonging to the VMware environment (meaning in use as a VMFS or RDM) that is controlled by SRM is not supported. In other words, for a given ActiveDR pod, either all of the volumes must be in use as an VMFS or RDM and protected by the same SRM protection group, or none of them. Supporting "non-VMware" volumes is under investigation for a future release of the SRA.
If a volume is added to the source pod prior to a test:
And the 4th volume (in this case) is not in the protection group:
The test recovery will still succeed, but the cleanup will fail. The test recovery will tell the SRA to recover the 3 volumes SRM knows about, and the SRA will tag them:
During the cleanup, the SRA will see a 4th volume which is untagged. The cleanup will fail with the following error:
Failed to delete snapshots of replica devices. SRA command 'testFailoverStop' failed. More than one type of devices found in the pod. Please verify that all the volumes are either untagged or tagged with same value in the "puresra" namespace.
This failure can also occur if someone manually deleted the tags on one of the expected volumes. The SRA will fail in this situation because it does not want to demote the pod when an in-use volume is in it--the demotion process causes all volumes to go NOT READY, meaning they will not be able to be written to or read from. If some environment is using that 4th volume, it will lose access. In this situation, manual intervention is required.
The options are:
- Delete the non-VMware volume
- Terminate the pod replica link, move the volume out of the pod, and then relink the pods (note this will cause replication to stop for the duration of the process!).
You may either do this, then re-run test recovery cleanup or run test recovery cleanup with the force cleanup option selected to have the SRA skip the demotion step. The force option will require manual intervention to demote the pod.