Table Of Contents

Troubleshooting Errors in Data Migration

Errors From CS Data Migration

Errors From RME Data Migration

Errors From DFM 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

•Frequently Asked Questions on LMS Upgrade and Data Migration

You must:

•Make sure that the server configuration and OS versions are compatible with LMS 2.5.1. 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

There is another way of migrating data, where you do not have to perform inventory collection during migration. This is if there are many devices in the backup. Inventory can be triggered 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:

1. Stop the LMS system by entering:

/etc/init.d/dmgtd stop

2. Run the following two commands:

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

3. rm -fr 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:

/opt/CSCOpx/MDC/log/core-MM-DD-YYYY.log

•Sybase version:

Solaris: 9.0.0.1364

You can get the Sybase version by entering: NMSROOT/objects/db/bin/dbversion

Windows: 9.0.0.1383

You can get the Sybase version by entering: NMSROOT\objects\db\win32\dbeng9 -v

•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. The 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 is useful to debug issues of corrupted files and issues related to failure of some basic components. It runs PERL scripts that provide outputs indicating 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 2.5.1. 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

•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.

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

There is another way of migrating data, where you can skip inventory collection during migration. That is, if there are many devices in the backup. You can trigger Inventory Collection from the UI after you complete the data migration for other applications.

Sometimes, RME Migration may fail with 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 executing migration:

Solaris

NMSROOT/bin/perl NMSROOT/bin/dbRestoreOrig.pl dsn=cmf dmprefix=Cmf opt=Y

Windows

NMSROOT\bin\perl NMSROOT\bin\dbRestoreOrig.pl dsn=cmf dmprefix=Cmf opt=Y

Errors From DFM Data Migration

If you encounter errors during DFM data migration:

•Check logs. The relevant log files are:

Solaris

–/var/tmp/ciscoinstall.log

–/var/tmp/ciscouninstall.log

–/var/adm/CSCopx/log/dbbackup.log

Windows

–SystemDrive:\Ciscoworks_setupno.log, where SystemDrive is the drive where your operating system is installed

– NMSROOT\log\dbbackup.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

Frequently Asked Questions on LMS Upgrade and Data Migration

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. I tried to install LMS 2.5.1 and the installation failed. How do I clean up the installation completely?

A. If the installation failed because some basic prerequisities were not met, then you need not do any additional cleanup. The installation process cleans up on its own and exits gracefully.

If the installation failed because of some abnormal condition (such as aborting accidentally), we recommend the following procedure for cleaning up the installation:

For Windows

–Delete CSCOpx folder

–Delete SystemDrive\CMF.LOCK file

–Delete the registry keys (HKEY_LOCAL_MACHINE > SOFTWARE > Cisco > ResourceManager)

–Restart Machine

For Solaris

You must run the clean_system.sh script. Go to the URL:

http://www.cisco.com/en/US/products/sw/cscowork/ps2425/
products_configuration_example09186a0080133f4f.shtml#uninstallSol

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

A. On Solaris, if errors occur during installation, check the installation log file /var/tmp/ciscoinstall.log.

For IPM, the installation log file is /var/tmp/cisco_ipm_install.log.

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_setupxxx.log, where xxx is the running number for the last CiscoWorks application installed.

For IPM, there is no installation log file on Windows.

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

A. No, this option is not currently supported.

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

A. You must do the following:

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

b. Upgrade your operating system to Windows 2003 Server.

Q. I have been running LMS 2.5.1 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.