SRM 5.0.1/SRA 2.0 error

[HUX20002000]

In VMware SRM 5.0.1 with NetApp FAS/V-Series SRA 2.0, when I enable my array pair, the volumes I want are correctly listed but I also get the error, "Device '[/path/to/NFS_volume]' cannot be matched to a remote peer device". This refers to a volume that I do NOT want in SRM (i.e. when the SRA scans the filer it's finding this replicated pair in addition to the ones that I do want to use in SRM.) I want to get rid of that error since it's purely cosmetic and doesn't actually affect SRM's operation.

To resolve this, I edited the array manager settings and entered a string in the "Volume exclude list" field that is part of the offending volume's path, then refreshed, but the error still appeared. Next I tried disabling/enabling the array pair, but that didn't clear the error either. Finally, I removed the array manager entries completely and started from scratch, again entering the relevant string in the exclude list, but it still finds that volume and still throws the error.

So, what can I do here? As far as I can tell, that "Volume exclude list" field doesn't seem to actually do anything. Is that right?

[HUX20002000 · Accepted solution]

Fixed it! It turns out that the "Volume exclude list" field doesn't match just any string that's present in the path. For example, let's say that the full path to the volume is:

/vol/F3A12V04/EsxVolume_srm

If you enter "Volume" (without the quotes) into that field then the SRA will still find it (and in my case throw the error mentioned above). However, if you enter "F3A12V04" then it excludes the volume as expected.

I don't have time to test this further, but it looks like if your string is the entire text between two forward slashes within the path then it'll work. Or it might just be that the start of your string must be text that appears immediately after a forward slash (so "Esx" might work in this example). It seems likely that the same rules apply to the "Volume include list" field as well.

I'd be interested to know if anyone else has run into this in the past, or if it's a known problem with SRA 2.0.

[MSEBEL1980]

This thread is nearly a year old but I'd like to post a follow-up for any others that stumble upon this. And the following applies to SRA 2.0.1 32bit version that works for SRM 5.0

It appears the Include and Exclude lists work primarily by looking at a string value that matches that string in your volume names and not necessarily only the actual name of the volume. For example, if you add "TEST_VOL" to the exclusion list and you have two volumes named "TEST_VOL" and "TEST_VOL_sm", it will exclude both of those. You may not want it to do that, but my experience shows that that's how it works and you can't use quotes in your text because it won't allow those characters to get around the problem. I've also finally realized that using the Include list, does narrow down the volumes that the SRA looks at but not entirely. Below is an example of my Include and Exclude lists:

Include: NAVM_A_0_SRM_4hr,NAVM_A_0_win2k3

Exclude: NAVM_B_0_win2k8,qtree,rhel5_SnapMirror,sv

Hope this helps anyone else that is uber-confused by this setup. I can say for sure, the 1.4 SRA with SRM 4.x was much simpler!

[MNazri]

Just to add the below;

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.