|
Brian,
James is absolutely right in his advice to you.
My advice is you should open a PMR with support to help solve your "dies in various places" migration failures.
Two tips:
Once a migration fails, depending on where you fail, you can very easily find yourself in a situation where there is no way to succeed, unless you restore the system before your next attempt. For example, assuming UNIX, if you fail in either of the two final steps of installation, and if you do not completely cleanup the installation and reattempt with the originally created /usr/OV.back* filesystem, all subsequent attempts to migrate will either overtly fail or yield incorrect results. This is because the system now has an updated ODM entry for the new version of NetView, which results in incorrect migration decisions being made in the scripting that does the migration work. Only the /usr/OV.back.* filesystem created before the first failure contains the correct "from" version information. So as James pointed out, the /usr/OV.back.* that was created either by you with serversetup, or the first one created by your first migration attempt (or after complete restores after failures) are invaluable and should be protected. This all assumes you are going to drive to completion, the migration effort in one session. If you have to wait for a window of opportunity in the future, and in-between, run production NetView, it is best to completely restore, prove all is well, and create a new /usr/OV.back.* filesystem or allow migration to create it, in your next window. That way your migration will migrate in the latest databases.
Another problem that can arise is if you create a /usr/OV.back* filesystem (usually using serversetup) on one system, say your production server, and move it to a new target system, say a lab or test box, that has a different IP address or hostname or domain name. New daemon registrations may fail because /usr/OV.back.*/conf/ovors is copied onto the target system and will indicate the source system's internet identity, causing ovaddobj (daemon registration) to fail and installation to terminate. (The easy solution to this is to remove the /usr/OV.back.*/conf/ovors file before running the migration that will use it. Remember this is necessary if any part of the target internet identity is different from the source).
Regards,
Geo.
George deSocio
IBM Americas Support - Distributed Network Management
Dept 46-E1ZA
IBM B660 CC102
HWY 54 & 600 Park Offices
Research Triangle Park, NC 27709
E-Mail: desocio@us.ibm.com
Expand your IBM Tivoli product knowledge by participating in Support Technical Exchange:
http://www-3.ibm.com/software/sysmgmt/products/support/supp_tech_exch.html
 James Shanks/Raleigh/IBM@IBMUS
|
|
To: nv-l@lists.us.ibm.com
cc:
Subject: Re: [nv-l] Upgrading from 711 to 714 |
Personally, speaking I think it is a mistake not to do an upgrade install. If there are problems, you would likely have them with a new install anyway.
But even if you disagree, I think you should still create the backup directory using serversetup. You can always rename it to something else, if you don't want to use it for migration. Then it will contain everything which would have been merged or migrated. And you don't have to worry about losing any of it.
James Shanks
Level 3 Support for Tivoli NetView for UNIX and Windows
Tivoli Software / IBM Software Group
| "Brian W Green" <brian.green@cgi.com>
Sent by: owner-nv-l@lists.us.ibm.com
02/10/2004 11:31 AM
Please respond to nv-l |
To: "Netview Mailing List" <nv-l@lists.us.ibm.com>
cc:
Subject: [nv-l] Upgrading from 711 to 714 |
I am starting to plan to migrate my system from NV 711 to 714. I have
tried this as an upgrade install - every time it dies on me at various
places. I am now planning to do a complete deinstall and reinstall, but
before I do this, I need to plan out how to keep all the customizations
and reload them after the install completes. Things I can think of:
Topology
MIBS
SNMP Collect
Web GUI Users
SmartSets
Configurations with serversetup
Other than going through everything and recording every config to be
re-done after install, does anyone know of a command or commands to do
this?
Thanks,
Brian
Brian W. Green
IBM Certified Deployment Professional
CGI Information Systems and Management Consulting
275 Slater Street, 14th Floor
Ottawa, Ontario
K1P 5H9
(613) 234-2155
brian.green@cgi.com
|