You can migrate your KB by using the
You must migrate and merge your KB only if the KB and the mcell.conf file located at MCELL_HOME\etc\cellName\ contain any customizations.
This section shows how to launch the
mmigrate utility manually.
The manual procedures and the manual execution of the scripts are aimed at experienced and knowledgeable users.
mmigrate utility is a BMC component that automatically migrates older KBs to the latest, standard KB formats in the current release. It is launched from a computer that has the latest version of the Integration Service.
mmigrate utility performs the following operations:
You can execute the
mmigrate utility to migrate configuration and KB data from earlier versions to the latest versions of Infrastructure Management.
mmigrate utility is located in the <installation directory>\Windows or Linux\MigrateKB\server\bin directory.
There are at least four KBs involved in running the
mmigrateutility is trying to migrate
mmigrateitself. They are the common ancestors to both the customer KB and the reference KB. The
mmigrateutility will by default compare every existing, potentially customized KB definition with every released definition of the same name, so the
mmigrateutility might look at several ancestors.
When running the
mmigrate command, determine the type of cell you are creating, the old cell directory, and the new cell directory that contains the result of the migration.
The syntax of the
mmigrate command is as follows:
mmigrate [-option] [type] custom_kb_directory output_directory
output_directory is the directory to which the KB is migrated. You must provide this parameter.
-ap embedded PNET (PPM)
mmigratecommand are listed as follows:
-hdisplays the online help for the command.
-v sets the verbosity level of the
mmigrate messages. In the order of severity, the options are VERBOSE, INFORM, WARNING, ERROR, and FATAL.
-v option without a following descriptor sets the trace level to VERBOSE
INFORM is the default level, which does not require the -v option.
The specified level and the next higher severity levels are printed. For example, if you specify -v WARNING, then WARNING, ERROR, and FATAL messages are printed. FATAL messages are never filtered.
mmigrate -v -ap "C:\TrueSight\pw\server\etc\custom_cell" "C:\migrated_cell_kb\custom_cell"
mmigratecommand, ensure that C:\migrated_cell_kb directory already exists.
mmigratecommand, if there are any conflicts, you must resolve them manually and recompile the cell.
The table below lists the values that your
mmigrate cell type selection assigns to the
POMEnabled variables in the mcell.conf file.
Cell type impact on mcell.conf variables
When executed, the
mmigrate utility modifies the following parameter values to ensure that they meet the specified minimum constraints in the indicated configuration files under the installationDirectory\pw\server\etc folder.
ConnectionSetupTimeOut >= 20 seconds
TraceFileSize >= 5 MB
TraceFileSize parameter, the value 0 (zero) indicates no limit to the size of the trace file. For example, if the value of the
TraceFileSize parameter is 0, it is considered an infinite file size and thus meets the constraint of
>= 5 MB.
EventDBCleanupDurationLimit <= 10 seconds
EventDBKeepClosed >= 3d
EventDBSize >= 330k
ServerHostName >= Name of host system
StateBuildSize >= 10 MB
TraceFileSize >= 5MB
TraceFileSize >= 5MB
TraceFileSize >= 5MB
For example, if the
mmigrate utility discovers that the
ConnectionSetupTimeOut parameter value is less than 20 seconds, it updates the value to meet the minimum value of 20 seconds.
When it alters a parameter value, the
mmigrate utility maintains the original value as a comment prefixed with
# was:. For example, if you execute the
mmigrate utility with the
-ap option and it alters the
TraceFileSize parameter values to meet the minimum constraints in the mcell.conf file, the stanzas look as follows:
mmigrate impact on configuration files
The .load files must reference all the customized KB source files that you want the
mmigrate utility to merge in the new output directory.
mmigrate utility is run, it merges the contents of both the customer load lists and reference load lists in generated .load files, in the following order:
Conflicts identified by the
mmigrate utility are marked in the following way:
For example, we have three files:
The ancestor KB has the following definition:
Your KB definition (yours):
My KB definition (mine):
The conflict will appear in the merge as follows:
Open the file containing the conflicts, and review the conflicting definitions shown by the conflict markers. Select one of the conflicting definitions or replace it with something else. Save and close the file, and then recompile.