Data Infrastructure Management Software Discussions


Performance Advisor / Management Console access

Hello all

I am deploying a new storage contoller pod that is in a restrictive network zone; trying to get ports to open up through the customer's security group is like trying to balance the state budget ... slow.

PROBLEM - When launching NetApp Management Console ( from DFM 3.8 ), i get a timeout on both HTTP and HTTPS on ports 8088 and 8488

I can SSH into the linux host and use DFM commands and use the web interface through port 8080

A contact of mine here uses a special HTTP tunnelling program to access the NMC and is able to get PA to display - although I do not know if all of PA's functionality will work through such tunnelling.

Can I change the NMC access ports to be 8080 and would that conflict with the web interface for DFM?

If Tunnelling HTTP can work, is there a recommended configuration/software package we recommend?

Thanks, Emanuel


Re: Performance Advisor / Management Console access

okay ... got part of my answer resolved ...

I can use putty to open a SSH - Tunnel configuration and I have added three entries for DFM sevices:

Hostname - full qualified DNS name for the dfm server

In Connection, choose SSH, Tunnel, add the following:

- Localhost:8080

- Localhost:8088

- Localhost:8488

My other question is still vailid .. using this method, can i expect to have full functionality?

Re: Performance Advisor / Management Console access

See the second table in FAQ entry 3.14:

You may also tunnel 8443 if you want to use OM UI over HTTPS.

And these are the only ports required for OM (8080 and 8443) and Performance Advisor client (8088 and 8448) to connect to the server.



Re: Performance Advisor / Management Console access


Which ip address did you put ?

You need to put the ip address of the server where is installed DFM and not put the Filer Ip address.

keep me informed.

Hicham Azarou

Re: Performance Advisor / Management Console access

Tunneling 8443 and 8448 may be overkill since the transmission is already over SSH and therefore secure. Of course if the company policy does not allow the plain HTTP transmission you will need to do this.

As far as full functionality is concerned, I use this configuration regularly and have not had any problem yet. I use ssh on Linux and not putty, but I don't think that should make a difference.