Thanks for this Lee. I have checked and double checked the configuration as I had before and had read NetApp TR-4064. I still cannot see what the issue is.
All of the SnapMirror relationships are using the host name for the source and destination Filers, no IP addresses used in snapmirror relationships, no FQDN and no connection names used.
No qtrees.
SnapMirror relationships have been created with Ops Manager 2.0R1 but they look good as does snapmirror.conf
Original Volume created with Virtual Storage Console with autodelete NOT enabled.
I raised a SR with VMware (13345880607) who identified the issue to be with the SRA and recommended raising a SR with IBM. I can now see that the error is coming from the SRA so I guess it is down to IBM to help me fix it.
This is what I have discovered, when the SRA runs the reverseReplication.pl script with the command prepareReverseReplication it is not detecting the broken-off snapmirror as I am seeing the following error in the SRM logs
validating if path NFS_VMware_Test is valid mirrored device for given peerArrayId
curr state = invalid, prev state = ,source name:DRNSERIES02:NFS_VMware_Test, destination:NSERIES02:NFS_VMware_Test, path=NFS_VMware_Test, arrayID:NSERIES02
Skipping /vol/NFS_VMware_Test as peerArrayId DRNSERIES02 is not valid
If I run a snapmirror status on the controller at the site I have just failed over to, i.e. Site-A, I see the snapmirror is broken off and the Source and Destination Filers are listed as the Filer host names and not an IP address, FQDN or Connection Name.
When I do a reprotect after a failover to Site-B I see the following equivalent messages in the SRM logs
validating if path NFS_VMware_Test is valid mirrored device for given peerArrayId
curr state = , prev state = broken-off,source name:NSERIES02:NFS_VMware_Test, destination:DRNSERIES02:NFS_VMware_Test, path=NFS_VMware_Test, arrayID:DRNSERIES02
I'm wondering if it has got something to do with the length of the peerArrayId name, surely at 11 characters this is not the issue.