Network Management

we are currently running Airwave 8.0.4 on Hyper-V.  Considering upgrading to 8.2.  what are the HW requirements;mem and processor requirements:

We are currently Running 8.0.9 on the below:

Intel(R) Xeon(R) CPU E7- 4870 @ 2.40GHz 4 Cores 30720 KB cache (2394.010 MHz actual)
Memory
Installed Physical RAM: 31.35 GB
Configured Swap Space: 4.00 GB
Kernel
Kernel Version: Linux 2.6.32-431.23.3.el6.x86_64 #1 SMP Thu Jul 31 17:20:51 UTC 2014
Operating System: CentOS release 6.2

The server sizing guide (link) should be useful.

I suspect that if you're running 8.0 OK, 8.2 will be OK too.

Need more info.

How many devices (switches/controllers/APs) are being monitored/managed by AirWave?  Are any of these devices Aruba Instant?

Is VisualRF enabled?  If so, how much memory allocation is to VRF?

Is AppRF enabled?

Are you capturing client data via AMON or via SNMP?

What is client behavior?  (hotspot, office, classroom, dorm)

Each of the above may cause a change in either disk space needed, or RAM needed.  In several cases, you may get away without having to resize.  Or you can try the 'all in' (push poker chips into the pot) and go for the upgrade (only do this if you take a snapshot of the VM beforehand - or at least save off the last nightly backup).

The snapshot saved our installation on Monday, excellent advice!!

Thanks for

Need more info.

How many devices (switches/controllers/APs) are being monitored/managed by AirWave?  Are any of We have ap105 in some buildings  and ap 225 in others.

Is VisualRF enabled?  If so, how much memory allocation is to VRF?

Visual RF is enabled with 8GB Mem. Alloc.

AppRF is enabled

Are you capturing client data via AMON or via SNMP? capture via SNMP

What is client behavior? office, roaming from floor to floor and building to building.

By those metrics, I don't see why the same sized server wouldn't work.  You should be okay to upgrade to 8.2.  Please note that as of yesterday, we put a patched version onto the support site (due to postgres upgrade).

# start_amp_upgrade -v 8.2.0.1

literally upon hitting enter after username/password for upgrade download to start, cli session disconnects.

if i leave the cli session open, and do not attempt upgrade, no disconnects.

anyone else having this problem?

is there a way for to kickoff the upgrade, and have it run without me being connected via cli, since i am not using ftp from my server, but using the start_amp_upgrade -v 8.2.1.1 command, which should download from aruba, thereby, i should not need to be connected?

we have had a few others that disconnected at 37% and then had to restart

any help would be welcome

thanks

You can use the "screen" directive.  When you get into your SSH session, type "screen" press enter, and then type your upgrade commands.  If you disconnect, your session will continue.

More information on this command is here:  https://www.rackaid.com/blog/linux-screen-tutorial-and-how-to/

thank you for the recommendation

tried it and when i disconnected/reconnected, there was no mention that the upgrade was still running, no further updates, no visible way to see if the upgrade was actually continuing.

is there a -tail or other command i can do, or use, or run to see or check on the upgrade, if indeed it is still running?

You should be able to do a 'psg upgrade' to see if the process is running in the background.

Also, here's a page that shows how to use screen:

https://www.gnu.org/software/screen/manual/screen.html

You should be able to do 'screen -r' to reattach to an existing screen.  'screen -ls' to list any running screens.

Also, if the upgrade did happen to take place, a good check would also be the AMP upgrade logs:

/var/log/upgrade/*

Current Version: RELEASE_8_0_9_1
[root@localhost mercury]# psg upgrade
root 4826 0.0 0.0 133908 6028 pts/1 S+ 09:42 0:00 upgrade
root 4838 0.0 0.8 269956 68108 pts/1 S+ 09:42 0:00 upgrade
root 15300 0.0 0.0 133904 6012 pts/0 S+ 13:30 0:00 upgrade
root 15315 0.4 0.8 269976 68092 pts/0 S+ 13:31 0:00 upgrade
[root@localhost mercury]# cd /var/log/upgrade
[root@localhost upgrade]# ls

this is the result of the psg upgrade and the var/log/upgrade folder was empty.

Its weird that it came up with 4 entries though.  It's a good idea to open a support case.  Also, try strace on those PIDs to see what they are doing.  Often times, the upgrade won't proceed if nightly_maintenance is still running.