NAME
mxnode - Systems Insight Manager system file format
SYNOPSIS
mxnode
DESCRIPTION
The mxnode command supports reading and writing node information in
the eXtensible Markup Language (XML) format. You may use this
capability to add, modify, remove or list multiple nodes in the
Systems Insight Manager environment. Each file may contain the
definitions of one or more nodes.
Document Type Definition
The Document Type Definition (DTD) file defines the constraints for an
XML file. These constraints include the valid element tags,
attributes, and the cardinality of elements in an XML file. The user
DTD file is named nodelist.dtd and is included in the following
paragraph. Note that due to man page formatting, the DTD contents may
not appear the same as in the file.
--- BEGIN NODELIST.DTD FILE SOURCE ---
<?xml version="1.0" encoding="UTF-8" ?>
<!-- READ THIS FIRST! This file is intentionally formatted with a
right margin set at 70. This allows the DTD file to be pasted
directly into the mxnode(4) man page file. Please respect this
constraint when editing this file. After edits are final for
a given release, please paste the final DTD version in the
mxnode(4) man page to keep the documentation current.
-->
<!-- The node-list element consists of zero or more node elements.
-->
<!ELEMENT node-list ( node* ) >
<!-- The node element consists zero or more sw-attribute elements,
zero or more hw-attribute elements, or zero or more credentials or a
combination of all of these elements.
-->
<!ELEMENT node ( sw-attribute |
hw-attribute |
credential |
managementpath-list )* >
<!-- The node element has the following attributes:
The name attribute specifies the node name and is optional.
The host-name attribute specifies the host name and is optional.
The monitoring attribute specifies whether discover or
identification of the node is suspended/resumed and is optional.
The guid attribute specifies the node GUID and is optional.
-->
<!ATTLIST node name CDATA #IMPLIED
host-name CDATA #IMPLIED
monitoring CDATA #IMPLIED
guid NMTOKEN #IMPLIED >
<!-- The sw-attribute element specifies a list of software attributes
for a node. A software attribute is specified as a name/value
pair. In an sw-attribute element, the software attribute name
portion is specified using the element's attribute called "name",
and the software attribute value portion is specified as the
PCDATA of the element.
-->
<!ELEMENT sw-attribute (#PCDATA) >
<!ATTLIST sw-attribute name CDATA #REQUIRED >
<!-- The hw-attribute element specifies a list of hardware attributes
for a node. A hardware attribute is specified as a name/value
pair. In a hw-attribute element, the hardware attribute name
portion is specified using the element's attribute called "name",
and the hardware attribute value portion is specified as the
PCDATA of the element.
-->
<!ELEMENT hw-attribute (#PCDATA) >
<!ATTLIST hw-attribute name CDATA #REQUIRED >
<!-- The credential element specifies the credential for a specified protocol.
The credential element is empty and is specified with the defined attributes.
The protocol attribute is required and specifies the credentialed protocol,
such as wbem or snmp.
The user name attribute is optional and associates a user name with the protocol.
The password attribute is optional and is associated with the user name.
-->
<!ELEMENT credential EMPTY >
<!ATTLIST credential protocol CDATA #REQUIRED
username CDATA #IMPLIED
password CDATA #IMPLIED >
<!-- ************************************************** -->
<!-- ManagementPath definitions below -->
<!-- ************************************************** -->
<!-- The managementpath-list element consists of zero or more managementpath elements -->
<!ELEMENT managementpath-list ( managementpath )* >
<!ATTLIST managementpath-list totalmpos CDATA #IMPLIED >
<!-- The managementpath element consists of zero or more of the following elements -->
<!ELEMENT managementpath ( catagoryname |
mroluid |
profilelist |
namespace |
cimcspath |
associatedmaoguid |
associatedmaoluid |
managementagent |
nodeguid |
nodename |
proxytype |
portnumber |
ipaddress |
protocol |
maoluid |
interopnamespace |
functionalprofilelist )* >
<!-- The managementpath element may have the following attributes -->
<!-- The mpotype attribute is required for the managementpath element -->
<!-- Its value can be either "MRO" or "MAO" -->
<!-- The maotype attribute is required for the managementpath element -->
<!-- Its value can be: "WBEM_CIMOM", "WMI_MAPPER" -->
<!-- The location attribute is optional for the managementpath element -->
<!-- Its vaue can be either "OnThisNode" or "OnOtherNode" -->
<!ATTLIST managementpath mpotype CDATA #IMPLIED
mpoversion CDATA #IMPLIED
maotype CDATA #IMPLIED
location CDATA #IMPLIED >
<!-- -->
<!ELEMENT catagoryname (#PCDATA) >
<!-- -->
<!ELEMENT mroluid (#PCDATA) >
<!-- The profilelist element applies to both the managementpath and managementagent elements -->
<!ELEMENT profilelist ( profilename )* >
<!-- -->
<!ELEMENT profilename (#PCDATA) >
<!-- -->
<!ELEMENT namespace (#PCDATA) >
<!-- -->
<!ELEMENT cimcspath (#PCDATA) >
<!-- -->
<!ELEMENT associatedmaoguid (#PCDATA) >
<!-- -->
<!ELEMENT associatedmaoluid (#PCDATA) >
<!-- The managementagent element consists of zero or more of the following elements -->
<!ELEMENT managementagent ( nodeguid |
nodename |
proxytype |
portnumber |
ipaddress |
protocol |
maoluid |
interopnamespace |
profilelist |
functionalprofilelist )* >
<!-- The managementagent element may have the following attributes -->
<!-- The mpotype attribute is required for the managementpath element -->
<!-- Its vaue can be either "MRO" or "MAO" -->
<!-- The maotype attribute is required for the managementpath element -->
<!-- Its value can be: "WBEM_CIMOM", "WMI_MAPPER" -->
<!-- The location attribute is optional for the managementpath element -->
<!-- Its vaue can be either "OnThisNode" or "OnOtherNode" -->
<!ATTLIST managementagent mpotype CDATA #IMPLIED
mpoversion CDATA #IMPLIED
maotype CDATA #IMPLIED
location CDATA #IMPLIED >
<!-- -->
<!ELEMENT nodeguid (#PCDATA) >
<!-- -->
<!ELEMENT nodename (#PCDATA) >
<!-- -->
<!ELEMENT proxytype (#PCDATA) >
<!-- -->
<!ELEMENT portnumber (#PCDATA) >
<!-- -->
<!ELEMENT ipaddress (#PCDATA) >
<!-- -->
<!ELEMENT protocol (#PCDATA) >
<!-- -->
<!ELEMENT maoluid (#PCDATA) >
<!-- -->
<!ELEMENT interopnamespace (#PCDATA) >
<!-- -->
<!ELEMENT functionalprofilelist ( profilename )* >
--- END NODELIST.DTD FILE SOURCE ---
Elements
As defined in the DTD, the node XML file may contain the following
elements.
The first line of a node XML file should be in the following format:
<?xml version="1.0" encoding="encoding-value" ?>
where the user substitutes a recognized encoding value for the
encoding-value parameter. The recognized encoding values may be found
at the following web site:
http://www.iana.org/assignments/character-sets
If no XML header line is specified, the system defaults encoding to
"UTF-8".
The "node-list" element must appear once in a node XML file and wraps
the list of node information. The "node-list" element may contain zero
or more "node" elements. Note that if the "node-list" element contains
no "node" elements, the associated mxnode command will have no
effect.
The "node" element supports four attributes.
(1) The "name" attribute is optional and specifies the node name.
(2) The "host-name" attribute is optional and specifies the network
hostname.
(3) The "guid" attribute is optional and specifies the globally unique
identifier of the node. Because this value is assigned by the system,
the system ignores this attribute when adding a new node.
(4) The "monitoring" attribute allows the user to control the
monitoring of the system/node by Systems Insight Manager. In normal
operation, the system is continously monitored (includes Discovery and
Identification) by Systems Insight Manager. Monitoring of the system
may be suspended for one of several pre-defined time duration values,
or monitoring may be suspended indefinately. If the 'monitoring'
attribute is not included in the XML file for a '-m -f' command, then
the current monitoring state for the node is left as is.
As reference, this same 'monitoring' feature may be modified through
the "Suspend/Resume Monitoring" page of the Systems Insight Manager
GUI.
Valid values for the 'monitoring' attribute are as follows.
monitoring="resume" Do not suspend monitoring
monitoring="suspend.5m" Suspend monitoring for 5 minutes
monitoring="suspend.15m" Suspend monitoring for 15 minutes
monitoring="suspend.1h" Suspend monitoring for 1 hour
monitoring="suspend.1d" Suspend monitoring for 1 day
monitoring="suspend" Suspend monitoring indefinitely
The "node" element may contain a number of optional elements. The
"sw-attribute", "hw-attribute" and "credential" elements may appear
zero or more times.
The "sw-attribute" element specifies a software-related node
attribute, such as the operating system type. The required "name"
specifies the attribute name. The text content of this element
specifies the attribute value.
The "hw-attribute" element specifies a hardware-related node
attribute, such as the device type. The required "name" specifies the
attribute name. The text content of this element specifies the
attribute value.
The "credential" element specifies the credential to use with a
specified protocol. The required "protocol" attribute specifies the
protocol, such as WBEM or SNMP. The optional "username" attribute
specifies a user name, and the optional "password" attribute specifies
a password. Note that the credential information is included only for
compatibility with mxnodesecurity. It is ignored by mxnode.
Pre-defined system attributes/properties
The following is the complete list of system attributes (or
properties) that are pre-defined and recognized by Systems Insight
Manager. Invoking mxnode with either the -ld or -lf options on a
particular existing system or node will allow you to view the current
values for some or all of the attributes shown below.
Note that the next section contains the limited list of those
attributes that may be modified and locked via XML, by using the
'mxnode -m -f <filename> command.
System name The system name is by default the same as the
hostname, if a hostname exists, or else the IP
address. The system name may be anything as long
as it is unique among all the systems in the
repository, and it may be changed.
Host name The hostname available from gethostbyname(1). It
may have embedded spaces and its maximum length is
16 characters. Hostnames are not case sensitive
and are represented internally as fully-qualified
names.
IP address The IP address corresponding to the hostname.
OS name This is the name of the operating system on the
managed system.
OS revision This is the revision level of the operating
system.
OS revision text
This is the operating system revision with
vendor-specific descriptive information. Note
that this attribute will contain same descriptive
text as the 'OS Description' attribute.
OS vendor This is the operating system vendor.
Protocols These are the management protocols supported by
the managed system, with the revision level of
each protocol.
GUID The GUID is a unique identifier assigned to a
system in the repository.
Hardware device ID
The hardware device ID is another unique
identifier assigned to the hardware-specific
portion of a system in the repository.
Device type This is the major type of the device.
Device subtype This is a subtype of the device within the major
type. Up to 8 subtypes per node may be specified
within the XML file.
Model This is the device model.
Added By This is the login of the Systems Insight Manager
user who added the system.
Added Date This is the date and time the system was added.
Preferred Node Name
This attribute defines an alternate system/node
name of your choosing which may make it easier for
you to identify, find or organize systems/nodes
residing in the Systems Insight Manager
repository.
System Description
This is a description of the system.
Serial Number This is the serial number of the system.
Asset Number This is the asset number of the system.
OS Description This is the description of the system's operating
system. Note that this attribute will contain
same descriptive text as the 'OS Revision Text'
attribute.
Contact This is the person to contact in case of system
maintenance.
Location This is the location where the system physically
resides.
System attributes that may be locked
The following is the complete list of system attributes (or
properties) that may be modified and locked via the 'mxnode -m -f
<filename>' command. Locking an attribute prevents that attribute
from being over written by any possible Discovery and Identification
processes. Note that the attribute name that's enclosed in
parenthesis is the actual attribute name that would be used in the
mxnode XML file.
Also note that system attributes are categorized into two distinct
groups, hardware and software attributes, and that when specifying an
attribute to be modified within an mxnode XML file, the correct
attribute modifier must be used.
For example, the Device Type attribute is considered a 'hardware'
attribute and would be specified as follows within the XML file by
using the 'hw-attribute' modifier.
<hw-attribute name="DeviceType">Device Type here</hw-attribute>
The OS Name is considered a 'sofware' attribute and would be specified
as follows within the XML file by using the 'sw-attribute' modifier.
<sw-attribute name="OSName">Your OS name here</sw-attribute>
Again, only the following system attributes may be locked:
Preferred Node Name (software attribute)
(PreferredNodeName) This attribute defines an
alternate system/node name of your choosing which
may make it easier for you to identify, find or
organize systems/nodes residing in the Systems
Insight Manager repository.
Device Type (hardware attribute)
(DeviceType) This attribute is the major type of
the device. Note that only the following pre-
defined valid device types may be used as a value
for a device type. Note that only 1 device type
may be specified within the XML file.
Unknown, Unmanaged, Server, Desktop, Workstation, Portable,
Router, Cluster, Printer, Switch, Hub, RAS, MgmtProc, Rack,
Enclosure, KVM, UPS, PDU, Env, Complex, Handheld, Partition,
PowerSupply, ThinClient, Storage.
Device Subtype (hardware attribute)
(DeviceSubType) This attribute is a subtype within the
device's major type. Up to 8 total of the following pre-
defined valid device subtypes may be specified as device
subtypes within the XML file. Again, 1-8 DeviceSubType hw
attribute lines may be specified within the XML file.
None, Blade, Dell, HPSuperdome, HPAlphaServer, HPAlphaStation,
HPDeskpro HPEvo, HPIntegrity, HPIntegrityServer,
HPIntegritySuperdome HPINtegrityWorkstation, HPKayak,
HPNetServer, HPOmnibook, HPProLiant HPServer, HP ServiceGuard,
HPVectra, HPVisualize, HPWorkstation HighAvailabilityArray,
HighAvailabilityCluster, MSCS, NSCUW7, HPNonStop OVM7, PowerEnc,
RAC, ServerEnc, Storage, TCR_PS, TruCluster HPUNCFG, VMGuest,
VMHost.
Model (hardware attribute)
(Model) This attribute describes the device model. Any
displayable text may be used as a value for this attribute.
System Description (software attribute)
(SystemDescription) This attribute describes the device.
Any displayable text may be used as a value for this
attribute.
Serial Number (hardware attribute)
(SerialNumber) This attribute is the device's serial number.
Any displayable text may be used as a value for this
attribute.
Asset Number (software attribute)
(AssetNumber) This attribute is the device's asset number.
Any displayable text may be used as a value for this
attribute.
OS Description (software attribute)
(OSDescription) This attribute describes the device's
Operating System. Any displayable text may be used as a
value for this attribute. Note that setting this attribute
will also change the 'OS Revision Text' attribute to same
value as they will both contain same descriptive text.
OS Name (software attribute)
(OSName) This attribute defines the name of the Operating
System. Note that only the following pre-defined valid
values may be used as values for this attribute.
HPUX, WINNT, LINUX, NOVEL, Tru64.
OS Revision (software attribute)
(OSRevision) This attribute defined the Operating System
revision or version. Any displayable text may be used as a
value for this attribute.
Contact (software attribute)
(Contact) This attribute is used to define a contact person
for this device. Any displayable text may be used as a
value for this attribute.
Location (software attribute)
(Location) This attribute is used to define a physical
location for this device. Any displayable text may be used
as a value for this attribute.
As reference, these same attributes may be modified through the "Edit
System Properties" page of the Systems Insight Manager GUI. However,
note that there is some difference in the wording between the
attribute name as required in the XML file, and the attribute label as
displayed in the GUI. The following list may be used as a cross
reference:
XML Attribute Name GUI Attribute Label
PreferredNodeName Preferred display name:
DeviceType System type:
DeviceSubType System subtype:
Model Product model:
SysDescription Hardware description:
SerialNumber Serial number:
AssetNumber Asset number:
OSDescription Operating System description:
OSName Operating System for tool filtering:
OSRevision Operating System version:
Contact Contact:
Location Location:
Commenting
Comments may be included in XML files. The comment must begin with
the characters "<!--" and end with the characters "-->". Comments may
span multiple lines within the beginning and ending character tags.
Examples
This section contains some examples of node XML files.
This example shows a file containing nodes to be identified and added
to the repository via a 'mxnode -a -f <filename>' command. Note that
the node may be specified either by providing a Name or IP address.
Also note the difference in syntax as to specifying the node either by
name or IP address.
<?xml version="1.0" encoding="UTF-8"?>
<node-list>
<node name="abc" host-name="abc.mycompany.com" />
<node>
<sw-attribute name="IPAddress">192.1.1.1</sw-attribute>
</node>
<node name="maple" />
</node-list>
This example shows what an identified node might look like. Note that
in this example, there are 4 device subtypes specified. A maximum of
8 valid subtypes are allowed to be specified per node. See preceding
section for list of valid subtypes that may be specified within the
XML. Also note that the 3 default settings have been set to false
which specifies that all three setting types shall not be changed
when/if a new discovery process is run on this particular 'abc' node.
Specifying a 'true' attribute value for a particular setting would
allow a discovery process to overwrite that setting's value.
<?xml version="1.0" encoding="UTF-8"?>
<node-list>
<node name="abc" guid="..." host-name="abc.mycompany.com">
<hw-attribute name="DeviceType">Workstation</hw-attribute>
<hw-attribute name="DeviceSubType">HP9000</hw-attribute>
<hw-attribute name="DeviceSubType">HighAvailabilityArray</hw-attribute>
<hw-attribute name="DeviceSubType">HighAvailabilityCluster</hw-attribute>
<hw-attribute name="DeviceSubType">TruCluster</hw-attribute>
<hw-attribute name="Model">9000/785</hw-attribute>
<hw-attribute name="ProcessorFamily">pa-risc</hw-attribute>
<sw-attribute name="OSName">HPUX</sw-attribute>
<sw-attribute name="OSVendor">HP</sw-attribute>
<sw-attribute name="OSRevision">11.00</sw-attribute>
<sw-attribute name="IPAddress">192.1.2.3</sw-attribute>
<sw-attribute name="ProtocolSupport">SNMP:1.0</sw-attribute>
<sw-attribute name="Description">HP-UX phoenix</sw-attribute>
<sw-attribute name="SystemName">abc.mycompany.com</sw-attribute>
<sw-attribute name="DefaultProtoSettings">false</sw-attribute>
<sw-attribute name="DefaultAttributeSettings">false</sw-attribute>
<sw-attribute name="DefaultSystemName">false</sw-attribute>
</node>
</node-list>
The following example lists a node in XML format and includes all
pre-defined system attributes for reference, including those that may
be modified and/or locked. One method for modifying a particular
system/node would be to use the 'mxnode -lf >filename' command to
output the XML data to an external output file. The output file could
then be manually edited so as to change/add those attributes that need
to be modified and/or locked. After the file is edited, then use the
'mxnode -m -f <filename>' command to actually modify the system/node,
specifying the file just edited as the input file for the command.
Note that the XML below also includes the method for locking those
attributes that are lockable. If the desire is to keep certain
attributes from being over-written (locked) by the Discovery or
Identification process, then ALL THREE of the attribute lock flags
(see example XML) must be set to a 'false' value, as shown below.
Else, all three attributes must be set to 'true'.
<sw-attribute name="DefaultProtoSettings">false</sw-attribute>
<sw-attribute name="DefaultAttributeSettings">false</sw-attribute>
<sw-attribute name="DefaultSystemName">false</sw-attribute>
As reference, these same three attribute lock flags may be modified
through the "Edit System Properties" page of the Systems Insight
Manager GUI. Checking or Unchecking the the "Prevent the Discovery
and Identification processes from changing these system attributes"
checkbox is the same as setting the three attribute lock flags to
either true or false. Checking the checkbox is the same as setting
all 3 flags to 'false'. Unchecking the checkbox is the same as
setting all 3 flags to 'true'.
Note that the XML also includes the 'monitoring' feature attribute
within the node element. This feature allows the user to control the
monitoring of the system/node by Systems Insight Manager. In normal
operation, the system is continously monitored (includes Discovery and
Identification) by Systems Insight Manager. Monitoring of the system
may be suspended for some pre-determined time, or monitoring may be
suspended indefinately.
As reference, this same 'monitoring' feature may be modified through
the "Suspend/Resume Monitoring" page of the Systems Insight Manager
GUI.
Valid values for the 'monitoring' attribute are as follows.
monitoring="resume" Do not suspend monitoring
monitoring="suspend" Suspend monitoring indefinitely
monitoring="suspend.5m" Suspend monitoring for 5 minutes
monitoring="suspend.15m" Suspend monitoring for 15 minutes
monitoring="suspend.1h" Suspend monitoring for 1 hour
monitoring="suspend.1d" Suspend monitoring for 1 day
For your reference, all attributes that may be modified and locked are
prepended (marked) with an 'L'. Those attributes that may be modified
and locked, but require a pre-defined value are marked with an
asterisk character. See preceding sections that list the valid values
for the 'DeviceType', 'Device Subtype' and 'OS Name' attributes. And
again, be aware of those attributes that are categorized as hardware
versus software attributes. The three attribute lock flags are
prepended with an 'LF' marker.
Note that setting the 'OS Description' attribute will also change the
'OS Revision Text' attribute to same value as they will both contain
same descriptive text.
Sample XML file showing all system attribute formats and syntax:
<?xml version="1.0" encoding="windows-1252"?>
<node-list>
<node name="systemName" host-name="hostName" monitoring="resume">
L* <hw-attribute name="DeviceType">your data here</hw-attribute>
L* <hw-attribute name="DeviceSubType">your data here</hw-attribute>
L <hw-attribute name="Model">your data here</hw-attribute>
L <hw-attribute name="SerialNumber">your data here</hw-attribute>
<hw-attribute name="OverallStatus">NORMAL</hw-attribute>
<hw-attribute name="ProductID">12345</hw-attribute>
L* <sw-attribute name="OSName">your data here</sw-attribute>
L <sw-attribute name="OSRevision">your data here</sw-attribute>
<sw-attribute name="OSRevisionText">info here</sw-attribute>
<sw-attribute name="TrustStatus">false</sw-attribute>
L <sw-attribute name="AssetNumber">your data here</sw-attribute>
L <sw-attribute name="Contact">your data here</sw-attribute>
L <sw-attribute name="Location">your data here</sw-attribute>
L <sw-attribute name="PreferredNodeName">your data here</sw-attribute>
L <sw-attribute name="SysDescription">your data here</sw-attribute>
L <sw-attribute name="OSDescription">your data here</sw-attribute>
<sw-attribute name="OSNameStr">OS name str</sw-attribute>
<sw-attribute name="OSVendor">OS vendor info</sw-attribute>
<sw-attribute name="IPAddress">0.0.0.0</sw-attribute>
<sw-attribute name="ProtocolSupport">SNMP:1.0</sw-attribute>
<sw-attribute name="discovery.source">Ping</sw-attribute>
LF <sw-attribute name="DefaultProtoSettings">false</sw-attribute>
LF <sw-attribute name="DefaultAttributeSettings">false</sw-attribute>
LF <sw-attribute name="DefaultSystemName">false</sw-attribute>
</node>
</node-list>
As an example, let's say you wanted to change the 'PreferredNodeName'
attribute for a particular system/node via the mxnode CLI. You want
to change the system name from "abc" to "LABabc" to signify that this
system is a Lab system. You would first dump the XML for the node via
a 'mxnode -lf >filename' command. You could then manually edit the
output file. You could either leave all the current attributes as is
in the file, or remove all attributes except for the
'PreferredNodeName' attribute (if it does not exist, you will need to
add it). The following example shows what the XML file could look
like if you wanted to change the PreferredNodeName attribute for node
abc. You could then use the XML file as the input for the 'mxnode -m
-f filename' node modify command. Note that the example XML also has
set all 3 attribute lock flags to 'false' as we want the
PreferredNodeName attribute to not be over written by the Discovery or
Identification process. This same process could be used to change any
of the other attributes, or change and lock any of the lockable
attributes.
<?xml version="1.0" encoding="windows-1252"?>
<node-list>
<node name="abc">
<sw-attribute name="PreferredNodeName">LABabc</sw-attribute>
<sw-attribute name="DefaultProtoSettings">false</sw-attribute>
<sw-attribute name="DefaultAttributeSettings">false</sw-attribute>
<sw-attribute name="DefaultSystemName">false</sw-attribute>
</node>
</node-list>
To restore the Preferred node name back to the original 'discovered'
node name, simply set the PreferredNodeName attribute to the same
value 'name=' value as shown in the node element. This 'name=' value
for the node/system will always be the original 'discovered' name. To
Restore the preferred node name back to its original 'discovered'
value using the above example, you could do the following.
<?xml version="1.0" encoding="windows-1252"?>
<node-list>
<node name="abc">
<sw-attribute name="PreferredNodeName">abc</sw-attribute>
<sw-attribute name="DefaultProtoSettings">false</sw-attribute>
<sw-attribute name="DefaultAttributeSettings">false</sw-attribute>
<sw-attribute name="DefaultSystemName">false</sw-attribute>
</node>
</node-list>
NODE PROXY/MANAGEMENT PATHS (MPO)
A node may have zero or more management paths associated with it.
Node management paths (MPOs - Management Path Objects) are created to
assist WBEM CIMOM protocol identification as well as other 'proxy'
type based management. When dealing with CIMOMs and the other sources
of management data that may not come directly from a node itself, a
proxy type MPO will be added to the node by identification. This MPO
must be able to define and handle the WMI mapper and SMI-S based
CIMOMs as proxies to a storage device that does not support a network
connection. The MPO must also be able to support defining a path to
obtain SNMP data for a server via an iLO for cases where a server is
in a DMZ with the iLO on a management network.
The two types of MPOs that may possibly reside on a node are a
Management Agent type (MAO), and Management Route type (MRO).
The purpose of the MAO type is to define and support a management
agent such as a CIMOM on SNMP agent. The MAO contains information
specific to accessing the agent, which includes attributes such as
agent type, port number and IP address by which it was accessed.
The purpose of the MRO type is to provide information required to
access an agent (MAO). An MRO will always have an associated MAO
included within its overall information. A MRO residing on a given
node will either point to a MAO residing on the same node, or may
point to a MAO residing on some other node.
MPO = Management Path Object (MRO or MAO)
MRO = Management Route Object (Points to an MAO)
MAO = Management Agent Object (Agent, Proxy, CIMOM)
The following example node XML listing shows a node with one MAO and
one MRO residing on the node. A node's MPOs will be included in the
XML within the <managementpath-list> block. Within this list block,
each MPO will be included in its own <managementpath> block, whereby a
'mpotype' atribute will define either a MRO type MPO, or a MAO type
MPO. Note that the MRO in the following sample XML has an associated
MAO that resides on some other system.
<?xml version="1.0" encoding="windows-1252"?>
<node-list>
.-<node name="abc" guid="..." host-name="..." monitoring="resume">
| <hw-attribute name="DeviceType">Server</hw-attribute>
| <sw-attribute name="PreferredNodeName">abc</sw-attribute>
| <sw-attribute name="OverallStatus">NORMAL</sw-attribute>
| <sw-attribute name="IPAddress">nn.nn.nnn.nn</sw-attribute>
| <sw-attribute name="ProtocolSupport">WBEM:1.0</sw-attribute>
| <sw-attribute name="ProtocolSupport">SNMP:1.0</sw-attribute>
| <sw-attribute name="discovery.source">Ping</sw-attribute>
| <sw-attribute name="DefaultProtoSettings">true</sw-attribute>
| <sw-attribute name="DefaultAttributeSettings">true</sw-attribute>
| <sw-attribute name="DefaultSystemName">true</sw-attribute>
| .-<managementpath-list totalmpos="2">
| | .-<managementpath mpotype="MAO" mpoversion="1.0" maotype="WBEM_CIMOM" location="OnThisNode">
| | | <nodeguid>nn...nn</nodeguid>
| | | <nodename>abc</nodename>
| | | <proxytype>WBEM_CIMOM</proxytype>
| | | <portnumber>nnnn</portnumber>
| | | <ipaddress>nn.nn.nnn.nn</ipaddress>
| | | <protocol>https</protocol>
| | | <maoluid>nnnnnnnnnnn</maoluid>
| | | <interopnamespace>interop</interopnamespace>
| | | <profilelist>
| | | <profilename>Array</profilename>
| | | <profilename>Server</profilename>
| | | </profilelist>
| | | <functionalprofilelist>
| | | <profilename>Basic Read</profilename>
| | | <profilename>Basic Write</profilename>
| | | </functionalprofilelist>
| | `-</managementpath>
| | .-<managementpath mpotype="MRO" mpoversion="1.0">
| | | <catagoryname>hpmxCimomMro</catagoryname>
| | | <mroluid>nnnnnnnnnnn</mroluid>
| | | <profilelist>
| | | <profilename>Switch</profilename>
| | | </profilelist>
| | | <namespace>root</namespace>
| | | <cimcspath>....</cimcspath>
| | | <associatedmaoguid>nn...nn</associatedmaoguid>
| | | <associatedmaoluid>nnnnnnnnnnn</associatedmaoluid>
| | | .-<managementagent mpotype="MAO" maotype="WBEM_CIMOM" location="OnOtherNode">
| | | | <nodeguid>nn...nn</nodeguid>
| | | | <nodename>dpiwin5</nodename>
| | | | <proxytype>WBEM_CIMOM</proxytype>
| | | | <portnumber>nnnn</portnumber>
| | | | <ipaddress>nn.nn.nnn.nn</ipaddress>
| | | | <protocol>https</protocol>
| | | | <maoluid>nnnnnnnnnnn</maoluid>
| | | | <interopnamespace>interop</interopnamespace>
| | | | <profilelist />
| | | | <functionalprofilelist />
| | | `-</managementagent>
| | `-</managementpath>
| `-</managementpath-list>
`-</node>
</node-list>
MPO XML ELEMENTS and ATTRIBUTES
As defined in the DTD, the node XML file may contain the following MPO
related elements and information.
The <managementpath-list> element must appear once in a node XML file
and wraps the list of associated MPO information for the node. The
<managementpath-list> element supports one attribute called
"totalmpos" and is provided only as an informational numerical
attribute when listing mxnode data as XML, and shows the total number
of MPOs (MROs and MAOs) listed in the XML. This attribute is not
required when adding or modifying MPO data for a given node. The
<managementpath-list> element may contain zero or more
<managementpath> element blocks, which define each MRO or MAO that is
associated with this node.
The <managementpath> element supports several possible attributes.
The "mpotype" attribute is required and specifies the type of MPO
defined within the managementpath block. Valid values for this
attribute are "MRO" or "MAO".
The "mpoversion" attribute is required and specifies the MPO version.
When creating a new MRO or MAO, a value of 1.0.0 may be used as the
default.
The "location" attribute is provided only as an informational MAO
attribute when listing mxnode data as XML. The value for this
attribute can either be "OnThisNode" or "OnOtherNode", and thus
provides a quick method for determining whether this MAO actually
resides on this node or some other remote node. This attribute is not
required when adding or modifying an MAO.
The "maotype" attribute is required and specifies the MAO type only
for a MAO type <managementpath> XML data block. An MRO
<managementpath> type XML data block does not require an "maotype"
attribute. An "maotype" attribute defines the proxy type for this
particular MAO. Valid values for the "maotype" attribute are
"WMI_MAPPER", "WBEM_CIMOM", "SNMP_PROXY" or "SSH_PROXY".
ALL MAO XML ELEMENTS and ATTRIBUTES
The following is a sample XML MAO (Management Agent) type
<managementpath> element block and may be used as a reference for the
following MAO element discussion.
<managementpath mpotype="MAO" mpoversion="1.0" maotype="WBEM_CIMOM" location="OnThisNode">
<nodeguid>nn...nn</nodeguid>
<nodename>abc</nodename>
<proxytype>WBEM_CIMOM</proxytype>
<portnumber>nnnn</portnumber>
<ipaddress>nn.nn.nnn.nn</ipaddress>
<protocol>https</protocol>
<maoluid>nnnnnnnnnnn</maoluid>
<interopnamespace>interop</interopnamespace>
<profilelist>
<profilename>Array</profilename>
<profilename>Server</profilename>
</profilelist>
<functionalprofilelist>
<profilename>Basic Read</profilename>
<profilename>Basic Write</profilename>
</functionalprofilelist>
</managementpath>
The following XML elements are defined for the MAO <managementpath>
block when it is declared as an MAO type block via the "mpotype"
attribute (mpotype="MAO").
The <nodeguid> element specifies the GUID of the node this MAO is
residing on. This element is included in the MAO block when a -lf
option is executed, but is not required when adding or modifying a
node's MPOs, and if present, will be ignored.
The <nodename> element specifies the Name of the node this MAO is
residing on. This element is included in the MAO block when a -lf
option is executed, but is not required when adding or modifying a
node's MPOs, and if present, will be ignored.
The <proxytype> element specifies the MAO type and is required. Valid
values for this attribute are "WMI_MAPPER", "WBEM_CIMOM", "SNMP_PROXY"
or "SSH_PROXY".
The <portnumber> element specifies the port number this MAO operates
on.
The <ipaddress> element specifies the IP address used to communicate
with the MAO (Proxy CIMOM).
The <protocol> element specifies the protocol to use to communicate
with the MAO. Valid values for this attribute include "http",
"https", etc.
The <maoluid> element specifies the unique numerical LUID value for
this MAO.
The <interopnamespace> element specifies the namespace within the
target WEBEM Server where the CIM Interop Schema can be accessed.
The <profilelist> element specifies zero or more profiles supported by
this MAO (CIMOM, WBEM Server). The list may include sub profiles.
The profile(s) are specified by one or more <profilename> sub elements
residing within the <profilelist> block.
The <functionalprofilelist> element specifies zero or more functional
profiles supported by this MAO (CIMOM, WBEM Server). The profile(s)
are specified by one or more <profilename> sub elements residing
within the <functionalprofilelist> block.
ALL MRO XML ELEMENTS and ATTRIBUTES
The following is a sample XML MRO (Management Route) type
<managementpath> element block and may be used as a reference for the
following MRO element discussion. Note that the MRO's associated MAO
<managementagent> data block is embedded within the MRO
<managementpath> block.
<managementpath mpotype="MRO" mpoversion="1.0">
<catagoryname>hpmxCimomMro</catagoryname>
<mroluid>nnnnnnnnnnn</mroluid>
<profilelist>
<profilename>Switch</profilename>
</profilelist>
<namespace>root</namespace>
<cimcspath>....</cimcspath>
<associatedmaoguid>nn...nn</associatedmaoguid>
<associatedmaoluid>nnnnnnnnnnn</associatedmaoluid>
<managementagent mpotype="MAO" maotype="WBEM_CIMOM" location="OnOtherNode">
<nodeguid>nn...nn</nodeguid>
<nodename>dpiwin5</nodename>
<proxytype>WBEM_CIMOM</proxytype>
<portnumber>nnnn</portnumber>
<ipaddress>nn.nn.nnn.nn</ipaddress>
<protocol>https</protocol>
<maoluid>nnnnnnnnnnn</maoluid>
<interopnamespace>interop</interopnamespace>
<profilelist />
<functionalprofilelist />
</managementagent>
</managementpath>
</managementpath>
The following XML elements are defined for the MRO <managementpath>
block when it is declared as an MRO type block via the "mpotype"
attribute (mpotype="MRO").
The <catagoryname> element specifies a category for this MRO. This
element value is set internally and is not required when adding or
modifying a MRO.
The <mroluid> element specifies the unique numerical LUID value for
this MRO.
The <profilelist> element specifies zero or more profiles supported by
this MRO. The profile(s) are specified by one or more <profilename>
sub elements residing within the <profilelist> block.
The <namespace> element specifies the namespace for the MRO.
The <cimcspath> element specifies the source CIM Computer Space path
object that this node points to.
The <associatedmaoguid> element specifies the unique numerical GUID
value for the associated MAO. This element is not required when
adding or modifying a MRO.
The <associatedmaoluid> element specifies the unique numerical LUID
value for the associated MAO, and is required when adding or modifying
an MRO.
The <managementagent> element is an XML data block that specifies the
details of the MAO that's associated with this MRO. This
<managementagent> block is identical to the previously described MAO
XML ELEMENTS and ATTRIBUTES section. This entire element block is not
required when adding or modifying a MRO.
DETECTING ADD/REMOVE OPERATION FOR MPOs
Logic internal to the mxnode CLI scans the <managementpath-list>
section and attempts to determine which <managementpath> blocks are to
be added, modified or removed.
If a MRO <managementpath> block contains a <mroluid> element with a
valid MRO LUID value, then a Modification operation on that MRO will
be performed. Else if there is no <mroluid> element present in the
MRO <managementpath> block, or if the LUID is invalid, then a Add
operation will be performed.
If an MAO <managementpath> block contains a <maoluid> element with a
valid MAO LUID value, then a Modification operation on that MAO will
be performed. Else if there is no <maoluid> element present in the
MAO <managementpath> block, or the LUID is invalid, then an Add
operation will be performed.
ADDING AN MAO VIA XML
To add an MAO to a node, do not include an MAO LUID element/value as
shown in the example XML below. All the elements shown below should
be included within the XML, along with valid values.
<managementpath mpotype="MAO" mpoversion="1.0" maotype="WBEM_CIMOM">
<proxytype>WBEM_CIMOM</proxytype>
<portnumber>nnnn</portnumber>
<ipaddress>nn.nn.nnn.nn</ipaddress>
<protocol>https</protocol>
<interopnamespace>interop</interopnamespace>
<profilelist>
<profilename>Array</profilename>
</profilelist>
<functionalprofilelist>
<profilename>Basic Read</profilename>
</functionalprofilelist>
</managementpath>
MODIFYING AN MAO VIA XML
To modify an MAO on a node, include a valid MAO LUID element/value as
shown in the example XML below. A valid MAO LUID value could have
been gathered from running an "mxnode -lf nodename >xmlfilename"
command on a particular node and piping the XML to an external file,
editing the file (editing those element values that require changes)
and then feeding the file back into an "mxnode -m -p -f xmlfilename"
'modify' command. Also, any elements/values omitted from the MAO
block will not be modified.
<managementpath mpotype="MAO" mpoversion="1.0" maotype="WBEM_CIMOM">
<proxytype>WBEM_CIMOM</proxytype>
<portnumber>nnnn</portnumber>
<ipaddress>nn.nn.nnn.nn</ipaddress>
<protocol>https</protocol>
<maoluid>nnnnnnnnnnn</maoluid>
<interopnamespace>interop</interopnamespace>
<profilelist>
<profilename>Array</profilename>
</profilelist>
<functionalprofilelist>
<profilename>Basic Read</profilename>
</functionalprofilelist>
</managementpath>
ADDING AN MRO VIA XML
To add an MRO to a node, do not include an MRO LUID element/value as
shown in the example XML below. Be sure the <associatedmaoluid> value
is a valid LUID for an existing MAO residing on this node or some
other remote node.
<managementpath mpotype="MRO" mpoversion="1.0">
<profilelist>
<profilename>Switch</profilename>
</profilelist>
<namespace>root</namespace>
<cimcspath>....</cimcspath>
<associatedmaoluid>nnnnnnnnnnn</associatedmaoluid>
</managementpath>
MODIFYING AN MRO VIA XML
To modify an MRO on a node, include a valid MRO LUID element/value as
shown in the example XML below. A valid MRO LUID value could have
been gathered from running an "mxnode -lf nodename >xmlfilename"
command on a particular node and piping the XML to an external file,
editing the file and then feeding the file back into an "mxnode -m -p
-f xmlfilename" 'modify' command. Any elements/values omitted from
the MRO block will not be modified. Be sure the <associatedmaoluid>
value is a valid LUID for an existing MAO residing on this node or
some other remote node.
<managementpath mpotype="MRO" mpoversion="1.0">
<mroluid>nnnnnnnnnnn</mroluid>
<profilelist>
<profilename>Switch</profilename>
</profilelist>
<namespace>root</namespace>
<cimcspath>....</cimcspath>
<associatedmaoluid>nnnnnnnnnnn</associatedmaoluid>
</managementpath>
REMOVING AN MRO OR MAO VIA
Use the -p (prune) option and omit those MPOs from the XML that are to
be removed from the node. For each MAO that will be removed, all
associated MROs (MROs that may be pointing to this now removed MAO)
residing on other nodes will also be automatically found and removed.
MANAGEMENT PATH NOTES
The following notes may help when adding, modifying, listing or
removing node MPOs via XML.
Adding, modifying or removing MPO data for a given node is available
only via the mxnode CLI 'modify' option whereby the MPO data is
provided via XML input. Adding, modifying or removing MPOs is not
available directly on the mxnode CLI command line.
To Add, Modify or Remove any MPOs for a particular node, ONLY the
Modify ('-m') option may be used to perform the said MPO tasks.
Internal mxnode logic will determine whether the Add or Modify
operation will be performed on any MPOs residing within the XML based
of the existance or non-existance of an <maoluid> or <mroluid> element
and valid value. Either of the following mxnode command line formats
will allow for adding or modifying of a node's MPOs.
>mxnode -mf xmlfilename
>mxnode -m -f filename
>mxnode -m -p -f filename (prune option specified - must precede '-f')
To Add a node(s) with one or more specified MPOs, you would first
perform an "mxnode -af filename" to add the node to the system via
XML. Any MPO data residing within the node XML will be ignored during
the Add operation. Once the node(s) has been successfully added, you
would then perform a "mxnode -mf filename" command, using the same xml
file used in the add operation. The MPO data residing within the XML
would then be honored, and the MPO(s) would be added for the
associated node(s). This two-phase operation is required because MPO
addition/modification can only be performed on an existing node(s).
Do this first: mxnode -af filename.xml
Then this: mxnode -mf filename.xml
When the "mxnode -a -f filename" Add command or the "mxnode -r -f
filename" Remove command is used to Add/Remove a node via XML file,
then any existing MPO data residing in the input XML is ignored!
If an <mroluid> element is not present within an MRO section, then an
Add operation will be performed on that MRO.
If an <maoluid> element is not present within an MAO section, then an
Add operation will be performed on that MAO.
If an <mroluid> element is present within an MRO section, but this MRO
does not exist within the node's MPO list, then an Add operation will
be performed on that MRO.
If an <maoluid> element is present within an MAO section, but this MAO
does not exist within the node's MPO list, then an Add operation will
be performed on that MAO.
If an <mroluid> is present within an MRO section, and this MRO does
exist within the node's MPO list, then a Modify operation will be
performed on that MRO.
If an <maoluid> is present within an MAO section, and this MAO does
exist within the node's MPO list, then a Modify operation will be
performed on that MAO.
To Remove any MPO(s) for a particular node, the '-p' (Prune) option
MUST also be specified along with the '-m' (Modify) option. The '-p'
option tells the CLI that it's ok to remove those MPO(s) that are
currently assigned to the node, but have been omitted from the XML.
In other words, the '-p' option says: "Prune those MPOs that have been
omitted from the specified XML or XML file". Those MPOs that you wish
to remain associated with the node must reside within the XML.
When using the '-p' option with the "mxnode -m -f filename" command,
the format and order for the options on the command line must look as
follows, with the '-p' option coming before the '-f' option.
mxnode -m -p -f filename
Warning! Be careful when using the -p (Prune) option for MPOs. For
example, if you want to add one MPO to a particular node and the XML
includes only the MPO data for that one node in the XML, then any/all
other MPOs that may be associated with that node will be removed, if
the -p option was include in the command line! Only use the -p prune
option when you really want to remove one or more MPOs from a node.
When only adding or modifying MPOs for a node(s), do NOT include the
-p option.
When adding or modifying an MRO (Management Route), any MAO data
residing within the associated <managementagent> block is ignored.
The reason is for this behavior is that the associated MAO may reside
on some other node, and the MRO is simply 'pointing' to that MAO. To
actually modify the associated MAO, the node that the MAO resides on
would have to be modified. In other words, an MAO can only be added
or modified when defined within its own XML <managementpath> block.
When modifying the <profilelist> element or <functionalprofilelist>
element for either a MRO or MAO, a <profilename> can be removed by
simply omitting it from within the XML <profilelist> block or the
<functionalprovilelist> element block.
You can modify the associated MAO LUID (intent is for the MRO to point
to a different MAO), for an existing MRO. Note that the associated
<managementagent> block may or may not exist within the XML. When
modifying an MRO, the associated MAO <managementagent> block, if
present, is ignored.
When modifying MPOs, the <managementpath-list> element attribute
<totalmpos> is ignored. You can either leave it in the XML, or remove
it.
Note that if an <maoluid> is present within a particular MAO block,
but this MAO cannot be found in the node's current MPO list, then an
Add operation will be assumed and automatically performed. The same
holds true for an <mroluid> that may be present within an MRO block,
but cannot be found in the node's current MPO list. It too will then
be automatically added to the node.
When a node is removed via the -r -f option, all MROs and MAOs
associated with that node will also be removed. For removed MAOs,
this also includes the removal of any associated MROs that may be
residing on other nodes. Any MRO or MAO data residing within the XML
is ignored during the node(s) removal operation.
EXAMPLE NODE XML CONTAINING MPO DATA
The following XML example shows how to add an MAO to a node. Note
that the Add operation is triggered by the fact that there is no
<maoluid> element present in the MAO <managementpath> block. Also note
that the <nodeguid> and <nodename> elements will be ignored, and that
they could be removed if desired.
<?xml version="1.0" encoding="windows-1252"?>
<node-list>
<node name="abc" guid="..." host-name="..." monitoring="resume">
<hw-attribute name="DeviceType">Server</hw-attribute>
<sw-attribute name="PreferredNodeName">abc</sw-attribute>
<sw-attribute name="OverallStatus">NORMAL</sw-attribute>
<sw-attribute name="IPAddress">nn.nn.nnn.nn</sw-attribute>
<sw-attribute name="ProtocolSupport">WBEM:1.0</sw-attribute>
<sw-attribute name="ProtocolSupport">SNMP:1.0</sw-attribute>
<sw-attribute name="discovery.source">Ping</sw-attribute>
<sw-attribute name="DefaultProtoSettings">true</sw-attribute>
<sw-attribute name="DefaultAttributeSettings">true</sw-attribute>
<sw-attribute name="DefaultSystemName">true</sw-attribute>
<managementpath-list totalmpos="1">
<managementpath mpotype="MAO" mpoversion="1.0" maotype="WBEM_CIMOM">
<nodeguid>nn...nn</nodeguid>
<nodename>abc</nodename>
<proxytype>WBEM_CIMOM</proxytype>
<portnumber>nnnn</portnumber>
<ipaddress>nn.nn.nnn.nn</ipaddress>
<protocol>https</protocol>
<maoluid>nnnnnnnnnnn</maoluid>
<interopnamespace>interop</interopnamespace>
<profilelist>
<profilename>Array</profilename>
<profilename>Server</profilename>
</profilelist>
<functionalprofilelist>
<profilename>Basic Read</profilename>
<profilename>Basic Write</profilename>
</functionalprofilelist>
</managementpath>
</managementpath-list>
</node>
</node-list>
The following XML example shows how to add an MRO to a node. Note
that the Add operation is triggered by the fact that there is no
<mroluid> element present in the MRO <managementpath> block. Also be
aware that the <associatedmaoluid> value must be valid, that is, this
particular MAO must already reside either on this node or some other
remote node. Also, in this particular example, the <managementagent>
element block does exist, however, note that it is ignored, and could
in fact be removed if desired. The <catagoryname> element, the
<associatedmaoguid> element and the "totalmpos" attribute are also
ignored, and could in fact be removed if desired. You would use the
following mxnode command for an already existing node.
mxnode -m -f xmlfilename
<?xml version="1.0" encoding="windows-1252"?>
<node-list>
<node name="abc" guid="..." host-name="..." monitoring="resume">
<hw-attribute name="DeviceType">Server</hw-attribute>
<sw-attribute name="PreferredNodeName">abc</sw-attribute>
<sw-attribute name="OverallStatus">NORMAL</sw-attribute>
<sw-attribute name="IPAddress">nn.nn.nnn.nn</sw-attribute>
<sw-attribute name="ProtocolSupport">WBEM:1.0</sw-attribute>
<sw-attribute name="ProtocolSupport">SNMP:1.0</sw-attribute>
<sw-attribute name="discovery.source">Ping</sw-attribute>
<sw-attribute name="DefaultProtoSettings">true</sw-attribute>
<sw-attribute name="DefaultAttributeSettings">true</sw-attribute>
<sw-attribute name="DefaultSystemName">true</sw-attribute>
<managementpath-list totalmpos="1">
<managementpath mpotype="MRO" mpoversion="1.0">
<catagoryname>hpmxCimomMro</catagoryname>
<profilelist>
<profilename>Switch</profilename>
</profilelist>
<namespace>root</namespace>
<cimcspath>....</cimcspath>
<associatedmaoguid>nn...nn</associatedmaoguid>
<associatedmaoluid>nnnnnnnnnnn</associatedmaoluid>
<managementagent mpotype="MAO" maotype="WBEM_CIMOM" location="OnOtherNode">
<nodeguid>nn...nn</nodeguid>
<nodename>dpiwin5</nodename>
<proxytype>WBEM_CIMOM</proxytype>
<portnumber>nnnn</portnumber>
<ipaddress>nn.nn.nnn.nn</ipaddress>
<protocol>https</protocol>
<maoluid>nnnnnnnnnnn</maoluid>
<interopnamespace>interop</interopnamespace>
<profilelist />
<functionalprofilelist />
</managementagent>
</managementpath>
</managementpath-list>
</node>
</node-list>
The following XML example shows how to add an MRO to a node, and is
the same at the previous example, except all the non-required MPO
elements and attributes have been removed. You would use the
following mxnode command for an already existing node.
mxnode -m -f xmlfilename
<?xml version="1.0" encoding="windows-1252"?>
<node-list>
<node name="abc" guid="..." host-name="..." monitoring="resume">
<hw-attribute name="DeviceType">Server</hw-attribute>
<sw-attribute name="PreferredNodeName">abc</sw-attribute>
<sw-attribute name="OverallStatus">NORMAL</sw-attribute>
<sw-attribute name="IPAddress">nn.nn.nnn.nn</sw-attribute>
<sw-attribute name="ProtocolSupport">WBEM:1.0</sw-attribute>
<sw-attribute name="ProtocolSupport">SNMP:1.0</sw-attribute>
<sw-attribute name="discovery.source">Ping</sw-attribute>
<sw-attribute name="DefaultProtoSettings">true</sw-attribute>
<sw-attribute name="DefaultAttributeSettings">true</sw-attribute>
<sw-attribute name="DefaultSystemName">true</sw-attribute>
<managementpath-list>
<managementpath mpotype="MRO" mpoversion="1.0">
<profilelist>
<profilename>Switch</profilename>
</profilelist>
<namespace>root</namespace>
<cimcspath>....</cimcspath>
<associatedmaoluid>nnnnnnnnnnn</associatedmaoluid>
</managementpath>
</managementpath-list>
</node>
</node-list>
The following XML example shows how to add two MROs and an MAO to a
node. Note that the second MRO and the MAO have no values for the
<profilelist> and the <functionalprofilelist> elements. Also note in
this particular example, the associated MAO <managementagent> element
blocks for both MROs have been omitted. You would use the following
mxnode command for an already existing node.
mxnode -m -f xmlfilename
<?xml version="1.0" encoding="windows-1252"?>
<node-list>
<node name="abc" guid="..." host-name="..." monitoring="resume">
<hw-attribute name="DeviceType">Server</hw-attribute>
<sw-attribute name="PreferredNodeName">abc</sw-attribute>
<sw-attribute name="OverallStatus">NORMAL</sw-attribute>
<sw-attribute name="IPAddress">nn.nn.nnn.nn</sw-attribute>
<sw-attribute name="ProtocolSupport">WBEM:1.0</sw-attribute>
<sw-attribute name="ProtocolSupport">SNMP:1.0</sw-attribute>
<sw-attribute name="discovery.source">Ping</sw-attribute>
<sw-attribute name="DefaultProtoSettings">true</sw-attribute>
<sw-attribute name="DefaultAttributeSettings">true</sw-attribute>
<sw-attribute name="DefaultSystemName">true</sw-attribute>
<managementpath-list>
<managementpath mpotype="MRO" mpoversion="1.0">
<profilelist>
<profilename>Switch</profilename>
</profilelist>
<namespace>root</namespace>
<cimcspath>....</cimcspath>
<associatedmaoluid>nnnnnnnnnnn</associatedmaoluid>
</managementpath>
<managementpath mpotype="MRO" mpoversion="1.1">
<profilelist />
<namespace>root</namespace>
<cimcspath>....</cimcspath>
<associatedmaoluid>nnnnnnnnnnn</associatedmaoluid>
</managementpath>
<managementpath mpotype="MAO" mpoversion="1.0" maotype="WBEM_CIMOM">
<proxytype>WBEM_CIMOM</proxytype>
<portnumber>nnnn</portnumber>
<ipaddress>nn.nn.nnn.nn</ipaddress>
<protocol>https</protocol>
<interopnamespace>interop</interopnamespace>
<profilelist />
<functionalprofilelist />
</managementpath>
</managementpath-list>
</node>
</node-list>
The following XML example shows how to modify an MRO and an MAO on a
node. Note that the MRO and the MAO do both have LUIDs defined, which
is an indicator that these MPOs already exist for this particular
node.
Do note however, that if an <maoluid> is present within a particular
MAO block, but this MAO cannot be found in the node's current MPO
list, then an Add operation will be assumed and automatically
performed. The same holds true for an <mroluid> that may be present
within an MRO block, but cannot be found in the node's current MPO
list. It too will then be automatically added to the node. You would
use the following mxnode command for an already existing node.
mxnode -m -f xmlfilename
<?xml version="1.0" encoding="windows-1252"?>
<node-list>
<node name="abc" guid="..." host-name="..." monitoring="resume">
<hw-attribute name="DeviceType">Server</hw-attribute>
<sw-attribute name="PreferredNodeName">abc</sw-attribute>
<sw-attribute name="OverallStatus">NORMAL</sw-attribute>
<sw-attribute name="IPAddress">nn.nn.nnn.nn</sw-attribute>
<sw-attribute name="ProtocolSupport">WBEM:1.0</sw-attribute>
<sw-attribute name="ProtocolSupport">SNMP:1.0</sw-attribute>
<sw-attribute name="discovery.source">Ping</sw-attribute>
<sw-attribute name="DefaultProtoSettings">true</sw-attribute>
<sw-attribute name="DefaultAttributeSettings">true</sw-attribute>
<sw-attribute name="DefaultSystemName">true</sw-attribute>
<managementpath-list>
<managementpath mpotype="MRO" mpoversion="1.0">
<mroluid>nnnnnnnnnnn</mroluid>
<profilelist>
<profilename>Switch</profilename>
</profilelist>
<namespace>root</namespace>
<cimcspath>....</cimcspath>
<associatedmaoluid>nnnnnnnnnnn</associatedmaoluid>
</managementpath>
<managementpath mpotype="MAO" mpoversion="1.0" maotype="WBEM_CIMOM">
<proxytype>WBEM_CIMOM</proxytype>
<portnumber>nnnn</portnumber>
<ipaddress>nn.nn.nnn.nn</ipaddress>
<protocol>https</protocol>
<maoluid>nnnnnnnnnnn</maoluid>
<interopnamespace>interop</interopnamespace>
<profilelist />
<functionalprofilelist />
</managementpath>
</managementpath-list>
</node>
</node-list>
The following XML example shows how to remove, or prune all MROs and
MAOs from a node. Note that any MROs or MAOs omitted from the XmL
will be removed from the node, and in this example, the
<managementpathlist> is empty. Be careful using the -p option. You
would use the following mxnode command for an already existing node.
mxnode -m -p -f xmlfilename
<?xml version="1.0" encoding="windows-1252"?>
<node-list>
<node name="abc" guid="..." host-name="..." monitoring="resume">
<hw-attribute name="DeviceType">Server</hw-attribute>
<sw-attribute name="PreferredNodeName">abc</sw-attribute>
<sw-attribute name="OverallStatus">NORMAL</sw-attribute>
<sw-attribute name="IPAddress">nn.nn.nnn.nn</sw-attribute>
<sw-attribute name="ProtocolSupport">WBEM:1.0</sw-attribute>
<sw-attribute name="ProtocolSupport">SNMP:1.0</sw-attribute>
<sw-attribute name="discovery.source">Ping</sw-attribute>
<sw-attribute name="DefaultProtoSettings">true</sw-attribute>
<sw-attribute name="DefaultAttributeSettings">true</sw-attribute>
<sw-attribute name="DefaultSystemName">true</sw-attribute>
<managementpath-list />
</node>
</node-list>
GENERAL NOTES
(1) When modifying a node via the -m -f <filename> command, you only
need to include those attributes that you wish to modify within the
XML file. However, you must always include the 3 attribute lock flags
and set all 3 attribute lock flags to either 'true' or 'false'. Most
likely, you'll want the latter setting (false) so that the lockable
attributes will not be over written whenever the Discovery and
Identification processes run on the particular system/node.
(2) The only way to clear a particular system/node attribute using the
mxnode -m -f <filename> command, is to include that attribute in the
XML file and provide a value for that attribute of 1 space character.
(3) Including a software type attribute within the XML file that is
not a pre-defined attribute will still be accepted by mxnode during a
system 'modify' operation (-m -f <filename>) command. This 'user-
defined' type attribute will also be persistant and remain in the
repository as an associated node attribute, even if Discovery or
Identification is run on the node. However, it is not recommended to
add user-defined node attributes via an edited XML file as this
ability to include user-defined attributes for a node is intended for
other applications support. This may help explain why non pre-defined
system attributes may be visible via -lf option at times with a
particluar node(s).
(4) Although any system/node attribute may be modified via an XML
file, only a limited set of all pre-defined system attributes may be
additionally locked or protected from being over written by the
Discovery or Identification processes. See preceding documentation for
a complete list of those system attributes that may be modified AND
locked.
(5) The mxnode CLI does provide a way through the XML to 'Restore' the
preferred node name back to the original 'discovered' node name. See
above section on example XML files.
LIMITATIONS
This command may only be run on the CMS.
AUTHOR
mxnode was developed by the Hewlett-Packard Company.
SEE ALSO for HP-UX
mxnode(1M)
SEE ALSO for Linux
mxnode(8)