Table Of Contents

Troubleshooting Errors in Data Migration

Errors From CS Data Migration

Errors From RME Data Migration

Errors From DFM Data Migration

Errors From IPM Data Migration

Frequently Asked Questions on LMS Upgrade and Data Migration

Troubleshooting Errors in Data Migration

---

This chapter describes the errors that you might encounter during data migration and guidelines on troubleshooting those errors.

This chapter contains:

•Errors From CS Data Migration

•Errors From RME Data Migration

•Errors From DFM Data Migration

•Errors From IPM Data Migration

•Frequently Asked Questions on LMS Upgrade and Data Migration

You must:

•Make sure that the server configuration and OS versions are compatible with LMS 3.0. Also, make sure the server has enough space to do the DB backup and restore.

•Check migration logs. The logs (migration.log, restorebackup.log, rme_base.log) are available under:

–Solaris: /var/adm/CSCOpx/log

–Windows: NMSROOT\log

•Note that time taken to collect inventory is directly proportional to the number of devices and the network response time

You can migrate data without perfroming inventory collection during LMS 2.2 data migration.

If there are many devices in the backup, you can trigger inventory from the UI after the data migration of other applications have completed.

If you encounter problems during the data migration process, do the following to clean up the temporary files and go back to the initial state:

---

Step 1 Stop the LMS system by entering,

•On Solaris

/etc/init.d/dmgtd stop

•On Windows

net stop crmdmgtd

Step 2 Run the following commands:

•On Solaris

NMSROOT/bin/perl
NMSROOT/objects/db/conf/configureDb.pl action=unreg dsn=rme dmprefix=Essentials

NMSROOT/bin/perl
NMSROOT/objects/db/conf/configureDb.pl action=uninstall dsn=rme

rm -fr NMSROOT/tempBackupData

•On Windows

NMSROOT\bin\perl
NMSROOT\objects\db\conf\configureDb.pl action=unreg dsn=rme dmprefix=Essentials

NMSROOT\bin\perl
NMSROOT\objects\db\conf\configureDb.pl action=uninstall dsn=rme

rmdir NMSROOT/tempBackupData

---

Errors From CS Data Migration

If you encounter errors during CS data migration, the following options are useful for troubleshooting:

•CAM (Core Admin Module) debugging:

You can enable CAM debugging by entering:

NMSROOT/MDC/bin/ccraccess -updateLog Core cam DEBUG

You can disable CAM debugging by entering:

NMSROOT/MDC/bin/ccraccess -updateLog Core cam WARN

Daemon Manager restart is necessary.

•CAM debug details:

CAM debug details are logged at:

NMSROOT/MDC/log/core-MM-DD-YYYY.log

•Server information:

To collect server information, select Common Services > Server > Admin > Collect Server Information from the CiscoWorks Home Page.

This allows you to quickly collect all information about the state of the system. You can use this report to send to TAC for troubleshooting.

This report provides information about System configuration, environment settings, application configuration details, process status, and product log files.

•SelfTest tool:

You can select Common Services > Server > Admin > SelfTest from the LMS Home Page to invoke the SelfTest tool.

The SelfTest tool checks the integrity and health of the system for some of the Common Services components.

This tool helps to debug issues of corrupted files and issues related to failure of some basic components. It runs PERL scripts that provide outputs that indicate whether the test has passed.

Errors From RME Data Migration

If you encounter errors during RME data migration, do the following:

•Make sure that the server configuration and OS version are compatible with LMS 3.0. Also, make sure the server has enough space to do the DB backup and restore.

•Check migration logs. The logs (migration.log, restorebackup.log, rme_base.log) are available at

–Solaris

/var/adm/CSCOpx/log

–Windows

NMSROOT\log

•If you get the OutOfMemoryError message, you can try to increase the available JVM (Java Virtual Machine) heap size to work around the problem.

The JVM heap size can be configured in:

–Solaris

NMSROOT/MDC/tomcat/webapps/rme/WEB-INF/classes/com/cisco/nm/
rmeng/migration/migration.properties

–Windows

NMSROOT\MDC\tomcat\webapps\rme\WEB-INF\classes\com\cisco\nm\
rmeng\migration\migration.properties

The migration.properties file has the following parameters:

Parameter	Purpose	Default Value
VM_MIN_HEAP	Minimum JVM heap size	128
VM_MAX_HEAP	Maximum JVM heap size	512
RETRIES	Number of retries for starting the daemon	15

You can increase the JVM heap size as much as possible (up to the available RAM). However, do not exceed real system memory or your application will stop responding.

Sometimes, RME Migration may fail and display a message in the logfile migration.log that DCRServer could not be started.

You can work around this problem by running the following command before performing migration:

–Solaris

NMSROOT/bin/perl NMSROOT/bin/dbRestoreOrig.pl dsn=rmeng dmprefix=RME opt=Y

–Windows

NMSROOT\bin\perl NMSROOT\bin\dbRestoreOrig.pl dsn=rmeng dmprefix=RME opt=Y

---

Note For the above commands, stop the daemons before entering the commands. Start the daemons after entering the commands.

---

Errors From DFM Data Migration

If you encounter errors during DFM data migration:

•Check logs. The relevant log files are:

Solaris

–/var/adm/CSCOpx/log/restorebackup.log

Windows

–NMSROOT\log\restorebackup.log

•Check the contents of the backup data file filebackup.tar. Note that the following is the list of DFM related files or databases that are backed up during the backup into the user-defined backup directory.

Contents of the following folders are backed up as filebackup.tar under specified backup directory.

Solaris:

–NMSROOT/objects/smarts/conf

–NMSROOT/objects/smarts/local/repos

–NMSROOT/objects/smarts/local/logs

–NMSROOT/objects/smarts/local/conf

–NMSROOT/setup/dfm.info

Windows:

–NMSROOT\objects\smarts\conf

–NMSROOT\objects\smarts\local\repos

–NMSROOT\objects\smarts\local\logs

–NMSROOT\objects\smarts\local\conf

–NMSROOT\setup\dfm.info

The following database files along with corresponding database transaction log files are backed up:

–dfmEpm.db—Contains the data of the DFM Event Promulgation Module

–dfmInv.db—Contains the data of the DFM Inventory

–dfmFh.db—Contains the data of the DFM Fault History

These files are located at:

Solaris

–NMSROOT/databases/dfmEpm/dfmEpm.db

–NMSROOT/databases/dfmInv/dfmInv.db

–NMSROOT/databases/dfmFh/dfmFh.db

Windows

–NMSROOT\databases\dfmEpm\dfmEpm.db

–NMSROOT\databases\dfmInv\dfmInv.db

–NMSROOT\databases\dfmFh\dfmFh.db

Errors From IPM Data Migration

•If you encounter errors during IPM data migration, please check the following logs:

–restorebackup.log

–migration.log

–ipmclient.log

–ipmprocess.log

The logs are available at :

–Solaris

/var/adm/CSCOpx/log

–Windows

NMSROOT\log

•If Custom operations are not migrated properly, check whether:

–ipm2.x backedup DB contains custom operations.

–Predefined or custom SNA Operations are migrated.

–Alerts of NMVT type are changed to none.

–Alerts of NMVT and SNMP trap are changed to 'snmp trap'.

•If Collectors are not migrated, make sure:

–Source, target devices, and operations are properly migrated.

–Collectors configured with SNA operations are migrated.

•If Collectors are not moved into running state, check whether:

–Devices are SNMP reachable from IPM4.0.

–There is sufficient memory in the router to configure probes. If not, remove some probes on the router cli.

•If devices are not migrated, make sure that the IPM2.x backedup database contains source and target devices.

•If backup directory of IPM2.5 or IPM2.6 does not contain all required files, make sure it contains at least the following files:

–ipmdb.db

–.dbPassword

–ipmdb.tmpl

–ipm.env

Frequently Asked Questions on LMS Upgrade and Data Migration

This section lists the frequently asked questions and solutions to them.

Q. Can I uninstall applications from the LMS server in any order?

A. You can uninstall applications in any order, but we recommend that you uninstall in the reverse order in which you installed them.

Q. Where can I find the logfiles for LMS 3.0?

A. On Solaris, if errors occur during installation, check the installation log file /var/tmp/Ciscoworks_install_yyyymmdd_xxx.log, where xxx is the running number for the last CiscoWorks application installed.

On Windows, if errors occur during installation, check the installation log in the root directory on the drive where the operating system is installed. Each installation creates a new log file.

For example, the CiscoWorks Common Services installation creates SystemDrive:\Ciscoworks_install_yyyymmdd_xxx.log, where xxx is the running number for the last CiscoWorks application installed.

Q. I have LMS 2.2 applications installed on different servers. Can I migrate data from these multiple servers to one LMS 3.0 server?

A. No, this option is not supported.

Q. I have LMS 2.2 installed on Windows 2000 Server. I want to upgrade the OS to Windows 2003 Server, and also upgrade to LMS 3.0. In what order should I perform these upgrades?

A. You must:

a. Upgrade LMS 2.2 to LMS 2.5.1 on Windows 2000 Server.

b. Upgrade your operating system to Windows 2003 Server.

c. Upgrade LMS 2.5.1 to LMS 3.0 on Windows 2003 Server.

Q. I have been running LMS 3.0 for sometime, and have collected a lot of data. I would like to restore an older LMS 2.x backup, and merge the data from the current system and the backup. Is this possible?

A. No. After a backup is restored, all the data that is currently in the running system is replaced with the data from the backup.