Effective December 3, NetApp adopts Microsoft’s Business-to-Customer (B2C) identity management to simplify and provide secure access to NetApp resources.
For accounts that did not pre-register (prior to Dec 3), access to your NetApp data may take up to 1 hour as your legacy NSS ID is synchronized to the new B2C identity.
To learn more, read the FAQ and watch the video.
Need assistance? Complete this form and select “Registration Issue” as the Feedback Category.

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["dr.storage.ArrayManager.addArrayPair23"], storage-arraymanager-13192

2011-12-28T14:55:36.627-05:00 [05624 info 'DrTask' ctxID=7ea28e87 opID=34BFBF3D-00000193] Task 'dr.storage.ArrayManager.addArrayPair23' failed with error: (dr.storage.fault.ArrayNotFound) {

-->    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?



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.

View solution in original post



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.

View solution in original post


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?


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:





We are in the process of upgrading from SRM 4.1 to 5.1 and have hit a similar issue.

The connection string in the snapmiror.conf file is of the form filer1_filer2_999999999, if I edit the file manually it will work but DFM (Operations Manager) keeps rewriting the snapmirror.conf file and breaks it again.

I succeeded with one pair of filers but can not get it sorted on another.

I'd like to delete the relationships from DFM ( without destroying the actually relationship so that I can manually fix the files and then let DFM find them again but can't seem to work out how to do this.


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


So is the use of the multi directive supported by the NetApp SRA or not?

I have tried everything, and keep getting

Vcenter also throws this error "Array 'hosm1' nof found at site "vcenter.domain.com"

This is what I have in /etc/snapmirror.conf

Where hosm1 is a connection name and not a hostname.



hosm1:GHoLLIdxVol01 GDrNetApp01:GHoLLIdxVol01 compression=enable 0 0,2,4,6,8,10,12,14,16,18,20,22 * *

hosm1:GHoVSphereCluster01VolU01 GDrNetApp01:GHoVSphereCluster01VolU01 compression=enable 0 0,2,4,6,8,10,12,14,16,18,20,22 * *

hosm1:GHoVSphereCluster01Vol01 GDrNetApp01:GHoVSphereCluster01Vol01 compression=enable 0 0,2,4,6,8,10,12,14,16,18,20,22 * *

hosm1:GHoDoclinks GDrNetApp01:GHoDoclinks compression=enable 0,5,10,15,20,25,30,35,40,45,50,55 * * *

hosm1:Ghodoclinks1 GDrNetApp01:Ghodoclinks1 compression=enable 0,5,10,15,20,25,30,35,40,45,50,55 * * *


mghanawi1, SRM is complaining because the connection name you created "hosm1" is not a real system name that exists on the network and cannot be resolved.  Connection names are used only internally by SnapMirror.  You can make SRM work with connection names by making the connection name to match the host name of the source system. In your case changing all occurances of "hosm1" to "GHoNetApp01" (if GHoNetApp01 is the resolvable name of your array) in your snapmirror.conf file.  Snapmirror will still use the multi connection, and SRM will recognize the name of the array properly.  This is described in this tech report, under section about snapmirror connection names http://media.netapp.com/documents/tr-4064.pdf



We have installed VMware SRM 5.1 and NetApp SRA2.1. He has two NetApp storage (FAS3210 in Main site and FAS2240 in DR) with snapmirror license on both. Snapmirror is configured well in both site and work fine. After we configured SRM and run a recovery job. It is working well, but when we did reprotect job, it failed and this error message appeared :

Error - Failed to reverse replication for device '/vol/dr_test/lun_test'. SRA command 'prepareReverseReplication' failed for device '/vol/dr_test/lun_test'. Unable to failover the specified device

Ensure that the device is in online state and is mapped or exported properly.

Kindly support us ASAP if the bug in SRA or what.

Thanks in advance


This is a create post, but I'm dealing with this issue in clustered mode.  I have been unsuccesful in finding the etc/exports directory.  I understand that we now use export-policies... but how to I dig in and find the paths that have been exported?


Thanks all



Thanks for pointing out the issue with the connection name in the snapmirror.conf file. This is exactly the situation we were in after our upgrade to SRA 2.0.1 from v1.4 after our vSphere and SRM upgrade this week. Once we were able to find this info in that doc and determine we had an exact situation, we were able to make the adjustments and began to get everything clearly lined up. We were messing with the ip_hostname_mapping file but could not get it to work until we found this post.I'm not sure why this was changed from 1.4 but we had no issues with our setup back on that version and it worked w/o any problems.

Can you also confirm for me that the Include/Exclude list actually looks at the string value and not an actual match of a volume name? For example, if you exclude "TEST_VOL_xx" but have volumes named "TEST_VOLxx" and "TEST_VOL", it will exclude both of those even though you might not want both of those to be excluded? At least that's my experiences. Using quotes do specify the exact vol name does not work as the SRA will not accept those characters.



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?




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.


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?




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.



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.




Having volume names different on source and destination is not a problem.

In the vmware environment the path shown on the datastore is /vol/nfs_datastore1/qt1 correct?

The SRM server inventories the storage and VM's through vcenter and the ESX hosts.  You are having a mismatch in SRM storage discovery because the ESX hosts say they are mounting /vol/nfs_datastore1/qt1.  The SRA reports to SRM what is in the /etc/exports file. When SRM compares what the SRA reports to what vcenter/esx inventory is discovered, it does not find a match because one is reporting /vol/nfs_datastore1/qt1 and the other is reporting /vol/nfs_datastore1.  SRM believes they are different.

Because you have only one qtree in the volume then doing volume snapmirror is just fine.

You will have to change your export line from:


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



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

So that what's in the export file matches what's shown in vcenter as the NFS path.

Just changing the text in the /etc/exports file might be enough to make SRM storage discovery work.  However, if you change the exports file and then make ontap re-read the exports file, for example by using the exportfs -r command, then you will cause the existing mounts to go stale.  Even though the path is the same exportfs -r would unexport the existing path and then export the new path.


You're a genius, Larry!  After modifying the /etc/exports file to include the qtree name, the array pairs succeeded with no more errors.  Thank you very much for your help!  I have two more questions in regards to NFS exports.  Is this how it's supposed to setup in the first place (meaning the NFS exports should match with how the NFS datastores are mounted on the ESX hosts)?  I modified the /etc/exports file using wrfile without using the exportfs -r command, will there be any issues with the existing NFS volumes mounted on the ESX hosts if I need to reboot the NetApp filer later?  Thanks again for all your help on this.




This is really good stuff. This post will help many people in the future I'm sure.

Your filers will read the /etc/exports file upon reboot which is the same thing as doing an exportfs -r. If what's on /etc/exports matches the results of the exportsfs command then you're good to go.

Now I am having a different issue with trying to protect VM's between datacenters but at least the arrays are paired nicely.


Thanks, Carlos.  I ran the exportfs command but it still showed the old NFS export (in our case it's /vol/nfs_datastore1) instead of /vol/nfs_datastore1/qt1.  Will I have problems when I reboot the filers?

After creating the protection groups in SRM, I'm also having a iSCSI RDM LUN issue when trying to protect a VM running SQL, similar to what this guy experienced (https://communities.netapp.com/thread/15537).  The SRM requirement states that any VM with RDM LUNs must reside on the same filer, which is what we have.

In our case two of the five RDM LUNs are showing as non-replicated although they are indeed replicated/SnapMirrored to DR site.  Not sure what's going on here.  If I can't find a resolution to this, I may have to manually attach those RDM LUNs after a failover.




Sorry for the delay, I was in China last week...

To try to answer a couple of your questions Michael: 

Yes the values in the /etc/exports file should match each datastore that is mounted. There are lots of tools that look at whats exported and align that with what ESX shows for the mount path. If you export just the volume, but mount each qtree separately I believe this also causes problems for oncommand and the vsc, here's an example of that:https://communities.netapp.com/message/75022#75022

The exportfs command alone shows what's currently exported in memory.  When your filer reboots the /vol/nfs_datastore1 path will no longer be exported, but each /vol/nfs_datastore1/qtree path will be exported if you have those lines in there now.  However, I'm not 100% sure you will not have a problem if your filer boots.  My vmware lab is not accessible right now to test, but a colleague and I did try something in another lab with linux client NFS mounting a qtree where the volume is what is exported.  While the linux client is copying data into the export, if you change the export path by updating the exports file to add the qtree name to the end of the exports path, then doing exportfs -r (-r means re-read, which unexports anything not in the exports file like exports -u, and then exports everything in the exports file) this made the filer immediately start complaining that the linux client was trying to access a nonexistent export path.  In essence, even though the linux client was mounting /vol/volname/qtree, the export path from the NFS server really was just /vol/volname.  Unexporting the /vol/volname path did affect the client, even though the /vol/volname/qtree path immediately took it's place. And, a filer reboot would be the same as exports -r. I would recommend you remount your datastores.  I think you could do this by vmotioning your vms off of an ESX host, remounting the affected datastores on the host that's not using the datastore anymore using the exact same path that was used before, then vmotion back and repeat on other hosts.  I think this would work, unless vsphere wants to complain thinking these are different datastores now, if it won't let you vmotion back complaining that the target ESX host does not have connection to the correct datastore then that is the case and unfortunately I think you'd have to do a vm shutdown, unregister, remount and reregister.

I'm not sure what to make of your RDM issue.  That is supposed to work.  In the thread you linked to there was one user reporting that his simply detected ok on a later attempt.  If yours is consistently not working I think you'd have to get a case open with netapp about that one.


NetApp on Discord Image

We're on Discord, are you?

Live Chat, Watch Parties, and More!

Explore Banner

Meet Explore, NetApp’s digital sales platform

Engage digitally throughout the sales process, from product discovery to configuration, and handle all your post-purchase needs.

NetApp Insights to Action
I2A Banner