Using the mmigrate utility

The mmigrate utility is used to migrate the cell KB from an earlier version to the latest version of the TrueSight Infrastructure Management. You must run the mmigrate utility to retain the customizations in the cell KB files and the mcell.conf file present in the <TrueSight Infrastructure Management Install Directory>\pw\server\etc\cellName directory. For example, if you plan to upgrade from TrueSight Infrastructure Management 10.7 to 11.3.01, and if TrueSight Infrastructure Management 10.7 cell KB contains customizations, you must run the mmigrate utility to migrate the cell KB to retain these customizations.

The following section explains how to run the mmigrate utility, and also describes the sequence that is used to merge cell KB .load files. 

Warning

The manual procedures and the manual execution of the scripts are aimed at experienced and knowledgeable users.

To run the mmigrate utility

There are at least four cell KB files referenced when you run the mmigrate utility:

  • customer KB: The cell KB in the existing TrueSight Infrastructure Management version. The mmigrate utility will migrate the cell KB from this version to the latest version.
  • latest KB: It is the default KB installed with the latest version of TrueSight Infrastructure Management
  • merged KB: This is the target or destination KB that contains the content merged from both the customer KB and the latest KB. It is the only KB directory that is modified in the migration process.
  • ancestor KB: This is a precompiled KB bundled with the mmigrate utility. By default, the mmigrate utility compares every customized KB definition with the latest definition with the same name. The mmigrate utility might look at several ancestors.

The mmigrate utility performs the following operations:

  1. Copies the customer KB and the latest KB to a merged KB.
  2. Copies the latest standard KB directory over the merged KB skipping top-level configuration files.
  3. Updates configuration files (.conf).
  4. Merges the .mrl and .baroc files from the customer KB and the latest KB to the merged KB.

Syntax

The mmigrate utility is located in:

  • (Windows) <TrueSight Infrastructure Management Download location>\MigrateKB\Server\bin
  • (Linux) <TrueSight Infrastructure Management Download location>/MigrateKB/server/bin

The syntax for mmigrate utility is as shown in the following code block:

mmigrate [-option] [type] <custom_kb_directory> <output_directory>

Where:

ParameterDescription
custom_kb_directorySpecify the full path of the customer KB located in the <TrueSight Infrastructure Management Install directory>\pw\server\etc directory.
output_directory

This indicates the merged KB. The customer KB and the latest KB will be merged and copied to this directory.

Note: Specify the complete path of the directory.  This is a mandatory parameter, and you must specify a value to this parameter.

type

Indicates the type of cell data that you want to migrate. 
Note: The type of the cell determines the way in which the ServiceModelEnabled and POMEnabled variables are set in the mcell.conf file. This is a mandatory parameter, and you must specify a value to this parameter.

The supported cell types are:

  • -aa administrative (Admin)
    Note: The <latest KB> for the Admin cell type is in the installationDirectory\pw\server\etc\admin directory. For all other cell types, the <latest KB> you are merging with is in the installationDirectory\pw\server\etc\default\standard directory.
  • -ae: BMC Event Manager (BEM)
  • -as: Service Impact Manager (SIM)
    Note: Use this option to migrate the remote cell KB.
  • -ap: Embedded PNET (PPM)

    Note: Use this option:

    • If you plan to migrate a POMEnabled cell that is bundled with the Infrastructure Management Server cell (default cell)

    • If the customer KB version is 8.6.xx or 9.0.xx

option

The optional arguments for the mmigrate command are listed as follows:

  • -h displays 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 VERBOSE: The -v option without a severity descriptor sets the trace level to VERBOSE

    • The mmigrate command without -v option sets the trace level to INFORM.

    • -v WARNING

    • -v ERROR

    • -v FATAL

    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.

  • -z prints the version number of the command and exits.

  • (Applicable only to TrueSight Infrastructure Management version 11.3.02 and later) -r <release version> Specify the customer KB version that needs to be migrated. For example, if you are planning to run this command to migrate cell KB version 11.0 to the latest version, run the the following command:
    mmigrate -v -r "11.0.00" -ap "C:\TrueSight\pw\server\etc\custom_cell" "C:\migrated_cell_kb\custom_cell" 

    • -r option is supported for TrueSight Infrastructure Management 10.7 and later versions.
    • If you specify a version earlier to TrueSight Infrastructure Management 10.7, then the mmigrate utility ignores this version and assigns a version to the customer KB file based on its ancestor KB details. In such scenarios, the .load sequencing may produce results with some deviations.

Example

The following example illustrates the use of various options available in the mmigrate command line utility:

mmigrate -v -ap "C:\TrueSight\pw\server\etc\custom_cell" "C:\migrated_cell_kb\custom_cell"


Parameter description

  • -v specifies the trace level to VERBOSE.
  • -ap specifies the type of the cell as embedded PNET (PPM).
  • C:\TrueSight\pw\server\etc\custom_cell specifies the custom_kb_directory.
  • C:\migrated_cell_kb\custom_cell specifies the output_directory. Before you run the mmigrate command, ensure that C:\migrated_cell_kb directory already exists.
  • custom_cell is the name of the kb file.
  • After running the mmigrate command, if there are any conflicts, you must resolve them manually and recompile the cell.

To compile the cell KB

After running the mmigrate utility, ensure that you run the  mccomp command to compile the cell KB.

To understand the configuration file updates

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.

  • mclient.conf
    • ConnectionSetupTimeOut >= 20 seconds
    • TraceFileSize >= 5 MB

      Note

      For the 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.

       
  • mcell.conf
    • EventDBCleanupDurationLimit <= 10 seconds
    • StateBuildSize >= 10 MB
    • TraceFileSize >= 5MB
  • smmgr.conf
    • TraceFileSize >= 5MB
  • statbld.conf
    • 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 EventDBKeepClosedEventDBSizeStateBuildSize, and TraceFileSize parameter values to meet the minimum constraints in the mcell.conf file, the configurations are as follows: 

 mmigrate impact on configuration files

BEFORE:
***************************************************
EventDBKeepClosed=2d
EventDBSize=100000
StateBuildSize=1000
TraceFileSize=1M

##############

CellDuplicateMode=0
ServiceModelDirectFeed=Yes
ServiceModelPublish=Yes

AFTER:
***************************************************
EventDBKeepClosed=3d # must be at least 3d
# was: EventDBKeepClosed=2d
EventDBSize=330k # must be at least 330k
# was: EventDBSize=100000
StateBuildSize=10M # must be at least 10M
# was: StateBuildSize=1000
TraceFileSize=5M # must be at least 5M
# was: TraceFileSize=1M

##############

CellDuplicateMode=0
ServiceModelDirectFeed=Yes
ServiceModelPublish=Yes
POMEnabled=Yes
ServiceModelEnabled=Yes

Impact of cell type selection on the mcell.conf configuration file variables

The table below lists the values that your mmigrate cell type selection assigns to the ServiceModelEnabled and POMEnabled variables in the mcell.conf file.

Cell type impact on mcell.conf variables

Type switch

Cell type

POMEnabled

ServiceModelEnabled

-ae

EM

No

No

-as

SIM

No

Yes

-ap

PPM

Yes

Yes

To resolve the conflicts in the mmigrate process

Conflicts identified by the mmigrate utility are marked in the following way:

<<<<<<< your source file name
your definition
=======
BMC definition
>>>>>>> BMC source file name

For example, we have three files:

  • The ancestor KB has the following definition:

    MC_PUBLISH_DATA_CLASS : BMC_Application ISA BMC_ApplicationSystem
    DEFINES {
    ApplicationType : ApplicationType;
    };
    END
    
  • Your KB definition (yours):

    MC_PUBLISH_DATA_CLASS : BMC_Application ISA BMC_ApplicationSystem
    DEFINES {
    ApplicationType : ApplicationType;
    ApplicationEntityName : STRING;
    };
    END
    
  • My KB definition (mine):

    MC_PUBLISH_DATA_CLASS : BMC_Application ISA BMC_ApplicationSystem
    DEFINES {
    ApplicationType : ApplicationType;
    ApplicationInstanceCount : INTEGER;
    };
    END
    

The conflict will appear in the merged file as shown in the following example:

MC_PUBLISH_DATA_CLASS : BMC_Application ISA BMC_ApplicationSystem
DEFINES {
ApplicationType : ApplicationType;
<<<<<<< yours
ApplicationEntityName : STRING;
=======
ApplicationInstanceCount : INTEGER;
>>>>>>> mine
};
END

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.

To merge .load files (applicable only to version 11.3.01)

When you plan to upgrade from TrueSight Infrastructure Management version 10.7 or 11.0 to 11.3.01, and run the mmigrate utility to migrate the data, the utility merges the content from the <customer KB> .load files and <latest KB> .load files in the <merged KB.load files in the following order:

  1. Standard files are placed in the same order as in the latest KB files
  2. Customer files are placed in the same order as the customer KB.load files

Note: The .load files must have the entries of all the <customer KB> source files that you want the mmigrate utility to merge in the new output directory.

To merge .load files (applicable to version 11.3.02 and later)

When you upgrade from TrueSight Infrastructure Management version 10.7, 11.0, or 11.3.01 to 11.3.02, and run the mmigrate utility to migrate the data, the utility merges the content from the <customer KB> .load files and <latest KB> .load files to the <merged KB> .load files as explained in the following section:

Limitation when you upgrade from a version earlier to TrueSight Infrastructure Management 10.7

However, if you upgrade from an earlier version of TrueSight Infrastructure Management 10.7, the .load sequencing may produce results with some deviations. In such scenarios, the mmigrate utility ignores the <customer KB> version and assigns a version to the <customer KB> files based on its ancestor KB details. 

  1. Sequence of all the customized files added in <customer KB> .load files will be retained as is in the newly created <merged KB> .load files.
  2. Sequence of the newly added files in <latest KB> .load files will be retained as is in the <merged KB> .load files.
  3. In case of a conflict, for example, the <customer KB>.load files and <latest KB>.load files have unique entries at same position in their respective .load files, priority will be given to newly added entry in the <latest KB> .load files.

Note: The .load files must have entries of all the <customer KB> source files that you want the mmigrate utility to merge in the new output directory.

The following table explains .load file sequencing with examples:

ExampleDescription<customer KB>.load<latest KB>.load<merged KB>.load
1
  • The <customer KB>.load file has some new entries as shown below that are not present in the <latest KB>.load file:
    • csg_ux_volume
    • csg_ux_alert
  • The <latest KB>.load file has a new entry sdig_poller_timestamp that is not present in the <customer KB>.load file

outage_policy
csg_ux_volume
csg_ux_alert
ibrsd_ci_incidentinfo
ibrsd_sm_incident
ctm_event

outage_policy
ibrsd_ci_incidentinfo
sdig_poller_timestamp
ibrsd_sm_incident
ctm_event

outage_policy

csg_ux_volume
csg_ux_alert
ibrsd_ci_incidentinfo

#Added by the latest KB
sdig_poller_timestamp
ibrsd_sm_incident
ctm_event

2

The <customer KB>.load file and the <latest KB>.load files have unique entries at the same position.

outage_policy
csg_ux_volume
csg_ux_alert
ibrsd_ci_incidentinfo
ibrsd_sm_incident
ctm_event

outage_policy
sdig_poller_timestamp
ibrsd_ci_incidentinfo
ibrsd_sm_incident
ctm_event

outage_policy

# added by latest KB
sdig_poller_timestamp
csg_ux_volume
csg_ux_alert
ibrsd_ci_incidentinfo
ibrsd_sm_incident
ctm_event

3

The <customer KB>.load file has an entry (for example, outage_policy) that is deleted in the <latest KB>.load file.


outage_policy
csg_ux_volume
csg_ux_alert
ibrsd_ci_incidentinfo
ibrsd_sm_incident
ctm_event

ibrsd_ci_incidentinfo
ibrsd_sm_incident
ctm_event

csg_ux_volume

csg_ux_alert
ibrsd_ci_incidentinfo
ibrsd_sm_incident
ctm_event

# deprecated by latest KB

#outage_policy


About mcsnmptrapdmibe, mcsnmptrapdmib, euem_refine files:

Following are the .load files related to SNMP Adapter configuration:

  • mcsnmptrapdmibe, mcsnmptrapdmibe (classes.load)
  • euem_collectors (collectors.load)
  • euem_refine (rules.load)

Following are a few exceptions while merging these SNMP related .load files:

  • If the <customer KB> has the above SNMP related file entries in the .load files, these files will be retained as is in the <merged KB>.load files.
  • If the <customer KB> doesn't have the above SNMP related file entries in the .load files, and if you want to configure the SNMP adapter, ensure that you list these files manually in their respective .load files.
Was this page helpful? Yes No Submitting... Thank you

Comments