Network Management

Hi all; I have been running Airwave on my VMware 4.1 for a few years now.

I have just built a clean VM, grabbed the backup from the 7.4.4 server, shut it down, built the new 7.6 server with the same IP address.

I logged into the GUI and got the expected install license.

I then restored my backup to the 7.6 machine.  Now I get a "Unable to Connect" in the browser.

Was this too much of a jump in versions.

When I try to connect the http process is pinning the CPU, and with 4 cores and 8 gigs of ram that seems silly.

Thanks for any insight.

Chris

Yikes!  You've got a server migration, an upgrade, and a restore that are being tackled all at once.  The httpd process was probably trying to call the migration handlers, but was unsuccessful due to the code jump at restore time from 7.4.4 to 7.6.2 without proper database migration (database migration typically happens during upgrade).

Key things to keep in mind:

a. Upgrading from 7.4.4 to 7.6.2 is okay as you can upgrade between 2 releases skipping 1 major release (skipping 7.5 in this case).

b. Restores need to be made based on release versions, a 7.4.4 AMP backup will restore clean on a 7.4.4-7.4.9 (7.4.9 was the last release of 7.4).  A 7.4 backup will not cleanly restore on a 7.5 or 7.6 version due to schema changes in the database (where database tables or columns have been changes, added, deleted, or even split).

The clean way to get you back online (my recommendation) -

1. Delete the new VM instance that was installed with 7.6.

2. Create a new instance, installing 7.4.9 ISO

3. Restore the 7.4.4 backup

4. Upgrade to 7.6.2

-> this will get you to current AMP code

If you were trying to do this to upgrade the OS, then add these steps:

5. Take backup of 7.6.2

6. Pull backup off server

7. Power down instance (At this time, you may delete the instance, I keep it around in case something went wrong with the backup to save me from going back to step 2)

8. Create new instance, installing 7.6.2 ISO

9. Restore 7.6.2 backup

10. Delete intermediate instance that was power down in step 7 if you haven't already done so.

The alternative (okay for lab, but not for production), there's a battle of risk and reward here:

# root; make

This command should call for the database migrations that were missed when the upgrade process was never called.  The risk is if the database changed to a point that the restore did not put anything in the database.  This is more likely to work if the upgrade is spanning 1 release, but the scenario you put together is upgrading a span of 2 releases.

yeah, I suspected it might be database issues.

But I like to reach for the stars.

first things first though, I get start the download and order lunch.

So much for going to the gym today.

I post my sucess back here before the dinner bell I am sure.

Any update on your AMP status?