napp-it refusing http and https connections

qhash

Weaksauce
Joined
Oct 25, 2011
Messages
110
Hi,
After some time of not checking on my ESXi test lab at all, I have an environment with a problem.
My napp-it VM was stopped, upon restarting it has received a different IP as its inside DHCP enabled network. After restarting, I cannot access the web interface of napp-it. I can login with SSH and from the console level.
Some theoretical questions from a person learning it all to people knowing napp-it and solaris:
1. what might be the cause of me not able to log in?
2. if the IP was changed; how that affects ZFS/iSCSI? I mean how the change without stopping deamon, changing IP, starting deamon will end-up? I never though about it as I always set static address for servers, etc. If one cannot change to the old IP, what should be done then?
 
Call ifconfig -a at console to get (new) ip
Then connect to that ip:81, optionally change ip to a static adress in System > Network Eth

If ip changes, all services are available only under the new ip

optionally restart napp-it at console as root:
/etc/init.d/napp-it restart
 
It's not that server is unavailable. It is refusing connections on both 81 and 82 ports. I did what you say. I even deleted network configuration and re-added it as static one.
As this is still lab, I will reinstall napp-it and try to add my datastores and see if I do not lose data.
 
_Gea I have imported pools and I now have all the names of the pools and filessystems... but after moutning ZFS data is not there. I have tried to look through napp-it manuals to verify my actions vs recommened steps, but I could not find any disaster recovery tutorials. Could you elaborate a little bit what to do in case host/HBA fails or you need to move your drives somewhere? I know that I have started from connectivity problem, but this can be valuable to the community (i think).
 
ZFS is extremely uncritical so there is no special disaster recovery method needed.
If a pool is imported and more disks than the redundancy level allows are missing, the pool is unavailable. If enough disks come back, the pool is available again. If there are remaining errors, you can do a zpool clear.

If a pool is not imported (does not matter if you have moved the disks over servers or HBAs or did a zpool export or destroy) a simple zpool import is enough.

more https://docs.oracle.com/cd/E23824_01/html/821-1448/gbchy.html
 
OK, thanks for the link. I need to do some learning + try and see before moving to production.
 
Back
Top