Contents

1   Introduction

This document describes how to manage the Core Middleware (MW) component.

1.1   Prerequisites

This section describes the prerequisites, which must be fulfilled before using these procedures.

1.1.1   Conditions

The following conditions must apply:

• The system is ready to accept logon attempts from users.
• Commands are run as root user or prefixed with sudo and run by users belonging to group system-adm. The sudo configuration enforces the user to provide the password before execution of the command. Any exceptions to this are detailed in the relevant sections.

2   Core MW Command Overview

After successful logon the commands shown in Table 1 are available to root user or to user belonging to group system-adm and prefixed by sudo.

Note:  

The exact output from any command can differ depending on the release. Command completions can be used.

Command argument completion can be used if the OS supports it and bash shell is used.

In addition to what is listed in Table 1, all commands have a --help attribute.

Core MW has introduced interference checks and locking between a number of commands to minimize the risk that parallel execution disrupts the system. The following areas are included:

• Campaign execution
• Backup
• Resize of Core MW

The interference locking assures that it is only possible to execute one of these commands at the same time.

2.1   Deprecated Commands

The deprecated commands are listed in Table 2.

Deprecated command options are listed in Table 3.

3   Administrative Operations

All commands in this section are to be run as root user.

All commands except those for "Configuring IMM Access Control" can be prefixed with sudo and run by users belonging group system-adm.

This section describes the following administrative operations:

• Rebooting cluster
• Rebooting node
• Locking node
• Unlocking node
• Verifying system status
• Saving IMM data
• Getting AMF node of given hostname
• Getting hostname of given AMF node
• Configuring IMM Access Control
• Enabling or disabling Core MW features
• Setting time-out for Core MW scaling feature
• Clearing alarm issued by AMF

3.1   Reboot Cluster

To reboot the cluster in an ordered way, use the following command:

cmw-cluster-reboot [--no-rapid-reboot] [--yes]

If --no-rapid-reboot is specified, the cluster reboots using a regular mechanism instead of using kexec to facilitate fast rebooting as usual.

If --yes is specified, the command does not require confirmation.

SC-1:~ # cmw-cluster-reboot
Really want to reboot the entire cluster (yes/no)? yes
Rebooting all nodes
Stopping DHCP daemon on node 2 (SC-2)
Stopping DHCP daemon ..done
Stopping DHCP daemon on node 1 (SC-1)
Stopping DHCP daemon ..done
Rebooting node 4 (PL-4)
Rebooting node 3 (PL-3)
Waiting for payload nodes to shut down
Payload nodes have shut down
Rebooting node 2 (SC-2)
Rebooting node 1 (SC-1)

Broadcast message from root (pts/0) (Mon Jul  5 13:07:36 2010):

The system is going down for reboot NOW!
SC-1:~ #

3.2   Reboot Node

To reboot a single node, use the following command:

cmw-node-reboot [<hostname>]

If no hostname is specified, the current node is rebooted.

Note:  

This command is normally not used, but can be necessary to recover from transient error situations on a node that cannot be resolved using procedures with less system impact.

SC-1:~ # cmw-node-reboot PL-4
Rebooting node 4 (PL-4)
SC-1:~ #

3.3   Lock Node

To lock an AMF node, that is, to set its administrative state to LOCKED, use the following command:

cmw-node-lock <hostname> [-t <timeout> | --timeout <timeout>]

All Service Units (SUs) hosted on the node are prohibited from providing service.

To set the time-out in seconds, use the utility timeout command:

-t, --timeout <seconds>

If time-out is not specified, the default time-out of 900 seconds is used.

Note:  

The affected workload is redistributed according to the AMF redundancy model of the application.

SC-1:~ # cmw-node-lock PL-4
SC-1:~ #

3.4   Unlock Node

To unlock an AMF node, that is, to set its administrative state to UNLOCKED, use the following command:

cmw-node-unlock <hostname> [-t <timeout> | --timeout <timeout>]

All SUs hosted on the node are administratively allowed to provide service.

To set the time-out in seconds, use the utility timeout command:

-t, --timeout <seconds>

If time-out is not specified, the default time-out of 900 seconds is used.

SC-1:~ # cmw-node-unlock PL-4
SC-1:~ #

3.5   Verify System Status

To verify that the system status is normal, check the status of the following system items with the following command:

cmw-status [-v] <class-name> [<class-name>...]

When the system is in normal status, the output can look as shown in Example 5.

SC-1:~ # cmw-status node comp su
Status OK
SC-1:~ #

When verifying system status the primary class names to specify are su, node, and comp. If the si class name is specified, PARTIALLY_ASSIGNED can be returned even if there is no fault in the system.

On a single node cluster (1 + 0 configuration), the output can look as shown in Example 6.

SC-1:~ # cmw-status si
Status OK
SC-1:~ # 

In verbose mode on a single node cluster (1 + 0 configuration) the output can look as shown in Example 7.

SC-1:~ # cmw-status -v si
safSi=SC-2N,safApp=OpenSAF
  AdminState=UNLOCKED(1)
  AssignmentState=PARTIALLY_ASSIGNED(3)
safSi=SC-2N,safApp=ERIC-CoreMW
  AdminState=UNLOCKED(1)
  AssignmentState=PARTIALLY_ASSIGNED(3)
SC-1:~ #

SC-1:~ # cmw-status node
safAmfNode=PL-3,safAmfCluster=myAmfCluster
AdminState=LOCKED-INSTANTIATION(3)
OperState=ENABLED(1)
SC-1:~ # 

SC-1:~ # cmw-status -v node
safAmfNode=SC-2,safAmfCluster=myAmfCluster
        AdminState=UNLOCKED(1)
        OperState=ENABLED(1)
safAmfNode=SC-1,safAmfCluster=myAmfCluster
        AdminState=UNLOCKED(1)
        OperState=ENABLED(1)
safAmfNode=PL-4,safAmfCluster=myAmfCluster
        AdminState=UNLOCKED(1)
        OperState=ENABLED(1)
safAmfNode=PL-3,safAmfCluster=myAmfCluster
        AdminState=UNLOCKED(1)
        OperState=ENABLED(1)
SC-1:~ #

SC-1:~ # cmw-status pm
pmJobId=TC-CMW-PM-CMD-STATUS-1, Stopped
SC-1:~ #

SC-1:~ # cmw-status -v pm
Name                   Value(s)
========================================
pmJobId                TC-CMW-PM-CMD-STATUS-1
jobType                Measurement(0x1)
granularityPeriod      1 minute(0x3)
reportingPeriod        1 minute(0x3)
jobPriority            High(0x3)
requestedJobState      Stopped(0x2)
currentJobState        Stopped(0x2)
Overall Job State      Stopped(0x2)
Name                   Value(s)
========================================
pmJobId                TC-CMW-PM-CMD-STATUS-2
jobType                Threshold(0x2)
granularityPeriod      5 minutes(0x4)
reportingPeriod        15 minutes(0x5)
jobPriority            Medium(0x2)
requestedJobState      Active(0x1)
currentJobState        Active(0x1)
Overall Job State      Active(0x1)
SC-1:~ #

3.6   Save IMM Data

The IMM data is automatically persisted incrementally for every Configuration Change Bundle (CCB) and persistent runtime object create/ update/ delete operation. During campaign execution, the persistency is disabled and then enabled again when the campaign reaches the completed state, that is, before commit is done.

3.7   Get AMF Node of Given Hostname

To get the AMF node of a given hostname, use the following command:

cmw-amfnode-get <hostname>

SC-1:~ # cmw-amfnode-get SC-1
SC-1
SC-1:~ #

3.8   Get Hostname of Given AMF Node

To get the hostname of a given AMF node, use the following command:

cmw-hostname-get <amfnode>

SC-1:~ # cmw-hostname-get SC-1
SC-1
SC-1:~ #

3.9   Configure IMM Access Control

To configure IMM Access Control, use the following command:

cmw-imm—policy-set <enforced | disabled | permissive>

For compatibility reasons, the default setting of IMM Access Control is DISABLED.

By setting IMM Access Control to ENFORCED, the IMM users wanting to access IMM must belong to the cmw-imm-users group. For more information, refer to Section Information Model Management Service in Core MW System Architecture Description.

Note:  

PERMISSIVE logs all violations to system logs without enforcing access control. Must be used with caution, as it can introduce unwanted spam in the system logs.

3.10   Enable or Disable Core MW Features

To enable, disable, or check status of Core MW features, use the following command:

cmw-configuration <--enable | --disable | --status> <feature> [--reboot]

The parameters are as follows:

• --enable – Enable <feature> on all nodes.
• --disable – Disable <feature> on all nodes.
• --status – Check status of <feature> (enable/disable).
• --reboot – Force cluster reboot immediately to enable or disable <feature> on all nodes. A cluster reboot is needed to enable or disable some features. Information about this can be found in the description of each feature.

The FENCING feature supports the following additional parameters:

• --test – Test specified Fencing plug-in and parameters.
• --plugin <plug-in name> – Specify plug-in for the FENCING feature.
• --set <amfNodeName> – Set amfNodeName for the FENCING feature.
• --list – List available plug-ins for the FENCING feature.

The following features are supported:

• TIPC_MULTICAST
• SC_ABSENCE_ALLOWED
• SCALING
• ISP_REPORT
• ONE_STEP_UPGRADE – Deprecated
• PM_REPORTALWAYS
• ME_NAME
• FENCING

3.10.1   TIPC Multicast Feature

The Message Distribution Service (MDS) broadcasts are implemented using unicast, which adds load and does not scale on larger clusters. The Transparent Inter-Process Communication (TIPC) multicast feature solves this issue, deleting these performance impacts.

Before enabling the TIPC Multicast feature in Core MW, the user must verify that the current TIPC driver fully supports that feature.

Note:  

A cluster reboot is required for this action to take effect. An immediate cluster reboot can be triggered with parameter --reboot.

If the TIPC Multicast feature is already enabled, then after a Core MW upgrade it stays enabled and if it is disabled, it stays disabled.

How to enable the TIPC Multicast feature is shown in Example 14 with forced reboot, and in Example 15 without forced reboot.

SC-1:~ # cmw-configuration --enable TIPC_MULTICAST --reboot
Rebooting cluster ...

SC-1:~ # cmw-configuration --enable TIPC_MULTICAST
Cluster reboot is required for change to take effect

If the TIPC Multicast feature is already enabled, the output is as shown in Example 16.

SC-1:~ # cmw-configuration --enable TIPC_MULTICAST --reboot
Already enable

SC-1:~ # cmw-configuration --status TIPC_MULTICAST
Enable

3.10.2   SC Absence Feature

The System Controller (SC) Absence feature ensures that the cluster does not reboot while both SC nodes are down, allowing the payload to work with limited service. If the time taken for the SC nodes to recover exceeds a timeout value, all payload nodes shut down (current behavior).

Before enabling the SC Absence feature in Core MW, the user must verify that the system fully supports this feature.

Note:  

A cluster reboot is required for this action to take effect. An immediate cluster reboot can be triggered with parameter --reboot.

timeout is an optional argument for the cmw-configuration command. By default, timeout has the same value as the maximum timeout (900 seconds).

If the SC Absence feature is already enabled, then after a Core MW upgrade it stays enabled and if it is disabled, it stays disabled.

Example 18 and Example 19 are common examples to provide more information.

SC-1:~ # cmw-configuration --enable SC_ABSENCE_ALLOWED 300 --reboot
Rebooting cluster ...

SC-1:~ # cmw-configuration --disable SC_ABSENCE_ALLOWED
Cluster reboot is required for change to take effect

When the status of the SC Absence feature is checked, the timeout value is also shown. The result of checking the feature is shown in Example 20.

SC-1:~ # cmw-configuration --status SC_ABSENCE_ALLOWED
WARNING: Configuration has been changed but cluster reboot isn’t called
Enable
Current timeout is 300

3.10.3   Scaling Feature

When scaling is enabled, the system can automatically be expanded with newly detected nodes, using a default scaling profile. The Compute Resource Management (CRM) Northbound Interface (NBI) model allows the deletion of scalable nodes, which triggers a resize of the system. The scaling feature is enabled in runtime and does not require a reboot.

SC-1:~ # cmw-configuration --enable SCALING

Example 22 shows how to check the status of the scaling feature if it is already enabled.

SC-1:~ # cmw-configuration --status SCALING
Enable

SC-1:~ # cmw-configuration --disable SCALING

For more details about the scaling feature, refer to Core MW Cluster Manager Description.

3.10.4   In-Service Performance Report Feature

The ISP functionality collects ISP information that has been generated by Core MW and other components/applications (following the ISP API description, refer to ISP API Interface Description 1.1.0) and produces an XML file as output for processing by the ISP tool.

The support is as follows:

• Partial Outage reporting: partial outage events can be reported by applications or components following the specification in the ISP API. Reporting is done using the Log service.
• Network Element (NE) configuration change reporting: an upgrade/update event can be reported following the specification in the ISP API. Reporting is done using the Log service.
• ISP delivers the needed security rules to make ISP Log files visible over the NBI. These are accessed by the Automated Data Collection (ADC) tool to fetch and deliver them to the ISP tool.
• The ISP functionality keeps the XML report files for six months. Core MW automatically cleans the old ISP reports. This activity occurs once per month at the time of creation of output XML files.

Enabling/disabling the ISP report feature does not require reboot.

SC-2-1:~ # cmw-configuration --enable ISP_REPORT

SC-2-1:~ # cmw-configuration --status ISP_REPORT

SC-2-1:~ # cmw-configuration --disable ISP_REPORT

Note:  

It is highly recommended to enable ISP events for cluster restarts in the system, see Section 5.7 Configure ISP Events for Cluster Restarts. Otherwise cluster restart events are not visible in the ISP logs, not even on individual blade level.

3.10.5   One Step Upgrade Feature – Deprecated

The Software Management Framework (SMF) normally executes the procedures in a campaign in execution level order. When the One Step Upgrade feature is enabled, the SMF collects all actions calculated to be made by the originally written procedures into a new internal single-step procedure, which executes all upgrade actions in a single step. The originally written procedures in the campaign are not executed.

SC-1:~ # cmw-configuration --enable ONE_STEP_UPGRADE

Example 28 shows how to check the status of the One Step Upgrade feature if it is already enabled.

SC-1:~ # cmw-configuration --status ONE_STEP_UPGRADE
Enable

SC-1:~ # cmw-configuration --disable ONE_STEP_UPGRADE

3.10.6   PM_REPORTALWAYS Feature

The PM_REPORTALWAYS feature allows runtime configuration of the report file content generated for active PM Measurement jobs. It affects both existing and later created PM jobs. If the feature is enabled, report content is always generated in MISSING_MOIDS manner, independent of the reportContentGeneration attribute value of each PM job. If the feature is disabled, report content is generated according to the reportContentGeneration attribute value of each PM job.

This feature is disabled by default.

SC-1:~ # cmw-configuration --enable PM_REPORTALWAYS

SC-1:~ # cmw-configuration --disable PM_REPORTALWAYS

Example 32 shows how to check the status of the PM_REPORTALWAYS feature if it is already enabled.

SC-1:~ # cmw-configuration --status PM_REPORTALWAYS
Enable

3.10.7   Managed Element Network Name Feature

The ME_NAME feature allows the user to set a network name on the Managed Element (ME).

This feature is disabled by default.

SC-1:~ # cmw-configuration --enable ME_NAME Network1

SC-1:~ # cmw-configuration --disable ME_NAME

Example 35 shows how to check the status of the ME_NAME feature if it is already enabled.

DSC-1:~ # cmw-configuration --status ME_NAME
Disable

3.10.8   Fencing Feature

Remote Fencing (RF) allows components, applications, and integrators to substitute the generic remote fencing logic within Core MW with a remote fencing solution more suitable to the target cluster.

Before enabling this feature, the user must verify that the system fully supports the features implemented in the RF plug-in.

To view the status of the Fencing feature, use parameter --status as shown in Example 36 and Example 37.

SC-2-1:~ # cmw-configuration --status FENCING
Fencing : Disabled

SC-2-1:~ # cmw-configuration --status FENCING
Fencing : Enabled
Plugin Name : FENCING_STONITH-CXP9010009_1
Plugin Version : R3A20
Plugin Parameter: SC-2 SC-1

To view the available RF plug-ins that have been installed on the system, use parameter --list as shown in Example 38 and Example 39.

SC-2-1:~ # cmw-configuration --status FENCING --list
Fencing : Disabled
Plugin List :
FENCING_IPMI-CXP9010010_1

Example 39 shows the available RF plug-ins installed on the system and that the RF plug-in is enabled but a cluster reboot is required before configuration takes effect.

SC-2-1:~ # cmw-configuration --status FENCING --list
WARNING: Configuration has been changed but cluster reboot isn't called
Fencing : Enabled
Plugin Name : FENCING_STONITH-CXP9010009_1
Plugin Version : R3A20
Plugin Parameter: SC-1 SC-2
Plugin List :
FENCING_IPMI-CXP9010010_1
FENCING_STONITH-CXP9010009_1

To configure and enable an RF plug-in for SC-1 and SC-2, use parameters --enable, --plugin, and --set, as shown in Example 40 and Example 41.

Note:  

A cluster reboot is required for this action to take effect if the RF plug-in contains any OpenSAF variable configuration. Core MW detects this automatically and informs the user that reboot is required.

SC-2-1:~ # cmw-configuration --enable FENCING --reboot --plugin ⇒
FENCING_IPMICXP9010010_1 --set SC-1 --set SC-2
Rebooting cluster ...

Example 41 shows how to enable an RF plug-in with the user warned that cluster reboot is required for changes to take effect.

SC-2-1:~ # cmw-configuration --enable FENCING --plugin ⇒
FENCING_STONITH-CXP9010009_1 --set SC-1 --set SC-2
setlocale: No such file or directory
1075 FT-REG-70-SC-1 running
1076 FT-REG-70-PL-4 running
1077 FT-REG-70-PL-5 running
1078 FT-REG-70-PL-3 running
1079 FT-REG-70-SC-2 running
- FT-REG-70-gwhost701 shut off
setlocale: No such file or directory
1075 FT-REG-70-SC-1 running
1076 FT-REG-70-PL-4 running
1077 FT-REG-70-PL-5 running
1078 FT-REG-70-PL-3 running
1079 FT-REG-70-SC-2 running
- FT-REG-70-gwhost701 shut off
setlocale: No such file or directory
1075 FT-REG-70-SC-1 running
1076 FT-REG-70-PL-4 running
1077 FT-REG-70-PL-5 running
1078 FT-REG-70-PL-3 running
1079 FT-REG-70-SC-2 running
- FT-REG-70-gwhost701 shut off
setlocale: No such file or directory
1075 FT-REG-70-SC-1 running
1076 FT-REG-70-PL-4 running
1077 FT-REG-70-PL-5 running
1078 FT-REG-70-PL-3 running
1079 FT-REG-70-SC-2 running
- FT-REG-70-gwhost701 shut off
WARNING: Cluster reboot is required for change to take effect

Core MW performs checks on the RF plug-in before enabling it by calling the "verify" functionality of the plug-in. If any errors are detected in the RF plug-in itself, or the configured data for it, the user is alerted and further information can be found in the system logs. Example 42, Example 43, and Example 44 show some typical error use cases.

SC-2-1:~ # cmw-configuration --enable FENCING --reboot --plugin FENCING_IPMICXP9010010_1 ⇒
--set SC-1 --set SC-2
CMW: ERROR (cmw-configuration): Fencing Enable failed to verify (1)
SC-2-1:~ # less /var/log/messages
Oct 21 19:54:20 SC-2-1 FENCING_IPMI-CXP9010010_1: ERROR
(/storage/system/config/coremw/fencing/rf.FENCING_IPMI-CXP9010010_1): RFP_IPADDR,
RFP_USERID or RFP_PASSWD missing; check configuration
Oct 21 19:54:20 SC-2-1 FENCING_IPMI-CXP9010010_1: ERROR
(/storage/system/config/coremw/fencing/rf.FENCING_IPMI-CXP9010010_1): error executing
ipmitool:
Oct 21 19:54:20 SC-2-1 FENCING_IPMI-CXP9010010_1: ERROR
(/storage/system/config/coremw/fencing/rf.FENCING_IPMI-CXP9010010_1): Verify of
connection to IPMI failed
Oct 21 19:54:20 SC-2-1 CMW: Fencing plugin failed (1) on SC-1
Oct 21 19:54:20 SC-2-1 CMW: ERROR (cmw-configuration): Fencing Enable failed to
verify (1)

SC-2-1:~ # cmw-configuration --enable FENCING --reboot --plugin FENCING_STONITHCXP9010009_1 ⇒
--set SC-1 --set SC-2
CMW: ERROR (cmw-configuration): Fencing Enable failed to verify (1)
SC-2-1:~ # less /var/log/messages
Oct 21 20:02:56 SC-2-1 FENCING_STONITH-CXP9010009_1: ERROR
(/storage/system/config/coremw/fencing/rf.FENCING_STONITH-CXP9010009_1):
TARGET_PLUGIN (/cluster/home/fencingtest/target.FENCING_STONITH-CXP9010009_1-R3A20)
not readable
Oct 21 20:02:56 SC-2-1 CMW: Fencing plugin failed (1) on SC-1
Oct 21 20:02:56 SC-2-1 CMW: ERROR (cmw-configuration): Fencing Enable failed to
verify (1)

SC-2-1:~ # cmw-configuration --enable FENCING --plugin FENCING_STONITH-CXP9010009_1 ⇒
--set SC-1 --set SC-2
CMW: ERROR (cmw-configuration): Fencing Enable failed to verify (1)
SC-2-1:~ # less /var/log/messages
Oct 21 20:07:20 SC-2-1 external/libvirt[14655]: ERROR: Failed to get status for
qemu+tcp://172.16.83.51?name=qemu:///system
Oct 21 20:07:20 SC-2-1 external/libvirt[14655]: ERROR: setlocale: No such file or
directory#012error: unexpected data 'version'
Oct 21 20:07:21 SC-2-1 stonith: external_status: 'libvirt status' failed with rc 1
Oct 21 20:07:21 SC-2-1 stonith: external/libvirt device not accessible.
Oct 21 20:07:21 SC-2-1 FENCING_STONITH-CXP9010009_1: ERROR
(/storage/system/config/coremw/fencing/rf.FENCING_STONITH-CXP9010009_1): Verify of
stonith and libvirt via stonith failed, rc: 1
Oct 21 20:07:21 SC-2-1 CMW: Fencing plugin failed (1) on SC-1
Oct 21 20:07:21 SC-2-1 CMW: ERROR (cmw-configuration): Fencing Enable failed to
verify (1)

The user can invoke the "verify" functionality of an RF plug-in (irrespective of whether enabled or not) by entering the cmw-configuration command with parameter --test, as shown in Example 45.

SC-2-1:~ # cmw-configuration --test FENCING --plugin FENCING_STONITH-CXP9010009_1 --set SC-1
setlocale: No such file or directory
1075 FT-REG-70-SC-1 running
1076 FT-REG-70-PL-4 running
1077 FT-REG-70-PL-5 running
1078 FT-REG-70-PL-3 running
1079 FT-REG-70-SC-2 running
- FT-REG-70-gwhost701 shut off
SC-2-1:~ # echo $?
0

3.11   Set Time-Out for Core MW Scaling Feature

To set time-out for scaling batch, node join, and parallel shutdown of Core MW scaling features, use the following command:

cmw-timeout-configuration [--list | --set <timeout> <value>]

The parameters are as follows:

• --list – View the value of these time-outs.
• --set – Set a value to these time-outs through arguments SCALING_BATCH, SCALING_JOIN, and SCALING_SHUTDOWN.

SC-1:~ # cmw-timeout-configuration --set SCALING_JOIN 120

3.12   Clear Alarm Issued by AMF

To clear an alarm issued by AMF, use the following command:

cmw-alarm-clear [-v] <alarm-type> <managed-object>

SC-1:~ # cmw-alarm-clear instantiation ManagedElement=1,⇒
SaAmfApplication.safApp=ERIC-CoreMW,SaAmfSG.safSg=2N,⇒
SaAmfSU.safSu=SC-1,SaAmfComp.safComp=EcimSwm

4   Core MW Partial Backup and Partial Restore – Deprecated

Note:  

This section and all its subsections contain information that is deprecated since Core MW R6A.

When the scaling feature is enabled, all the following mentioned Core MW partial backup commands are disabled.

This section describes the following partial backup and partial restore operations:

• Creating Core MW partial backup
• Listing Core MW partial backups
• Deleting Core MW partial backup
• Restoring using Core MW partial backup

A Core MW partial backup contains a snapshot of files for Core MW, which represents the system state of Core MW. The scope of a Core MW partial backup can be extended if application programs register application-specific backup commands. The partial backup mainly acts as a driver of backup where the OS and the applications keep their backup files on their own.

The Core MW partial backup can usually be used to restore a system, but as it does not contain all files it cannot be used for restoring the system after a catastrophic event.

Core MW supports integration of custom backup manager frameworks. If a custom backup manager is registered, the responsibility for backup and restore is transferred to the backup manager. The cmw-partial-backup-create and cmw-partial-backup-register commands are disabled and returns non-zero error codes when executed.

4.1   Create Core MW Partial Backup – Deprecated

To create a Core MW partial backup, use the following command:

cmw-partial-backup-create [--verbose] <label>

A partial backup with the specified label is created.

The label can be a maximum of 128 characters and can only contain characters that are valid in a Linux® filename.

The partial backup is physically divided in multiple archives files. The partial backup covers the following areas:

• Host OS
• Core MW
• Software bundles and campaigns imported to Core MW repository
• Data provided by registered application backup commands

SC-1:~ # cmw-partial-backup-create mgmtug-example
Snapshot starting (/cluster/snapshot/.cmwea-snapshot-mgmtug-example.tar.gz)
Snapshot completed
SC-1:~ #

4.2   List Core MW Partial Backups – Deprecated

To list the labels of the created partial backups, use the following command:

cmw-partial-backup-list

Only the labels of the complete partial backups are listed. For incomplete labels of partial backups, a warning message is printed.

SC-1:~ # cmw-partial-backup-list
1st-CMW
mgmtug-example
SMF-BACKUP_2010-07-05T12:48:08
SMF-BACKUP_2010-07-05T12:58:56
SC-1:~ #

4.3   Delete Core MW Partial Backup – Deprecated

To delete a previously created partial backup, use the following command:

cmw-partial-backup-remove [--verbose] <label>

SC-1:~ # cmw-partial-backup-remove mgmtug-example
SC-1:~ # 

4.4   Restore Using Core MW Partial Backup – Deprecated

To restore the system from a previously created partial backup, use the following commands:

cmw-partial-backup-restore [--verbose] <label>

cmw-cluster-reboot --yes

The partial backup must be activated by rebooting the cluster, see Section 3.1 Reboot Cluster.

SC-1 # cmw-partial-backup-restore mgmtug-example
Restore the Host OS ...
Snapshot restore starting (/cluster/snapshot/cmwea-snapshot-mgmtug-example.tar.gz)
Snapshot restore completed
Starting RPM synchronization of node 1
Synchronizing linux-control-R1A03-PRE1.x86_64.rpm
Synchronizing ⇒
COREMW_COMMON-R1A-72.x86_64.716a0b126ae0b34d2f841e5cd3c539e3.rpm
Synchronizing ⇒
coremw-opensaf-4.0-R1A01.x86_64.09ade38a707f803470fdfc58d92f5434.rpm
Synchronizing ⇒
opensaf-amf-libs-4.0.RC1-R1A01.1580.4.x86_64.a8774057970069565b178c62002b893f.rpm
Synchronizing ⇒
opensaf-amf-nodedirector-4.0.RC1-R1A01.1580.4.x86_64.a772b062ed3638ac48a59e8bfd30e2db.rpm
Synchronizing ⇒
opensaf-ckpt-libs-4.0.RC1-R1A01.1580.4.x86_64.b40335b7cfa2f3592f08246fad13844c.rpm
Synchronizing ⇒
opensaf-ckpt-nodedirector-4.0.RC1-R1A01.1580.4.x86_64.14866c4e3fbe964cda83e97d673b7447.rpm
Synchronizing ⇒
opensaf-clm-libs-4.0.RC1-R1A01.1580.4.x86_64.1574c1c5e29562731573eb045d45d520.rpm
Synchronizing ⇒
opensaf-clm-nodeagent-4.0.RC1-R1A01.1580.4.x86_64.b7c8544f5dd86d7d33e5b8575ae3fe00.rpm
Synchronizing ⇒
opensaf-imm-libs-4.0.RC1-R1A01.1580.4.x86_64.59f8198c1ccbcd5ef6f21e464e19b4a9.rpm
Synchronizing ⇒
opensaf-imm-nodedirector-4.0.RC1-R1A01.1580.4.x86_64.769e124e417a0711c4dd4771a48a3c26.rpm
Synchronizing ⇒
opensaf-libs-4.0.RC1-R1A01.1580.4.x86_64.e23173b8021f50927f1328a299f793f4.rpm
Synchronizing ⇒
opensaf-log-libs-4.0.RC1-R1A01.1580.4.x86_64.2fbc9be1867d7c307351aeb5ebba9425.rpm
Synchronizing ⇒
opensaf-ntf-libs-4.0.RC1-R1A01.1580.4.x86_64.ded91cefd458156125bed888782afe73.rpm
Synchronizing ⇒
opensaf-smf-libs-4.0.RC1-R1A01.1580.4.x86_64.11a6b0cad1300999bf9dfa8ce4bef3d6.rpm
Synchronizing ⇒
opensaf-smf-nodedirector-4.0.RC1-R1A01.1580.4.x86_64.cf8cce9975734cf5d0324a24c1565ff1.rpm
Synchronizing ⇒
opensaf-4.0.RC1-R1A01.1580.4.x86_64.77e4dc0c1c15c20cac63097935f54cfd.rpm
Synchronizing ⇒
opensaf-amf-director-4.0.RC1-R1A01.1580.4.x86_64.a79972ce3e15bf7c307526459e00349f.rpm
Synchronizing ⇒
opensaf-ckpt-director-4.0.RC1-R1A01.1580.4.x86_64.6f6c5eaf5f6b413b4c4b88fbb65ef9b4.rpm
Synchronizing ⇒
opensaf-clm-server-4.0.RC1-R1A01.1580.4.x86_64.fa5baf4a1fa773e50037bb7afc5c679f.rpm
Synchronizing ⇒
opensaf-controller-4.0.RC1-R1A01.1580.4.x86_64.ba49b887419f2c4753f4fda58024f758.rpm
Synchronizing ⇒
opensaf-imm-director-4.0.RC1-R1A01.1580.4.x86_64.41b0fb79df6fd3fa25076aa43b291fce.rpm
Synchronizing ⇒
opensaf-log-server-4.0.RC1-R1A01.1580.4.x86_64.308b7372726cb676e9e51da7d4dbca45.rpm
Synchronizing ⇒
opensaf-ntf-server-4.0.RC1-R1A01.1580.4.x86_64.932bfbc668a973b6941054e99416988f.rpm
Synchronizing ⇒
opensaf-smf-director-4.0.RC1-R1A01.1580.4.x86_64.50ec99d3b2b0a6a3fafdbec9257d5b43.rpm
Synchronizing ⇒
COREMW_SC-R1A-53.x86_64.679a7116d9d5a9758c0c8f081c99ed5b.rpm
Completed RPM synchronization of node 1
......
Completed RPM synchronization of node 9
Unpack the Core MW backup ...
Restore application data [backup-ERIC-Vip-CXP9013048_4-R1A03] ...
SC-1 # cmw-cluster-reboot --yes 

5   Software Management

This section describes the following software management tasks:

• Importing software bundles and campaigns
• Deleting software bundles and campaigns
• Reading from software inventory
• Using SMF campaigns
• Configuring ECIM SWM
• Using CLI for upgrade package/CSP
• Configuring ISP events for cluster restarts
• Configuring reboot behavior of single-step procedures
• Configuring remote fencing parameters

Commands are to be run as root user or prefixed with sudo and run by a user belonging to the system-adm group.

5.1   Import Software Bundles and Campaigns

To import software bundles or campaigns to the repository, use the following command:

cmw-sdp-import <file> [<file>...]

The possible formats are the following:

• Bundle Software Delivery Package (SDP)
• Campaign SDP
• Bundle RPM

Note:  

Different file formats can be mixed in the command.

The names of successfully imported software bundles and campaigns are printed.

# cmw-sdp-import /home/MyApp/incoming/TestApp.sdp ⇒
/home/MyApp/incoming/TestAppInstall.sdp
ERIC-TestApp-CXP12345-R1A01 imported (type=Bundle)
ERIC-InstallTestApp imported (type=Campaign)
#

A third party product (3PP) software import in bundle RPM format is shown in Example 53.

# cmw-sdp-import MySQL-server-community-5.1.61-1.sles11.x86_64.rpm
3PP-MySQL-server-community-5.1.61-1.sles11 imported (type=Bundle)
#

5.2   Delete Software Bundles and Campaigns

To delete software bundles and campaigns from the repository, use the following command:

cmw-sdp-remove <name> [<name>...]

The possible formats are the following:

• Bundle SDP
• Campaign SDP
• Bundle RPM

Note:  

Different formats can be mixed in the command.

# cmw-sdp-remove ERIC-TestApp-CXP12345-R1A01 ERIC-InstallTestApp
Bundle SDP removed [ERIC-TestApp-CXP12345-R1A01]
Campaign SDP removed [ERIC-InstallTestApp]
#

Note:  

Deleting already deleted software bundles or campaign SDPs is not considered an error.

sc-1:~ # cmw-sdp-remove 3PP-MySQL-server-community-5.1.61-1.sles11
Bundle SDP removed [3PP-MySQL-server-community-5.1.61-1.sles11]
sc-1:~ #

5.3   Read from Software Inventory

To list the imported campaigns, use the following command:

cmw-repository-list --campaign

SC-1 # cmw-repository-list --campaign
ERIC-InstallTestApp
SC-1 #

To list the imported software bundles and if they are used or not in the system, use the following command:

cmw-repository-list

A list of imported software bundles and if they are used or not in the system is shown in Example 57.

sc-1:~ # cmw-repository-list
ERIC-COREMW_COMMON-CXP9017566_1-P1A34        Used
ERIC-COREMW_SC-CXP9017565_1-P1A31            Used
ERIC-COREMW_OPENSAF-CXP9017656_1-P1A26       Used
3PP-MySQL-server-community-5.1.61-1.sles11   Used
sc-1:~ #

The first column shows the name of the software bundle and the second column states whether the software bundle is used, without specifying the node.

To list all software bundles installed per node, use the following command:

cmw-repository-list --node [<hostname>...]

If hostname is not used, the output looks as in Example 58.

SC-1:~ # cmw-repository-list --node
PL-3 ERIC-COREMW_COMMON-CXP9017566_1-P1C72
PL-3 ERIC-COREMW_OPENSAF-CXP9017656_1-R1A01
PL-4 ERIC-COREMW_COMMON-CXP9017566_1-P1C72
PL-4 ERIC-COREMW_OPENSAF-CXP9017656_1-R1A01
SC-1 ERIC-COREMW_COMMON-CXP9017566_1-P1C72
SC-1 ERIC-COREMW_OPENSAF-CXP9017656_1-R1A01
SC-1 ERIC-COREMW_SC-CXP9017565_1-P1C53
SC-1 3PP-MySQL-server-community-5.1.61-1.sles11
SC-2 ERIC-COREMW_COMMON-CXP9017566_1-P1C72
SC-2 ERIC-COREMW_OPENSAF-CXP9017656_1-R1A01
SC-2 ERIC-COREMW_SC-CXP9017565_1-P1C53
SC-2 3PP-MySQL-server-community-5.1.61-1.sles11
SC-1:~ #

5.4   Use SMF Campaigns

All kinds of software reconfiguration such as installation, upgrade, and deletion are done with a campaign.

A campaign is contained and delivered in an SDP. To make the campaign available to Core MW, the campaign SDP is imported using the cmw-sdp-import command. For more information about this command, see Section 5.1 Import Software Bundles and Campaigns.

To list imported campaigns, usi the following command:

cmw-repository-list --campaign

For more information about the command, see Section 5.3 Read from Software Inventory.

The software reconfiguration specified in a campaign.xml file is executed by SMF. SMF implements a state machine that interprets the XML file and executes the software reconfiguration.

The transitions between SMF states depending on Core MW commands are shown in Figure 1.

5.4.1   Execute an SMF Campaign

Ensure that the units (node, SU, component, and so on) are affected by the campaign and that they are free of faults before executing.

To execute a campaign:

1. Get a list of the installed campaigns:

   cmw-repository-list --campaign

2. Start an SMF campaign:

   cmw-campaign-start <campaign-name>

   If the SMF campaign is a template, the first step performed is that the campaign is updated with information fetched from the system. Any error that occurs during campaign update and validation results in an error message and the campaign execution is not started. If this occurs, a new campaign SDP must be provided, but no other measures are needed.

   If more than one campaign is executed in sequence, the optional parameter --disable-backup can be used to inhibit backups during campaign execution. However, when the first campaign is started, a backup is recommended and the optional parameter must not be used.

   Note:  

   Execution of a new campaign cannot be started until the previous campaign is committed.

   
   
3. Verify that the campaign status has state COMPLETED:

   cmw-campaign-status <campaign-name>

   If SMF detects that a campaign cannot be initiated, the initial transition is Cannot_initiate and the state remains Initial. The Cannot_initiate transition can be caused by an invalid campaign file, or a campaign that executes already. Once executing, the campaign can either be successful or it can fail.

   Note:  

   As one of the first steps of campaign execution a backup is taken. A failed campaign requires that the system is restored from a backup, during which there is a service outage.

   
   

   The backup is labeled according to the following syntax:

   SMF-BACKUP_YYYY-MM-DDTHH:MM:SS

   Examples:

   SMF-BACKUP_2010-07-05T12:48:08 SMF-BACKUP_2010-07-05T12:58:56

   Depending on the state, take different actions, as follows:

   State	Action
   INITIAL without error	Retry status command.
   INITIAL with error	Contact the campaign provider.
   EXECUTING	Retry status command.
   ERROR_DETECTED	Retry status command.
   SUSPENDED_BY_ERROR_DETECTED	Start or rollback.
   COMPLETED	Proceed with commit step.
   FAILED	Initiate a fallback by restoring and restarting the cluster, see Section 4.4 Restore Using Core MW Partial Backup – Deprecated.

4. Verify the status of the cluster, see Section 3.5 Verify System Status.

   If the status is OK, continue with the next step, otherwise repeat the status check.

5. Commit the campaign, if it executed successfully:

   cmw-campaign-commit <campaign-name>

6. Verify that the campaign status is COMMITTED:

   cmw-campaign-status <campaign-name>

   It can take some time before the campaign is committed. Repeat the command until the campaign status is COMMITTED.

5.4.2   Roll Back a Campaign

To roll back a campaign:

1. Stop the executing campaign, if the campaign is executing:

   cmw-campaign-stop <campaign-name>

2. Roll back the campaign:

   cmw-campaign-rollback <campaign-name>

3. Verify that the campaign status is ROLLBACK COMPLETED:

   cmw-campaign-status <campaign-name>

   If the campaign status is ROLLBACK COMPLETED, continue with the next step.

   If the campaign status is ROLLBACK FAILED, initiate a fallback by restoring and restarting the cluster, see Section 4.4 Restore Using Core MW Partial Backup – Deprecated.

4. Commit the campaign, if it rolled back successfully:

   cmw-campaign-commit <campaign-name>

5. Verify that the campaign status is ROLLBACK_COMMITTED:

   cmw-campaign-status <campaign-name>

   It can take some time before the campaign is committed. Repeat the command until the campaign status is ROLLBACK_COMMITTED.

5.4.3   Add Software

Applications are installed using a campaign. The application is contained in one or more software bundles and the installation campaign in an SDP. The installation campaign is target system size specific.

To install an application using a campaign:

1. Copy the installation campaign SDP and the software bundles to a location at the target system, for example:

   /home/MyAppl/incoming

2. Import all campaign SDPs and software bundles:

   cmw-sdp-import /home/MyApp/incoming/<installation-campaign-filename>

   cmw-sdp-import /home/MyApp/incoming/<application-filename>

3. Execute the installation campaign, see Section 5.4.1 Execute an SMF Campaign.
4. Delete the installation campaign SDP:

   cmw-sdp-remove <installation-campaign>

5.4.4   Upgrade Software

Any software delivered as a software bundle is upgraded using a campaign. The new version of the software is contained in a software bundle and the upgrade campaign in a campaign SDP.

To upgrade software using a campaign:

1. Copy the campaign SDP and the software bundles to a location at the target system, for example:

   /home/MyAppl/incoming

2. Import all campaign SDPs and software bundles:

   cmw-sdp-import /home/MyApp/incoming/<upgrade-campaign-filename>

   cmw-sdp-import /home/MyApp/incoming/<new-software-filename>

3. Execute the upgrade software campaign, see Section 5.4.1 Execute an SMF Campaign.
4. Delete the campaign SDP and the old application software bundles:

   cmw-sdp-remove <upgrade-campaign> <old-software-bundle-name>...

5.4.5   Delete Software

Software is deleted using a campaign. The removal campaign is contained in an SDP and target system specific.

To delete software using a campaign:

1. Import the removal campaign:

   cmw-sdp-import /home/MyApp/incoming/<removal-campaign-sdp-filename>

2. Execute the removal campaign, see Section 5.4.1 Execute an SMF Campaign.
3. Delete the removal campaign SDP and the software bundles:

   cmw-sdp-remove <removal-campaign> <software-bundle-name>...

5.4.6   Initiate SMF Verification

An application can provision itself with the ability to influence the progress of an SMF campaign by registering a callback function during application startup. Once the callback is registered, it is called whenever a campaign is initiated, see Section 5.4.1 Execute an SMF Campaign.

To initiate campaign verification manually and hence execute all currently registered callbacks, use the following command:

cmw-campaign-verify <campaign-name>

The command returns exit code 0 on success, otherwise exit code 1.

Verification can also be initiated through ECIM SWM verify(), which makes use of cmw-campaign-verify.

5.5   Configure ECIM SWM

If ECIM for SWM is to be used, the installation-dependent attributes in the ECIM SWM object must be set. These attributes are described in Table 4.

For more information about these attributes, refer to Core MW Software Managementand Managed Object Model cmw_SwM.

All these attributes can be set using the following command:

cmw-swm-config-set <option> [<option>...]

Except for localFileStorePath and subType, all attributes in Table 4 can also be configured using the NBI.

The command takes the options described in Table 4.

cmw-swm-config-set --automaticBackup 1 -s smallCluster -l ⇒
/home/my/package/repository

The command activates automatic backup, sets subType to "smallCluster", and the local file store path to /home/my/package/repository.

5.6   Use CLI for Upgrade Package/CSP

Core MW can consume a UP/CBA Software Package (CSP) by using the command cmw-swm. This command allows users not using the COM component to create a UP/CSP and upgrade a CBA system using the produced package. It also allows components and applications to use the same upgrade scenario with a limited CBA stack deployed. The command takes the options described in Table 5.

Example of upgrading software using cmw-swm:

1. Create a UP/CSP from the file argument:

   cmw-swm --up-create /storage/system/software/coremw/repository/UP/ERIC-ActivateCommand_UP/ERIC-ActivateCommand_UP.tgz

   The UP/CSP can be created from file://, sftp://, or path of file.

2. Verify that the UP/CSP was created and to get the <UP-ID> of the UP/CSP:

   cmw-cwm --up-list

3. View the progress and result of the command in the previous step:

   cmw-swm --up-status

4. View the UP status:

   cmw-swm --up-status <UP-ID>

5. Verify that the UP has state INITIALIZED.
6. Set the UP/CSP upgrade execution method to ONE-STEP, ROLLING, or BALANCED:

   cmw-swm --up-execmethod <UP_ID> one-step | rolling | <role-name> <min-size-of-role> <min-remaining-capacity>

   Command cmw-swm --up-execmethod <UP-ID> (without execution method arguments) can also be used to view the upgrade execution method configured for the UP/CSP.

7. Prepare the ME for the activation of the UP/CSP with <UP-ID>:

   cmw-swm --up-prepare <UP-ID>

   The prerequisite of this action is that the state of the UP/CSP is INITIALIZED. This step is considered completed when the state of the UP/CSP is PREPARE_COMPLETED.

8. Activate the UP/CSP step by step or all at once:

   cmw-swm --up-activate <UP-ID>

   If the UP/CSP is designed with more than one step and ignoreBreakpoints is set to false, action Activate is called several times.

9. Verify that the upgrade procedure is completed:

   cmw-swm --up-confirm <UP-ID>

   The expected state is COMMIT_COMPLETED.

10. Delete the UP/CSP MO given as action parameter:

    cmw-swm --up-remove <UP-ID>

    This command also deletes all files temporarily stored in the ME and associated with the UP/CSP.

During consuming of the CSP 1.2 or above where the campaign is generated automatically, multiple campaigns are sometimes generated. If this occurs, the preparation of the CSP fails with the following status:

Action: Prepare – FINISHED
Result: FAILURE - Unsupport multiple tcg campaigns yet
State: INITIALIZED

ECIM SwM does not support multiple campaigns, so the cmw-ait-install command is provided for the Automatic Installation Tool (AIT) to continue consuming this package at installation time:

cmw-ait-install [[--status] | [--disable-backup]] <CSP-package>

cmw-ait-install [[--status] | [--disable-backup]] <CSP-ID>

Note:  

This command is only to be executed to the CSP that has just failed the prepare phase with the above status.

5.7   Configure ISP Events for Cluster Restarts

ISP events for cluster restarts are disabled by default.

This feature can be enabled or disabled during AIT installation of Core MW. For more information, see Section Automatically Installing Core MW by Using AIT in Core MW SW Installation.

ISP events for cluster restarts can be enabled in runtime with the cmw-utility command as follows:

cmw-utility immcfg --attribute ispClusterRebootLogEnabled=1 CmwMonitorIspId=1,CmwMonitorId=1,CmwSysConfigId=1

ISP events for cluster restarts can be enabled within a campaign by setting attribute ispClusterRebootLogEnabled of object with class type CmwMonitorlsp to 1.

An example of a campaign Init section that enables ISP events for cluster restarts by setting attribute ispClusterRebootLogEnabled to 1 is shown in Example 60.

<campInitAction>
 <immCCB ccbFlags="0">
   <modify objectDN="CMW_GETDN(^CmwMonitorIspId=1,CmwMonitorId=1,⇒
CmwSysConfigId=1$)" operation="SA_IMM_ATTR_VALUES_MODIFY">
    <attribute name="ispClusterRebootLogEnabled" type="SA_IMM_ATTR_SAUINT32T">
     <value>1</value>
    </attribute>
   </modify>
  </immCCB>
</campInitAction>

Note:  

In order for cluster restart events to be visible in the ISP report, the Core MW ISP_REPORT feature must also be enabled, as described in Section 3.10.4 In-Service Performance Report Feature.

5.8   Configure Reboot Behavior of Single-Step Procedures

SMF single-step procedures are typically used for installation (or removal) of components/applications where a component/application is not in-service upgradeable. If a single-step upgrade procedure contains software bundles, which require a reboot to install or remove, SMF can either perform a cluster reboot or perform nodewise reboot of only the affected nodes.

The default SMF behavior is to perform nodewise reboot during single-step upgrade procedures.

To define the affected nodes for nodewise reboot, the campaign.xml file must specify them in the <singleStepUpgrade> section, as shown in Example 61.

<singleStepUpgrade>
  <upgradeScope>
    <forAddRemove>
      <deactivationUnit>
        <actedOn>
          <byName objectDN="safAmfNode=SC-2,safAmfCluster=myAmfCluster"/>
        </actedOn>
      </deactivationUnit>	
      <activationUnit>
        <actedOn>
          <byName objectDN="safAmfNode=SC-2,safAmfCluster=myAmfCluster"/>
        </actedOn>

Attribute smfSSAffectedNodesEnable of the SMF configuration controls the nodewise reboot feature and defaults to 1. To change SMF behavior to reboot all nodes in the cluster during a single-step upgrade procedure, a campaign must disable nodewise reboot, as shown in Example 62.

<campWrapupAction>
  <immCCB ccbFlags="0">
    <modify operation="SA_IMM_ATTR_VALUES_REPLACE" objectDN="smfConfig=1,safApp=safSmfService">
      <attribute name="smfSSAffectedNodesEnable" type="SA_IMM_ATTR_SAUINT32T">
        <value>0</value>
      </attribute>
    </modify>
  </immCCB>
</campWrapupAction>

5.9   Configure Remote Fencing Parameters

All RF parameters are configured within the RF plug-in. For more information on RF plug-ins, refer to Section Remote Fencing in Core MW Programmer's Guide.

5.9.1   OpenSAF Parameters

Table 7 describes the OpenSAF fencing parameters.

5.9.2   Core MW Parameters

Table 8 describes the Core MW RF parameters.

6   Performance Management

PM jobs can be created, modified, deleted, started, and stopped programmatically using the IMM Object Management (OM) API.

This section describes the following shell command support for managing ECIM PM Jobs:

• Creating an ECIM PM Job
• Starting an ECIM PM Job
• Stopping an ECIM PM Job
• Deleting an ECIM PM Job
• Reporting status of an ECIM PM Job
• Listing ECIM PM Jobs
• Modifying an ECIM PM Job

This section also describes the following PM operation:

• Displaying active PM values for an instance

Commands are to be run as root user or prefixed with sudo and run by a user belonging to the system-adm group.

6.1   Create ECIM PM Job

To create an ECIM PM Job, use the cmw-pmjob-create command.

The command syntax is as follows:

cmw-pmjob-create <job-name>
                 (-u <pmgroup-id>
                  [-M <meas-reader>]
                  [-R <variation-rate>]
                  [-d <threshold-direction>]
                  [(-I <mo-instance>...)]
                  [-m <meas-type>]
                  [-T <threshold-id>
                   -H <threshold-high>
                   -L <threshold-low>
                   -S <severity>]
                 )...
                 [-t <job-type>]
                 [-r <reporting-period>]
                 [-g <granularity-period>]
                 [-p <job-priority>]
                 [-q <requested-state>]
                 [-c <job-control>]

The syntax is interpreted as follows:

• job-name is attribute pmJobId in the PmJob MO.
• pmgroup-id is the MO class (moClass) name of the Measurement Type (MT).
• meas-type is the MT.
• The part within ( ) can occur multiple times, as indicated with three dots.

The command supports any number of Measurement Readers (MRs) and Measurement Specifications (MSs).

For threshold jobs, up to four thresholds object are supported.

The MS can use a direct reference to an MT or use an indirect reference by referring to a moClass.

A direct reference to an MT occurs when the moClass (option -u) and the MT (option -m) are specified for the MR.

An indirect reference to a group occurs when only the moClass (option -u) is specified for the MR. However, indirect references are only valid for measurement jobs (-t 1), not for threshold jobs (-t 2).

The optional parameters for threshold jobs are as follows:

• -T <threshold-id>
  • -H <threshold-high>
  • -L <threshold-low>
  • -S <severity>
    • 3 – CRITICAL
    • 4 – MAJOR
    • 5 – MINOR (default value)
    • 6 – WARNING
• -R <variation-rate>
  • 0 – PER_SECOND (default value)
  • -1 – PER_GP

  Note:  

  Only used for Cumulative Counter (CC) collection method.

  
  
• -d <threshold-direction>
  • 1 – INCREASING
  • 2 – DECREASING

The optional Job parameters are as follows:

• -i <mo-instance>

  A specific MT instance to be referenced. If not specified, all MT instances are referenced. It supports any number of instance parameters. The format is as follows: -i <instance1> -i <instance2> -i <instance3>.

• -t <job-type>
  • 1 – MEASUREMENTJOB (default value)
  • 2 – THRESHOLDJOB
• -r <reporting-period>
  • 3 – 1 minute
  • 4 – 5 minutes
  • 5 – 15 minutes (default value)
  • 6 – 30 minutes
  • 7 – 1 hour
  • 8 – 12 hours
  • 9 – 24 hours
• -g <granularity-period>
  • 3 – 1 minute
  • 4 – 5 minutes
  • 5 – 15 minutes (default value)
  • 6 – 30 minutes
  • 7 – 1 hour
  • 8 – 12 hours
  • 9 – 24 hours
• -p <job-priority>
  • 1 – LOW
  • 2 – MEDIUM (default value)
  • 3 – HIGH
• -q <requested-state>
  • 1 – ACTIVE (default value)
  • 2 – STOPPED
• -c <job-control>
  • 0 – FULL (default value)
  • 1 – STARTSTOP
  • 2 – VIEWONLY
• -G <job-group>
• -x <compression-type>
  • 0 – GZIP

The creation of an ECIM PM Job named job3, which directly references MT rxOctets in moClass mocRx is shown in Example 63.

SC-1:~ # cmw-pmjob-create job3 -u mocRx -m rxOctets
PM job job3 created
SC-1:~ #

The command returns exit code 0 on success, otherwise exit code 1.

Attempting to create an ECIM PM Job without first defining the MT or moClass results in failure, as shown in Example 64.

SC-1:~ # cmw-pmjob-create job4 -u mocTx -m txOctets
Creating job job4...
Failed to apply object creations 21
CMW: ERROR (cmw-pmjob-create): Job creation from command line failed.
SC-1:~ #

How to create an ECIM PM Job that references an MT indirectly by the moClass mocRxRate (by not specifying option -m) is shown in Example 65.

SC-1:~ # cmw-pmjob-create job4 -u mocRxRate
PM job job4 created.
SC-1:~ #

Multiple MT references can be applied to the same job, as shown in Example 66.

SC-1:~ # cmw-pmjob-create job5 -u mocRx
                               -m rxDiscFr
                               -T rxDiscAlm
                               -H 300 -L 250 -S 3
                               -u mocRxRate
                               -m rxRate
                               -T rxRateOversub
                               -H 600 -L 550 -S 3
                               -T rxRateHigh
                               -H 400 -L 350 -S 4
                               -T rxRateBusy
                               -H 200 -L 150 -S 6
                               -t 2
PM job job5 created.
SC-1:~ #

job5 is defined as a threshold type job (flag -t is set to 2), as shown in Example 66.

job5 contains two MR references that can be described as follows:

• The first MR directly references an MT named rxDiscFr in moClass mocRx. It defines a PmThresholdMonitoring threshold named rxDiscAlm of severity class 3 (CRITICAL). The high threshold is set to 300 and the low threshold is set to 250.
• The second MR directly references an MT named rxRate in the moClass mocRxRate. It defines three PmThresholdMonitoring thresholds (rxRateOversub, rxRateHigh, and rxRateBusy), each with an assigned severity and threshold levels.

Attribute job-control is optional. Defaults to FULL, which means that the job can be started, stopped, or deleted.

PMJob2 in Example 67 is defined as a measurement job, which has job-control as 1 (STARTJOB).

SC-1:~ # cmw-pmjob-create PMJob2 -u PMGroup-1
                                 -t 1 -r 3 -g 3
                                 -p 3 -q 2 -c 1
SC-1:~ #

6.2   Start ECIM PM Job

To start an ECIM PM Job, use the cmw-pmjob-start command.

Note:  

The precondition is that job-control is FULL or STARTSTOP.

The command syntax is as follows:

cmw-pmjob-start <job-name>

The syntax is interpreted as follows:

• job-name is attribute pmJobId in the PmJob MO.

SC-1:~ # cmw-pmjob-start TC-CMW-PM-JOB-CMD-START
PM Job TC-CMW-PM-JOB-CMD-START Started.
SC-1:~ #

The command returns exit code 0 on success, otherwiseexit code 1.

A failure to start an ECIM PM Job whose job-name does not exist is shown in Example 69.

SC-1:~ # cmw-pmjob-start TC-CMW-PM-JOB-CMD-START_non-exist
CMW: ERROR (cmw-pmjob-start): PM Job ⇒
TC-CMW-PM-JOB-CMD-START_non-exist does not exist
SC-1:~ #

Attempting to start an already started ECIM PM Job results in exit code 0 with the following message:

Warning: PM Job <job-name> is already Active

6.3   Stop ECIM PM Job

To stop an ECIM PM Job, use the cmw-pmjob-stop command.

Note:  

The precondition is that job-control is FULL or STARTSTOP.

The command syntax is as follows:

cmw-pmjob-stop <job-name>

The syntax is interpreted as follows:

• job-name is attribute pmJobId in the PmJob MO.

SC-1:~ # cmw-pmjob-stop TC-CMW-PM-JOB-CMD-STOP
PM job TC-CMW-PM-JOB-CMD-STOP stopped.
SC-1:~ #

The command returns exit code 0 on success, otherwise exit code 1.

Attempting to stop an already stopped ECIM PM Job results in exit code 0 with the following message:

Warning: PM Job <job-name> is already Stopped

6.4   Delete ECIM PM Job

To delete a stopped ECIM PM Job, use the cmw-pmjob-delete command.

Note:  

The precondition is that job-control is FULL.

The command syntax is as follows:

cmw-pmjob-delete <job-name>

The syntax is interpreted as follows:

• job-name is attribute pmJobId in the PmJob MO.

SC-1:~ # cmw-pmjob-delete TC-CMW-PM-JOB-CMD-CC-ECIM-001
PM job TC-CMW-PM-JOB-CMD-CC-ECIM-001 deleted.
SC-1:~ #

The command returns exit code 0 on success, otherwise exit code 1.

Attempting to delete an ACTIVE ECIM PM Job results in exit code 1 with the following message:

CMW: ERROR (cmw-pmjob-delete): PM Job <job-name> is Active - can not be deleted

Attempting to delete a non-existent ECIM PM Job results in exit code 1 with the following message:

CMW: ERROR (cmw-pmjob-delete): PM Job <job-name> does not exist

6.5   Report Status of ECIM PM Job

To report the status of an ECIM PM Job, use the cmw-pmjob-status [-v] <job-name> command.

The command syntax is as follows:

cmw-pmjob-status [-v] <job-name>

The syntax is interpreted as follows:

• job-name is attribute pmJobId in the PmJob MO.
• The optional -v flag produces a verbose output. Omitting the -v flag only produces the job name and status.

SC-1:~ # cmw-pmjob-status TC-CMW-PM-JOB-CMD-STATUS-2
PM job TC-CMW-PM-JOB-CMD-STATUS-2 is active
SC-1:~ #

SC-1:~ # cmw-pmjob-status -v TC-CMW-PM-JOB-CMD-STATUS-2
Name                   Value(s)
========================================
pmJobId                TC-CMW-PM-JOB-CMD-STATUS-2
jobType                Measurement(0x1)
granularityPeriod      1 minute(0x3)
reportingPeriod        1 minute(0x3)
jobPriority            High(0x3)
requestedJobState      Active(0x1)
currentJobState        Active(0x1)
Overall Job State      Active(0x1)
SC-1:~ #

If the job does not exist or if the status cannot be shown, the command returns exit code 1 and logs the following message:

CMW: ERROR (cmw-pmjob-status): Could not show the status for PM Job <job-name>

Otherwise the command returns exit code 0.

6.6   List ECIM PM Jobs

To list ECIM PM Jobs, use the cmw-pmjob-list command.

The command syntax is as follows:

cmw-pmjob-list [<options>]

The possible options are as follows (<N> is a numeral):

• -v – Use long format for each job.
• -h|--help – Display this help and exit.
• -f – List only jobs with problems (faulty).
• -r <N> – List only jobs with this reporting period.
• -t <N> – List only jobs with this job type.
• -p <N> – List only jobs with this job priority.
• -g <N> – List only jobs with this granularity period.
• -q <N> – List only jobs with this requested job state.
• -s <N> – List only jobs with this current job state.

Using the command without any options results in a short listing, showing each ECIM PM Job name, requested job state, and current job state, as shown in Example 74.

SC-1:~ # cmw-pmjob-list
pmJobId=TCPMJCA_0, requestedJobState=Stopped(0x2), currentJobState=Stopped(0x2)
pmJobId=TCPMJCA_1, requestedJobState=Active(0x1),  currentJobState=Active(0x1)
pmJobId=TCPMJCA_2, requestedJobState=Stopped(0x2), currentJobState=Stopped(0x2)
pmJobId=TCPMJCA_3, requestedJobState=Active(0x1),  currentJobState=Active(0x1)
pmJobId=TCPMJCA_4, requestedJobState=Stopped(0x2), currentJobState=Stopped(0x2)
SC-1:~ #

The command contains a -v flag for verbose (long format). The output contains detailed information about each ECIM PM Job, as shown in Example 75.

SC-1:~ # cmw-pmjob-list -v
Name                   Value(s)
========================================
pmJobId                Job1
jobType                Measurement(0x1)
granularityPeriod      15 minutes(0x5)
reportingPeriod        5 minutes(0x4)
jobPriority            Medium(0x2)
requestedJobState      Active(0x1)
currentJobState        Active(0x1)
Overall Job State      Active(0x1)
Name                   Value(s)
========================================
pmJobId                Job2
jobType                Threshold(0x2)
granularityPeriod      15 minutes(0x5)
reportingPeriod        1 minute(0x3)
jobPriority            Medium(0x2)
requestedJobState      Active(0x1)
currentJobState        Active(0x1)
Overall Job State      Active(0x1)
Name                   Value(s)
========================================
pmJobId                Job3
jobType                Threshold(0x2)
granularityPeriod      15 minutes(0x5)
reportingPeriod        1 hour(0x7)
jobPriority            Medium(0x2)
requestedJobState      Active(0x1)
currentJobState        Active(0x1)
Overall Job State      Active(0x1)
SC-1:~ #

Multiple options can be combined in one command to OR the result. For example, using multiple options on the same job list as in Example 75, jobs with reportingPeriod equal to 1 minute and jobType equal to Measurement can be shown. A filtered list using multiple options is shown in Example 76.

SC-1:~ # cmw-pmjob-list -v -r 3 -t 1
Name                   Value(s)
========================================
pmJobId                Job1
jobType                Measurement(0x1)
granularityPeriod      15 minutes(0x5)
reportingPeriod        5 minutes(0x4)
jobPriority            Medium(0x2)
requestedJobState      Active(0x1)
currentJobState        Active(0x1)
Overall Job State      Active(0x1)
Name                   Value(s)
========================================
pmJobId                Job2
jobType                Threshold(0x2)
granularityPeriod      15 minutes(0x5)
reportingPeriod        1 minute(0x3)
jobPriority            Medium(0x2)
requestedJobState      Active(0x1)
currentJobState        Active(0x1)
Overall Job State      Active(0x1)
SC-1:~ #

Multiple options can be used in short format (without flag -v), as shown in Example 77.

SC-1:~ # cmw-pmjob-list -r 3 -t 1 -g 5
pmJobId=Job2, requestedJobState=Active(0x1), ⇒
currentJobState=Active(0x1), reportingPeriod=3
pmJobId=Job1, requestedJobState=Active(0x1), ⇒
currentJobState=Active(0x1), jobType=1
pmJobId=Job1, requestedJobState=Active(0x1), ⇒
currentJobState=Active(0x1), granularityPeriod=5
pmJobId=Job2, requestedJobState=Active(0x1), ⇒
currentJobState=Active(0x1), granularityPeriod=5
pmJobId=Job3, requestedJobState=Active(0x1), ⇒
currentJobState=Active(0x1), granularityPeriod=5
SC-1:~ #

6.7   Modify ECIM PM Job

To modify a stopped ECIM PM Job, use the cmw-pmjob-modify command.

The command syntax is as follows:

cmw-pmjob-modify <job-name> <added-MOs> | <deleted-MOs> | <modified-attributes>

Syntax when adding MeasurementReader MOs:

cmw-pmjob-modify <job-name>
                 [(-C
                   [-M <meas-reader>]
                   [-R <threshold-rate-of-variation>]
                   [-d <threshold-direction>]
                   [(-i <mo-instance>...)]
                   -u <pmgroup-id>
                   [-m <meas-type>]
                  )...]

Syntax when adding PmThresholdMonitoring MOs:

cmw-pmjob-modify <job-name>
                 [(-C
                   [-M <meas-reader>]
                   (-T <threshold-id>
                    -H <threshold-high>
                    -L <threshold-low>
                    -S <severity>)
                  )...]

Syntax when adding both MeasurementReader and PmThresholdMonitoring MOs:

cmw-pmjob-modify <job-name>
                 [(-C
                   [-M <meas-reader>]
                   [-R <threshold-rate-of-variation>]
                   [-d <threshold-direction>]
                   [(-i <mo-instance>...)]
                   -u <pmgroup-id>
                   -m <meas-type>
                   (-T <threshold-id>
                    -H <threshold-high>
                    -L <threshold-low>
                    -S <severity>)
                  )...]

Syntax when deleting MOs:

cmw-pmjob-modify <job-name>
                 [(-D
                   -M <meas-reader>
                   [-T <threshold-id>]
                  )...]

Syntax when modifying attributes:

cmw-pmjob-modify <job-name>
                 [-r <reporting-period>]
                 [-g <granularity-period>]
                 [-p <job-priority>]
                 [-G <job-group>]
                 [-x <compression-type>]

This command requires -C to indicate child MO creation, and -D to indicate child MO deletion. All the other options have the same meanings as with the cmw-pmjob-create command, see Section 6.1 Create ECIM PM Job. The parts within () can occur multiple times.

The addition of a MeasurementReader MO to an existing job named job3 is shown in Example 78.

SC-1:~ # cmw-pmjob-modify job3 -C -u mocRx -m rxOctets
Modifying job job3...
PM job job3 modified.
SC-1:~ #

The command returns exit code 0 on success, otherwise exit code 1.

The addition of both a MeasurementReader MO and its child PmThresholdMonitoring MO to an existing threshold job named job5 is shown in Example 79.

SC-1:~ # cmw-pmjob-modify job5 -C -M mrRxRate -u mocRxRate -m rxRate ⇒
-T rxRateOversub -H 50 -L 45 -S 3
Modifying job job5...
PM job job5 modified.
SC-1:~ #

The addition of a PmThresholdMonitoring MO to an existing MeasurementReader MO of an existing job named job5 is shown in Example 80. As the PmThresholdMonitoring MO is a child of a MeasurementReader MO, parameter -M must be specified.

SC-1:~ # cmw-pmjob-modify job5 -C -M mrRxRate -T rxRateOversub -H 50 ⇒
-L 45 -S 3
Modifying job job5...
PM job job5 modified.
SC-1:~ #

The deletion of a MeasurementReader MO from an existing job named job3 is shown in Example 81.

SC-1:~ # cmw-pmjob-modify job3 –D –M mrRxRate
Modifying job job3...
PM job job3 modified.
SC-1:~ #

The deletion of a PmThresholdMonitoring MO from an existing threshold job named job5 is shown in Example 82. Parameter -M must be specified.

SC-1:~ # cmw-pmjob-modify job5 -D -M mrRxRate -T rxRateOversub
Modifying job job5...
PM job job5 modified.
SC-1:~ #

Modifying one or more ECIM PM Job attributes for an existing job named job3 is shown in Example 83.

SC-1:~ # cmw-pmjob-modify job3 -p 2 -x 0 -G group1
Modifying job job3...
PM job job3 modified.
SC-1:~ #

6.8   Display Active PM Values for an Instance

To display active PM values for a specified instance, use the command cmw-pm-show-counters. The command displays the current value of all MTs associated with a specified instance.

Note:  

The precondition is that the instance is associated with the MTs that are measured by an active ECIM PM Job.

The command syntax is as follows:

cmw-pm-show-counters [-v] <instance>
                     [-t <timeout>]
                     [-j <job-name> [<job-name>...]]
                     [-m <meas-type> [<meas-type>...]]

The syntax is interpreted as follows:

• -v | --verbose is verbose.
• -t | --timeout <seconds> is the time-out. Defaults to 6 seconds.
• job-name is attribute pmJobId of an active PmJob MO. If job names are specified, only instance values from the specified jobs are displayed.
• meas-type is attribute measurementTypeId of a MeasurementType MO. If MTs are specified, only instance values associated with the specified MTs are displayed.

The command returns exit code 0 on success, otherwise exit code 1.

cmw-pm-show-counters MeasObj=1
    intCounterActive=123 SUSPECT
    multivalueIntCounter=12,14,16

cmw-pm-show-counters -v MeasObj=1
    intCounterActive=123 PmJob=1 Gp=5 min SUSPECT
    multivalueIntCounter=12,14,16 PmJob=1 Gp=5 min

7   OpenSAF Tools

7.1   OpenSAF Tools Wrapper

The cmw-utility command can be used to run the following OpenSAF tools:

• immfind
• immlist
• immcfg
• immadm
• amfadm
• runasroot

The command syntax is as follows:

cmw-utility [-h | --help] <immfind | immlist | immcfg | immadm | amfadm | runasroot> [<options>]

The syntax is interpreted as follows:

• -h | --help – Print help menu.
• options – See the following sections for the individual OpenSAF tools.

7.1.1   immfind

immfind is used for searching for IMM objects.

The command syntax is as follows:

cmw-utility immfind [path...] [<options>]

The options are as follows:

• -c | --class <name> – Only search for objects of the specified class.
• -t | --timeout <timeout> – Utility time-out in seconds.

cmw-utility immfind --class SaAmfCluster

7.1.2   immlist

immlist is used for listing IMM objects.

The command syntax is as follows:

cmw-utility immlist [<options>] <object-name> [<object-name>...]

cmw-utility immlist [<options>] <class-name>

The options are as follows:

• -a | --attribute <name> – Attribute name to print.
• -c | --class <name> – Class definition to print.
• -t | --timeout <timeout> – Utility time-out in seconds.

cmw-utility immlist safAmfCluster=myAmfCluster
cmw-utility immlist --attribute SaImmAttrClassName ⇒
CmwMonitorId=1,CmwSysConfigId=1
cmw-utility immlist --class CmwMonitor

7.1.3   immcfg

immcfg is for creating, deleting, or modifying IMM objects.

The command syntax is as follows:

cmw-utility immcfg ([<options>] [<object-name>])...

The options are as follows:

• -a | --attribute <name>[+|-]=<value> – Change attribute.
• -c | --create-object <class-name> – Create an object of the specified class.
• -d | --delete-object [<object-name>]... – Delete objects.
• -m | --modify-object [<object name>]... – Modify objects.
• -u | --unsafe – The CCBs generated by immcfg have SA_IMM_CCB_REGISTERED_OI set to false, allowing CCB commit when Object Implementers (OIs) are missing.
• -t | --timeout <timeout> – Utility time-out in seconds.

cmw-utility immcfg --create-object CmwPmPmJob ⇒
pmJobId=CmwUtilityTestJobObj,CmwPmpmId=1

cmw-utility immcfg --attribute requestedJobState=2 ⇒
CmwPmPmJob pmJobId=CmwUtilityTestJobObj,CmwPmpmId=1

cmw-utility immcfg --delete-object ⇒
pmJobId=CmwUtilityTestJobObj,CmwPmpmId=1

7.1.4   immadm

immadm is used for performing an IMM admin operation.

The command syntax is as follows:

cmw-utility immadm [<options>] [<object-name>...]

The options are as follows:

• --disable-tryagain – Disable try again handling. Defaults to no.
• -o | --operation-id <id> – Numerical operation ID.
• -p | --parameter=<p> – Parameter/parameters to admin operation.

  Parameter syntax: <name>:<type>:<value>

  Value types according to imm.xsd: SA_INT32_T, SA_UINT32_T, SA_INT64_T, SA_UINT64_T, SA_TIME_T, SA_NAME_T, SA_FLOAT_T, SA_DOUBLE_T, SA_STRING_T.

• -t | --timeout <timeout> – Utility time-out in seconds.

cmw-utility immadm --operation-id 1 ⇒
safJob=CmwUtilityTestJobObj,safPm=1

7.1.5   amfadm

amfadm is used for performing an AMF admin operation.

The command syntax is as follows:

cmw-utility amfadm [<options>] <command> <object-name>

The options are as follows:

• -s | --su – Specified object DN is checked to be an SU before performing AMF admin operation.
• -t | --timeout <timeout> – Utility time-out in seconds.
• <command> – lock, unlock, lock-in, unlock-in, shutdown, restart, si-swap, sg-adjust, repaired, eam-start, eam-stop.

cmw-utility amfadm --su lock safSu=SC-1,safSg=2N,⇒
safApp=ERIC-CoreMW
cmw-utility amfadm unlock safSu=SC-1,safSg=2N,⇒
safApp=ERIC-CoreMW

7.1.6   runasroot

runasroot is used for running a command with root privileges. It only supports the SMF service and must be called through SMF callbacks.

The command syntax is as follows:

cmw-utility runasroot <command>

For an example, refer to Section Built-in SMF API Callback Receiver in Core MW Software Management.

8   Backup and Restore Framework

For information about the Backup and Restore Framework, refer to BRF-C Management Guide.