Data ONTAP Discussions

Paired array name mismatch using SRA 2 and SRM 5

Hello, I am using VMware SRM 5 and SRA 2.0 in conjunction with 3 FAS2040 filers running ONTAP 8.0.1-7. 2 filers in a primary dc, 1 in a dr dc. I am trying to pair the arrays but I keep getting the VMware error below each time I click on the Enable action.


image 1.png


The DR Site has 2 remote arrays entries while each of the primary filers have 1 entry each but I don't have the option to enable (it's grayed out) from the primary filers.


One of the primary arrays:


image 2.png



image 3.png


The problem is that the DR array wants to connect to a different name (FQDN) while the primary arrays are only recognized as HOSTNAME. Below is an excerpt from the SRM log file:


2011-12-28T14:55:36.627-05:00 [05624 verbose 'PropertyProvider' ctxID=7ea28e87 opID=34BFBF3D-00000193] RecordOp REMOVE: taskInProgress[""], storage-arraymanager-13192

2011-12-28T14:55:36.627-05:00 [05624 info 'DrTask' ctxID=7ea28e87 opID=34BFBF3D-00000193] Task '' failed with error: ( {

-->    dynamicType = <unset>,

-->    faultCause = (vmodl.MethodFault) null,

-->    id = "'HOSTNAME1A.FQDN.local",

-->    siteUuid = "aab9fd9f-ead3-45d6-9f42-a90ef02c5120",

-->    siteName = "Site Recovery for MIA",

-->    msg = "Array 'HOSTNAME1A.FQDN.local' not found at site 'Site Recovery for MIA'.",


I have tried to find the location the DR array is grabbing those names from but I have been unsuccessful so far. It's not domain DNS and it's not local host file DNS (from either vcenter or the filers)


Has anyone seen this error before?


Re: Paired array name mismatch using SRA 2 and SRM 5

The problem was/is with Operations Manager / OnCommand Core and how it creates the relationships for SnapMirror. If I create the SnapMirror manually through the Filer the problem goes away and each Filer sees the other as HOSTNAME:/VOL - I still have a ticket opened with NetApp for OnCommand but the pairing of the arrays in SRM is now working.

Re: Paired array name mismatch using SRA 2 and SRM 5

Hi cserpadss,

I am configuring this for a customer and ran into the same problem.  Snapmirrored volumes using OnCommand and can't add arrays in SRM.  Has NetApp ever responded to your issue with an alternate fix? Or is my best bet to remove the OnCommand snapmirror relationships and redo them via command line or system manager?

Re: Paired array name mismatch using SRA 2 and SRM 5

Create the Snapmirror relationship via OnCommand but edit the snapmirror.conf manually.

In my case when the snapmirror relationship was created it would create the SRC filer name as HOSTNAME.DOMAIN:/VOL/ on the DST filer. I manually made it HOSTNAME:/VOL and then replication worked with the names in the snapmirror.conf file I re-added the Filers in SRM.

Example snapmirror snippet:




Re: Paired array name mismatch using SRA 2 and SRM 5

This issue is caused because there is a mismatch between the way the snapmirror relationship is defined at the destination (in the case above by a connection name or by FQDN used as source name) versus the way the snapmirror relationship appears at the source controller, where source name shows simply as short hostname in snapmirror status output.

In the admin guide for the NetApp SRA 2.0 there is a SRA configuration file feature described for use when you have a snapmirror relationship defined on the destination by IP address of the source, rather than by hostname of the source.  Using an IP address as source name also causes the mismatch. The feature, which is use of the ip_hostname_mapping.txt file in the SRA directory, is a way to tell the SRA about this mismatch so it can still detect the relationship.

The ip_hostname_mapping.txt file can also be used to resolve the mismatch between FQDN name and source name.

Please review the admin guide for details if you want to use this method, but the basic difference is this:

The admin guide gives an example where each filer hostname is aligned with an IP address that is used in the replication relationship:

hostA =

hostB =

Where hostA and hostB wold be changed to your source and destination controller host names.

To use the feature for FQDN name you would put this:

hostA = <hostA FQDN>

hostB = <hostB FQDN>

Where <hostA FQDN> is the FQDN of that controller.

You should just put the same entries in the ip_hostname_mapping.txt file on both SRM servers, as the entries will be needed later if you reverse replication and failback anyways.  Please review this in the admin guide, as there is also a config file option you have to turn on to enable the use of the ip_hostname_mapping.txt file.


BTW, I'm working on getting the documentation updated to mention this.

EDIT:  adding some more information for clarity, this is the FQDN use case reproduced in my lab:

Snapmirror relationships viewed on destination array (note source shows as FQDN of hostname.netapp.local):

vmcoe-fas2020-01> snapmirror status

Snapmirror is on.

Source                                Destination              State          Lag        Status

vmcoe-fas3070-01.netapp.local:nfs01   vmcoe-fas2020-01:nfs01   Snapmirrored   00:07:41   Idle

vmcoe-fas3070-01.netapp.local:nfs02   vmcoe-fas2020-01:nfs02   Snapmirrored   06:32:26   Idle

vmcoe-fas3070-01.netapp.local:nfs03   vmcoe-fas2020-01:nfs03   Snapmirrored   6052:02:50  Idle

vmcoe-fas3070-01.netapp.local:nfs04   vmcoe-fas2020-01:nfs04   Snapmirrored   6052:02:48  Idle

vmcoe-fas3070-01.netapp.local:vmfs01  vmcoe-fas2020-01:vmfs01  Snapmirrored   00:04:39   Idle

vmcoe-fas3070-01.netapp.local:vmfs02  vmcoe-fas2020-01:vmfs02  Snapmirrored   168:52:29  Idle

destination array /etc/snapmirror.conf file:

vmcoe-fas3070-01.netapp.local:nfs01 vmcoe-fas2020-01:nfs01 - 0 22 * *

vmcoe-fas3070-01.netapp.local:nfs02 vmcoe-fas2020-01:nfs02 - 0 22 * *

vmcoe-fas3070-01.netapp.local:vmfs01     vmcoe-fas2020-01:vmfs01 - - - - -

vmcoe-fas3070-01.netapp.local:vmfs02     vmcoe-fas2020-01:vmfs02 - - - - -

vmcoe-fas3070-01.netapp.local:nfs03     vmcoe-fas2020-01:nfs03 - - - - -

vmcoe-fas3070-01.netapp.local:nfs04     vmcoe-fas2020-01:nfs04 - - - - -

Snapmirror relationships viewed on source array (note source does not show as FQDN, because it's local system here and simply shows hostname, relationship will always show just hostname when viewed at source):

vmcoe-fas3070-01> snapmirror status

Snapmirror is on.

Source                               Destination              State          Lag        Status

vmcoe-fas3070-01:nfs01               vmcoe-fas2020-01:nfs01   Source         00:09:02   Idle

vmcoe-fas3070-01:nfs02               vmcoe-fas2020-01:nfs02   Source         06:33:47   Idle

vmcoe-fas3070-01:nfs03               vmcoe-fas2020-01:nfs03   Source         6052:04:11  Idle

vmcoe-fas3070-01:nfs04               vmcoe-fas2020-01:nfs04   Source         6052:04:09  Idle

vmcoe-fas3070-01:vmfs01              vmcoe-fas2020-01:vmfs01  Source         00:06:00   Idle

vmcoe-fas3070-01:vmfs02              vmcoe-fas2020-01:vmfs02  Source         168:53:50  Idle

source /etc/snapmirror.conf:

Mine is empty because I have no relationships currently replicating to this array.

Source array /etc/snapmirror.conf should not have entries yet for reverse direction of above relationships, if there are any bad entries there get rid of them.

Only other relationships, currently replicating in direction to this array, should be listed.

ip_hostname_mapping.txt file at both sites contains this:

vmcoe-fas3070-01 = vmcoe-fas3070-01.netapp.local

vmcoe-fas2020-01 = vmcoe-fas2020-01.netapp.local

(EDIT by Larry on Feb 18,2012: You have to put both the controllers in the above list, even if you are not currently replicating in the other direction.  Without both of them in there storage discovery will still have issues.  The other controller will be needed there for the SRM reprotect workflow when replication is reversed.)

ontap_config.txt has this option set on at both sites:

use_ip_for_snapmirror_relation = on

the use_ip_for_snapmirror_relation option and the entries in ip_hostname_mapping.txt file, are global options, they apply for all relationships between these to arrays (vmware used relationships).  So you cannot have some relationship between these two arrays defined by short hostname, some by FQDN, some by IP.  All SRM managed snapmirror relationships between these two arrays must be defined the same way, not a mix.

After any changes you have to refresh the adapters to re-run storage discovery, by clicking refresh in the array manager devices tab.

Screenshot of devices discovered above.  Note that I have nfs03 and nfs04 datastores on the netapp controller, and replicated, but they are not in use by my ESX hosts, they show up in discovery anyway, hence nothing in Datastore column for those. If you don't want these in there they you have to use the volume include/exclude fields on the edit array manager screen to exclude them.

Message was edited by: Larry Touchette

Message was edited by: Larry Touchette - added note under ip_hostname_mappin.txt example

Re: Paired array name mismatch using SRA 2 and SRM 5

Hello Larry,

I'm having a different issue with SRM 5/SRA2.  In SRM 5 Array Managers, the array pairs are detected and enabled just fine but I'm getting the following errors for some reason.

Device '/vol/NFS_datastore_name' cannot be matched to a remote peer device.

Device '/vol/NFS_datastore_name/qtree' cannot be matched to a remote peer device.

Our naming convention is that the NFS datastore is called "nfs_datastore1" in the protected site but it's named "nfs_datastore1_mirror" in the DR site (snapmirror works fine).  Does this create pairing issues in SRM 5?



Re: Paired array name mismatch using SRA 2 and SRM 5

That error means that those volumes aren't mounted as datastores. When adding a filer in SRM you can choose to either select what volumes to pair or what volumes to omit from the volume search.


Carlos Serpa

Systems Engineer

DSS, Inc.

This email was sent from a handheld device, please excuse any typographical errors.

Re: Paired array name mismatch using SRA 2 and SRM 5

Thanks for your quick reply, Carlos.  Actually the NFS datastore in question is indeed mounted on 2 of 4 ESX hosts in the protected site and there are VMs currently running off that datastore.  Do you have any other ideas?



Re: Paired array name mismatch using SRA 2 and SRM 5

Hello Michael,

Are you using qtrees as datastores or volumes as datastores?

Do you have the whole volume exported or each qtree exported?

If you are using qtrees, then you have to have an /etc/exports line for each qtree separately.

You can use one volume snapmirror relationship to replicate a volume that has multiple qtrees, but with SRM when using qtrees it's best to have a qtree snapmirror relationship for each qtree.

Since you say the SRA is reporting /vol/volume_name and /vol/volume_name/qtree then I think this means you are using qtrees as different datastores, but you are having an export only for the volume.


Re: Paired array name mismatch using SRA 2 and SRM 5

Thanks for your quick reply, Larry.  This is how our current NFS datastores setup look like on ESX hosts in the protected site (this was initially done for us by a third-party vendor when we purchased NetApp filers).  We'd first create a NFS volume called "nfs_datastore1" on the filer, and then create a qtree (say qt1) for this volume.  On each ESX host, we would mount the NFS datastore as:


and all VMs are saved to the qt1 folder.  On the storage filer in DR site, we would create the NFS volume as "nfs_datastore1_mirror" and setup SnapMirror relationship to replicate this whole volume (not qtree) from protected site to DR site.

On the storage filer in the protected site, I have setup the NFS exports as follows:

/vol/nfs_datastore1 -sec=sys,rw=x.x.x.0 (NFS IP subnet)/24,root=x.x.x.0/24

So in our case, do I have to setup NFS exports for the single qtree in each of our NFS datastores for SRM 5?  Your help on this is greatly appreciated.