discoverArray errror with SRA 7.1 and SRM 6.5.1

[kmc]

I am trying to add an array manager in SRM 6.5.1 using NetApp SRA 7.1 connecting to cdot 9.1p5, but getting the error:  SRA command 'discoverArrays' failed. Cause: Authentication failed. Invalid management IP address and/or invalid credentials

I'm reinstalling and configuring SRM 6.5.1 after upgrading our vCenter servers to 6.5U1e. I removed the previous version of VSC from the vCenter MOB site and removed the vCenter Web Client plugins from VCSA for both primary and DR locations.  I have two new Windows servers, one for primary/protected site and one for DR site.  I was able to install SRM 6.5.1 on both Windows servers.  I deployed a VCS/VASA/SRA 7.1 virtual appliances at each site and sucessfuly registered for each vCenter at the same location.  I then installed the .msi for the SRA 7.1 on both SRM servers.  After the installs I was able to go to the VSC plugin in vCenter Web client and enable SRA.  In the Site Recovery plugin of vCenter Web Client, I was able to create the site pairing, placeholder datastore, and mappings for resources, networks, and folders.

The add array dialog shows both vCenters at each site.  It correctly shows the NetApp SRA 7.1 as installed/available.  I enter the IP address of the storage management cluster.  I give the list of IPs serving the ESXi hosts.  I enter the SVM name.  And finally give username and password.  (The same username/password worked in previous vCenter 6.0 and SRM 5.8 install with SRA 2.1.  And login works connecting to OnCommand Manager)

I've tried other NetApp cluster IPs and SVMs.  I've tried the username with domain\username, username@domain.com, and just username.  And I've tried the admin account.  Same error.  No firewalls in between.

The logs are not very useful.  I have yet to find a way to generate the SRAs CMODE-ONTAP SRA log on the SRM server.  I have packet captures from VCSA, VSC/SRA appliance, and Windows SRM servers and working on sifting through the data.

I had this same error over a year ago when configuring SRM 5.8 and SRA 3.0.  I opened a ticket with NetApp support and recommendation was to use previous version of SRA 2.1, which does not use the VASA/VSC virtual appliance.  I wonder if this isn't an failing SSL connection.  We are using internal CA certs on NetApp management, VCSA, and SRM.  But I don't see a way to add a trusted root CA or replace self-signed certs for the VASA/VCS/SRA appliance.

Thanks for any help or advice.

[satishv]

Hi,

Is the storage system that you are using during array manager creation added to the VSC “Storage Systems” page. It should be showing the same ip.

Thanks,

~Satish

[kmc]

When I look at the 'Storage Systems' section in VSC, I get an error "The query execution timed out because of a back-end data adapter 'com.netapp.vsc.storagesystem.service.StorageSystemDataAdapter' which took more than 120 seconds" 

After a few minutes I get the option to Add.  I did manually add the IP of the cluster of the SVM I'm trying to add at the one site in SRM.  But never see the device or any others show up in the Storage Systems list.  However if I go into the Summary page of the VSC I do see data in the Overview, datastores, Virtual Machines sections. 

And I get same discoverArray error trying to add array manager.

Thanks for reply.

[satishv]

The IP that you are trying to add on the storage systems page and the array manager - Is it the SVM mgmt IP? Are you able to ssh into it and perform any operations?

The IP thats added on the VSC storage systems page and also on the array manager should be the SVM mgmt or Cluster mgmt IP. 

Thanks

[ikiris]

Not sure if you figured this out, but I had this issue last year and I worked it out with Netapp.

The trick is to add the SVM or cluster IP via the web cli at https://SRAIP:9083

Then go to web based cli interface

cluster add -cluster_ip=cluster_mgmt_ip -username=new_user_name -password=password -ssl=true

Example: cluster add -cluster_ip=1.2.3.4 -username=admin -password=secret -ssl=true

This is from the SRA 4.0 admin guide I believe, but nowhere in the subsequent guides.

https://library.netapp.com/ecm/ecm_download_file/ECMLP2610376

Start at page 23

[Lance_T]

Strangely, if I use the FQDN for the cluster IP instead of the cluster IP (FQDN resolves to the cluster IP I was trying), it works.   Yes, using the name works when the IP doesn't.  Not what I would expect.