Any way to eliminate SRM 5.0 / SRA 2.0 error message regarding CIFS share?

[boylerscs]

We recently upgraded to vSphere 5.0 / vCenter 5.0 / SRM 5.0 / NetApp SRA 2.0, and we notice a persistent "Error" message on the Array Managers panel of SRM:

Device '/vol/XXX/YYY' cannot be matched to a remote peer device

This particular volume (/vol/XXX/YYY) is simply our main CIFS file share, which happens to be replicated to the other filer using SnapMirror.  To me, it seems like perhaps the NetApp SRA is getting confused by this non-NFS and non-iSCSI SnapMirror relationship, and therefore producing an erroneous error message inside SRM.  It shows up for both the primary site Array Manager as well as the DR site Array Manager.

Any way to eliminate this erroneous error message from SRM?

[ahitoperations]

Did you get an answer to this? I have the same error but the system seems to work fine.

Andrew

[boylerscs]

No, I have not found a solution to this error message.  But you are correct; it does not appear to negatively affect the functionality of DR testing in SRM.  It's just annoying to see the big read error messages on the filers in the SRM interface.  I am assuming this bug will be fixed in the next SRA release.

[g_fildes1]

Have you tried excluding the CIFs vol in the SRA setup?

[boylerscs]

That is a great idea.  Let me try that and get back to you.

[boylerscs]

I tried editing the Array Managers by excluding the volume containing the CIFS share, and then restarted the SRM services on both sides, and the error persists.  I am wondering if I need to completely delete the array managers and start over.  I probably won't try this because everything is working fine except for the annoying error message, which is just cosmetic at this point.

[ahitoperations]

I have been thinking about this..... in SRM 4.0 if you had a VM with Raw Device Mappings, you needed to make sure that the RDMs were on the same controller as the VM.

We have a FAS3140 and have some RDMs on the different controller to the VM. So I think the error occurs if the volume contains a LUN for RDM to a VM on the different controller. I am not able to confirm this yet, but I am reorganising our storage so will see if this resolves it. Will be a month or two until I have an answer.

Andrew

[PETERG865]

@ahitoperations: Check out TR-3671, Page 12 Figure 8. "Many to one" Snapmirror Replication is unsupported. Sucks. I know. We found out the hard way...

[MNazri]

Just to add the below requirements for NetApp with NFS mounts;

1. The hostname referenced in snapmirror.conf must match the actual hostname. If it does not (as in our case where the hostname is uppercase and in snapmirror.conf its lowercase), then SRA will have a problem discovering the array device.

2. Ensure that snapmirror relationships are not in a transferring state. If there are, transfers need to complete to confirm that SRA is able to pair the devices

3. Remove unneeded export statements for RO snapmirror destinations. Having these export statements may cause issues when attempting a Recovery operation in that the destination hosts may not be able to mount the volume due to the existing export statements. It's best to remove these and to allow SRA to create them during the Recovery operation.