For those who haven't noticed, Prime Infrastructure (PI) 2.2 was released on 17 December. The Release Notes, Quick Start guide, etc. are all posted on the PI product support page.
I downloaded the 3.2 GB ova and deployed / installed via vCenter into a VMware ESXi 5.5 environment without issue.
The migration path is to backup your supported earlier version to a repository and then restore from that repository onto the new host. I grabbed a fresh backup of our PI 2.1.2 and followed the guide to restore. It took a while (about 1-1/2 hours to restore and then 30 minutes more to start completely - see output below) but the process ran without a hitch. You do need to make sure that the new host meets or exceeds the hardware specs of the old one - i.e. amount of memory, disk and vCPUs.
My initial look at the new system seems to indicate all is well - I see all the expected maps and devices and old configuration archives were pulled over. I have quite a bit of exercising the new feature set to do but initial indications are promising.
It's good to finally see the Topology map.
PI/admin# show restore log Started at : Thu Dec 18 11:59:29 2014 Initiating restore. Please wait... Restore Started at 12/18/14 11:59:36 Stage 1 of 9: Transferring backup file ... -- completed at 12/18/14 12:00:33 Stage 2 of 9: Decrypting backup file ... -- completed at 12/18/14 12:05:08 Stage 3 of 9: Unpacking backup file ... -- completed at 12/18/14 12:05:10 Stage 4 of 9: Decompressing backup ... -- completed at 12/18/14 12:08:30 Stage 5 of 9: Restoring Support Files ... -- completed at 12/18/14 12:08:31 Stage 6 of 9: Restoring Database Files ... -- completed at 12/18/14 12:08:54 Stage 7 of 9: Recovering Database ... -- completed at 12/18/14 12:36:03 Stage 8 of 9: Updating Database Schema ... Stage 1 of 5: Pre Migration Schema Upgrade ... -- completed at: 2014-12-18 12:56:00.638, Time Taken : 0 hr, 14 min, 59 sec Stage 2 of 5: Schema Upgrade ... : This could take long time based on the existing data size. -- completed at: 2014-12-18 13:11:04.244, Time Taken : 0 hr, 15 min, 3 sec Stage 3 of 5: Post Migration Schema Upgrade ... -- completed at: 2014-12-18 13:31:26.188, Time Taken : 0 hr, 20 min, 21 sec Stage 4 of 5: Enabling DB Constraints ... -- completed at: 2014-12-18 13:31:58.651, Time Taken : 0 hr, 0 min, 27 sec Stage 5 of 5: Finishing Up ... -- completed at: 2014-12-18 13:32:22.251, Time Taken : 0 hr, 0 min, 23 sec -- completed at 12/18/14 13:33:29 Stage 9 of 9: Re-enabling Database Settings ... -- completed at 12/18/14 13:33:29 Total Restore duration is: 01h:33m:53s INFO: Restore completed successfully. Starting PI Server... This may take some time Starting Prime Infrastructure... This may take a while (10 minutes or more) ... Prime Infrastructure started successfully. Finished at : Thu Dec 18 13:56:36 2014 PI/admin#
Good question - no it did not. The SSL certificate would still need to be re-added as a separate action.
The server from which I backed up PI 2.1 had a CA-issued certificate. The new PI 2.2 server had a self-signed certificate which persisted after the restore from backup.
Well, my experience are a bit different. I'm sitting with a newly updated PI 2.2 and the certificate, issued from our internal CA is there, after restore from backup.
If I understood the Post-installations tasks mentions in the Quick Start Guide, I also should have been forced to rehost my assurance licenses, but they also appeared without any trouble after the restore
Interesting - I double checked just now to make sure I wasn't misreading the situation since my new PI doesn't have a DNS entry (and thus I'm not using FQDN for it) just yet.
But, no, it is definitely using its brand new self-signed certificate. Here's a screen shot of both (hostnames redacted):
I have a case where customer is restoring backup from Prime Infrastructure 2.1 to 2.2.The zipped DB size is 28GB. It's being more than 29hrs....the restoration process ongoing. Customer is restoring the database from FTP server.
Please find the log from dbadmin_StdOut.log
ade # tail -f dbadmin_StdOut.log
In com.cisco.upgrade.MigrateRFMModel: preMigration()
22.214.171.124 matched within [126.96.36.199,188.8.131.529]
-- completed at: 2015-03-10 17:07:31.928, Time Taken : 0 hr, 14 min, 27 sec
Stage 2 of 5: Schema Upgrade ...
: This could take long time based on the existing data size.
-- completed at: 2015-03-10 17:11:06.612, Time Taken : 0 hr, 3 min, 34 sec
Stage 3 of 5: Post Migration Schema Upgrade ...
In com.cisco.upgrade.MigrateRFMModel: postMigration()
/**** PostMigration SQLs ****/
184.108.40.206 matched within [220.127.116.11,18.104.22.1689]
ade # tail -f sqlUpgrade.log
10-MAR-15 05.19.38.743478000 PM +00:00: 10-MAR-15 05.19.38.743411000 PM +00:00:: Beginning upgrade script rootallUrlTask
10-MAR-15 05.19.38.744821000 PM +00:00: 10-MAR-15 05.19.38.744797000 PM +00:00:: get count from xmptask where instancename=rootallUrlTask and urlexpression=.*
10-MAR-15 05.19.38.746149000 PM +00:00: 10-MAR-15 05.19.38.746127000 PM +00:00:: Update xmptask for instancename=rootallUrlTask to exclude credential API
10-MAR-15 05.19.38.746201000 PM +00:00: 10-MAR-15 05.19.38.746188000 PM +00:00:: Committing
10-MAR-15 05.19.38.750147000 PM +00:00: COMPLETED script PI22_upgrade_rootAllUrlTask_Expression.sql execution
10-MAR-15 05.19.38.752041000 PM +00:00: STARTED script setauth.sql execution
10-MAR-15 05.26.40.031852000 PM +00:00: COMPLETED script setauth.sql execution
10-MAR-15 05.26.40.033094000 PM +00:00: STARTED script ifm_sam_pm_ddl.sql execution
10-MAR-15 05.28.15.781912000 PM +00:00: COMPLETED script ifm_sam_pm_ddl.sql execution
10-MAR-15 05.28.15.784297000 PM +00:00: STARTED script PA_Upgrade_2_1.sql execution
I did the same. We had the 2.0 Prime running. I made a clone of this server and then the inline upgrade to 2.1. The Backup in the 2.1 Version and then the Restore in 2.2.
Our Backup is about 20GB big and it takes about 2,5 hours to restore and another 30-60 min to start.
As you said the certificate was not restored.
At the old CPI 2.0 i make every day a export of all Clients Sessions as csv and transfer it to a ftp server.
At the 2.0 the csv file was about 20mb per day big. Now at 2.2 i get csv.zip file with the size of about 4mb, and in the zip file there are about 8-10 csv files with about 2-3mb. I have looked in csv file. there are now only exact 15.000 rows.
Is this changed?
Can you test this for me if this is at your installation too?
Thanks Tobias Feichtinger
Did you do an appliance backup or application backup? I was hoping to simply backup our existing data from our 2.1 server then restore it to the new 2.2 CPI server (VM) that is up but then in the course of doing this I noticed there are two types of backups which raises some issues. What I want to do is run them concurrently so I don't have duplicate IP addresses so I'd just like to backup / restore the devices and users not the appliance IP address etc since that is unique.
Evidently this seems possible using the application backup but I'm not sure which application it is referring to by name since that has to be specified.
It would be very helpful for Cisco to give a specific migration document since this is a requirement if we are to preserve our existing data.
Any advice you can provide would be greatly appreciated as always!
An application backup is the required type. See Step 2 here.
I'm doing it in just the way you're thinking - running both concurrently with unique addresses until I'm ready to decommission the PI 2.1 host.
Here is a screenshot of where you do the backup:
Thanks so much! I did continue to research this from the 2.2 migration section and found that the name of the application backup is NCS; this was the key. Thanks for your quick reply and as always ... you make this forum what is .... a very valuable resource!
Please take a moment to rate helpful replies - it encourages them to keep coming. :)
Happy New Year.