HP Moonshot 1500 Chassis, ProLiant Moonshot Server Cartridge User Manual
HP iLO Chassis Management IPMI User Guide
Abstract
This document provides customers with information on the implementation of the Intelligent Platform Management Interface in
HP Moonshot iLO Chassis Management Firmware, including the available commands.
HP Part Number: 742544-003
Published: November 2014
Edition: 1
© Copyright 2014
Notices
Confidential computer software. Valid license from HP required for possession, use, or copying. Consistent with FAR 12.211 and 12.212, Commercial
Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under
vendor's standard commercial license.
The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express
warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall
not be liable for technical or editorial errors or omissions contained herein.
Contents
1 Introduction and key concepts......................................................................7
Overview................................................................................................................................7
Sensor Data Model...................................................................................................................7
Sensor owner identification...................................................................................................7
Sensor type code.................................................................................................................8
System event log and event messages.....................................................................................8
SDR repository..................................................................................................................10
SDR formats.................................................................................................................10
Reading the SDR repository and device SDR repositories....................................................11
FRU......................................................................................................................................11
FRU inventory device..........................................................................................................12
Standardized timers................................................................................................................12
Watchdog timer................................................................................................................12
POH counter.....................................................................................................................12
Timestamp format...............................................................................................................12
2 The virtual topology of the Moonshot 1500 CM module................................14
3 Discovering managed entities using IPMITool................................................17
4 IPMItool..................................................................................................18
Moonshot IPMItool support — out of band.................................................................................18
Interfaces...............................................................................................................................19
System Interface.................................................................................................................19
LANPlus Interface...............................................................................................................19
Features................................................................................................................................20
Events...................................................................................................................................21
Inventory...............................................................................................................................22
Chassis management..............................................................................................................22
Synopsis................................................................................................................................22
IPMItool Raw command syntax and example..............................................................................24
5 Command specification.............................................................................25
Standard command specification..............................................................................................29
Global commands.............................................................................................................29
Get device ID command................................................................................................29
Cold reset command ....................................................................................................32
Warm reset command...................................................................................................33
Get self test results command .........................................................................................33
Get ACPI power state command .....................................................................................34
Broadcast get device ID command .................................................................................35
IPMI messaging support commands......................................................................................36
Set BMC global enables command .................................................................................36
Get BMC global enables command ................................................................................37
Clear message flags command ......................................................................................37
Get message flags command .........................................................................................38
Enable message channel receive command .....................................................................38
Get message command ................................................................................................39
Send message command...............................................................................................42
Get system GUID command ...........................................................................................44
Set system info parameters command ..............................................................................45
Get system info parameters command..............................................................................46
Master write-read command...........................................................................................49
Contents 3
Get channel authentication capabilities command.............................................................50
Get Channel Cipher Suites Command.............................................................................52
Cipher suite records..................................................................................................54
Cipher suite ID numbers............................................................................................55
Set session privilege level command ...............................................................................56
Close session command.................................................................................................57
Get session info command ............................................................................................57
Get AuthCode command ..............................................................................................59
Set channel access command ........................................................................................60
Get channel access command .......................................................................................62
Get channel info command ...........................................................................................63
Set user access command..............................................................................................65
Get user access command..............................................................................................66
Set user name command ...............................................................................................68
Get user name command...............................................................................................68
Set user password command..........................................................................................69
RMCP+ support and payload commands..............................................................................70
Activate payload command............................................................................................71
Deactivate payload command........................................................................................73
Suspend/resume payload encryption command................................................................74
Set channel security keys command.................................................................................75
Get system interface capabilities command.......................................................................77
Get payload activation status command...........................................................................78
Get payload instance info command...............................................................................79
Set user payload access command..................................................................................79
Get user payload access command.................................................................................80
Get channel payload support command...........................................................................81
Get channel payload version command...........................................................................82
IPMI LAN Device Commands...............................................................................................83
Set LAN configuration parameters command....................................................................83
Get LAN configuration parameters command...................................................................83
SOL commands.................................................................................................................92
Set SOL configuration parameters command.....................................................................92
Get SOL configuration parameters command....................................................................93
MC watchdog timer commands...........................................................................................96
Watchdog timer actions.................................................................................................96
Watchdog timer use field and expiration flags..................................................................97
Using the timer use field and expiration flags...............................................................97
Watchdog timer event logging........................................................................................97
Pre-timeout interrupt.......................................................................................................98
Pre-timeout interrupt support detection.........................................................................98
BIOS support for watchdog timer................................................................................98
Reset watchdog timer command .....................................................................................98
Set watchdog timer command ........................................................................................98
Get watchdog timer command .....................................................................................100
Chassis commands..........................................................................................................102
Get chassis capabilities command ................................................................................102
Get chassis status command ........................................................................................103
Chassis control command ............................................................................................104
Chassis identify command ...........................................................................................105
Set power restore policy command ...............................................................................106
Set system boot options command ................................................................................107
Get system boot options command................................................................................107
Get POH counter command .........................................................................................111
Event commands..............................................................................................................112
4 Contents
Set event receiver command.........................................................................................112
Get event receiver command........................................................................................113
Platform event message command.................................................................................113
SEL commands................................................................................................................114
SEL device commands..................................................................................................114
Get SEL info command............................................................................................114
Reserve SEL command............................................................................................115
Get SEL entry command..........................................................................................116
Add SEL entry command.........................................................................................116
Clear SEL...................................................................................................................117
SEL record type ranges................................................................................................117
Get SEL time command................................................................................................118
Set SEL time command.................................................................................................118
SDR repository device commands......................................................................................118
SDR record IDs...........................................................................................................118
Get SDR repository info command.................................................................................119
Get SDR repository allocation info command..................................................................120
Reserve SDR repository command.................................................................................120
Reservation restricted commands..............................................................................121
Reservation cancellation..........................................................................................121
Get SDR command......................................................................................................121
Add SDR command.....................................................................................................122
Delete SDR command..................................................................................................123
Clear SDR repository command....................................................................................123
Run initialization agent command..................................................................................124
FRU inventory device commands........................................................................................124
Get FRU inventory area info command...........................................................................125
Read FRU data command........................................................................................125
Write FRU data command.......................................................................................126
Sensor Device Commands.................................................................................................126
Get device SDR info command.....................................................................................126
Get device SDR command............................................................................................127
Reserve device SDR repository command.......................................................................128
Get sensor thresholds command....................................................................................128
Get sensor reading command.......................................................................................129
DCMI specific commands.................................................................................................130
Get DCMI capability info command..............................................................................131
Get asset tag command...............................................................................................133
Get DCMI sensor info command...................................................................................134
Set asset tag command................................................................................................135
Management controller ID string...................................................................................135
Get controller ID string command..................................................................................136
Set controller ID string command...................................................................................136
PICMG specific commands...............................................................................................137
Get PICMG properties command..................................................................................137
Get address info command..........................................................................................137
FRU inventory device lock control command....................................................................138
6 IPMI Messaging and Interfaces.................................................................140
System Interfaces..................................................................................................................140
Message interface description...........................................................................................141
IPMI Messaging Interfaces.................................................................................................141
Network function codes.........................................................................................................141
Completion codes.................................................................................................................142
Channel Model, Authentication, Sessions, and Users.................................................................144
Contents 5
Channel numbers.............................................................................................................145
Logical channels..............................................................................................................145
Channel Privilege Levels....................................................................................................145
Users & Password support.................................................................................................146
IPMI sessions...................................................................................................................146
Session-less connections....................................................................................................147
Session inactivity timeouts.................................................................................................147
System interface messaging...................................................................................................147
Bridging..............................................................................................................................148
MC LUN 10b..................................................................................................................148
Send Message command with response tracking..................................................................149
Bridged Request Example..................................................................................................149
IPMB access via master write-read command.......................................................................151
MC IPMB LUNs................................................................................................................151
Sending Messages to IPMB from system software.................................................................152
Keyboard Controller Style Interface.........................................................................................153
KCS Interface/MC LUNs...................................................................................................153
KCS Interface-MC Request message format..........................................................................153
MC-KCS Interface Response Message format.......................................................................153
LAN Interface.......................................................................................................................154
Remote Management Control Protocol (RMCP).....................................................................154
RMCP port numbers....................................................................................................154
RMCP Message Format................................................................................................155
Serial Over LAN (SOL)..........................................................................................................156
7 Support and other resources....................................................................157
Information to collect before contacting HP...............................................................................157
How to contact HP................................................................................................................157
HP authorized resellers..........................................................................................................157
Related information...............................................................................................................157
A Command Assignments...........................................................................159
B Verbose output examples.........................................................................164
Glossary..................................................................................................186
Index.......................................................................................................188
6 Contents
1 Introduction and key concepts
Overview
The term Intelligent Platform Management (IPMI), refers to autonomous monitoring and recovery
features implemented directly in platform management hardware and firmware. The key
characteristic of Intelligent Platform Management is that inventory, monitoring, logging, and recovery
control functions are available independently of the main processors, BIOS, and operating system.
Platform management functions are available even when the system is in a powered down state.
IPMI capabilities are a key component in providing enterprise-class management for HA systems.
Platform status information is obtained and recovery actions initiated under situations where system
management software and normal “in-band” management mechanisms are unavailable.
The independent monitoring, logging, and access functions available through IPMI provide a level
of manageability built-in to the platform hardware. This supports systems with no system management
software available for the particular operating system, or the end-user who elects not to load or
enable the system management software.
NOTE: The HP Moonshot-45G Switch Module does not support IPMI. Only the HP Moonshot iLO
Chassis Management Firmware supports IPMI.
Sensor Data Model
The IPMI Sensor Model provides access to monitored information including temperatures, voltages,
and fan status. Instead of providing direct access to the monitoring hardware, IPMI provides access
by abstracted sensor commands, such as the Get Sensor Reading command, implemented
via a management controller. This approach isolates software from changes in the platform
management hardware implementation. Sensors return analog or discrete readings and events
are either discrete or threshold-based. Sensors are classified according to:
• Type of readings
• Type of events
Event types, sensor types, and monitored entities are represented using numeric codes defined in
the IPMI specification. IPMI avoids reliance on strings for management information and using
numeric codes facilitates internationalization, automated handling by higher level software, and
reduces management controller code and data space requirements.
Sensor owner identification
The definition for the Request/Response identifier, Requester’s ID, and Responder’s ID are specific
to the particular messaging interface used. However, the SDR and SEL must contain information
to identify the owner of the sensor. For management controllers, a slave address and LUN identify
the owner of a sensor on the IPMB. For system software, a software ID identifies the sensor owner.
These fields are used in event messages, where events from management controllers or the IPMB
are identified by an eight-bit field where the upper 7 bits represent the slave address or the system
software ID. The least significant bit is 0 if the value represents a slave address and 1 if the value
represents a system software ID.
Sensor number is not part of the sensor owner ID, but is a separate field used to identify a particular
sensor associated with the sensor owner. This combination of sensor owner ID and sensor number
uniquely identify a sensor in the system.
Table 1 Sensor owner ID and sensor number field definition
System Sensor Owner IDIPMB Sensor Owner ID
system software ID (7 bits)7:1 slave address (7 bits)
Overview 7
Table 1 Sensor owner ID and sensor number field definition (continued)
System Sensor Owner IDIPMB Sensor Owner ID
0 1b (ID is a software ID)0 0b (ID is a slave address)
sensor number (8 bits, FFh = reserved)LUN (2 bits)
sensor number (1 bit, FFh = reserved)
In Moonshot: 0x82 IPMB address
Sensor type code
Each sensor has a sensor type code and are defined in “Some Moonshot sensor type codes”
(page 8). Sensor type codes are used both in SDRs and event messages. An example of a sensor
type code is code 0x1, which indicates a temperature sensor.
Table 2 Some Moonshot sensor type codes
This only appears in the system node SEL, where the it is
logged by the host system
Reading type codeSensor type codeSensor type
0x10x1Temperature
0xA0x4Fan
0xB0x4Fan redundancy
0x6F0xF1PICMG IPMB0 Physical Link
0x710xC0Health LED
0x700xC0UID LED
0x6F0x8Power supply
0xB0x8Power supply redundancy
For a complete listing of sensor type codes, see the IPMI specification available at:
http://www.intel.com/content/www/us/en/servers/ipmi/second-gen-interface-spec-v2.html
System event log and event messages
The MC provides a centralized, non-volatile SEL. Having the SEL and logging functions managed
by the MC helps ensure that post-mortem logging information is available should a failure occur
that disables the systems processor(s).
A set of IPMI commands allows the SEL to be read and cleared, and for events to be added to the
SEL. The common request message used for adding events to the SEL is an event message. Event
messages are sent to the MC via the IPMB providing the mechanism for satellite controllers to detect
events and log them into the SEL. The controller that generates an event message to another
controller via IPMB is the IPMB Event Generator. The controller receiving event messages is the
IPMB Event Receiver.
In Moonshot, event messages are sent to the zone manager by each cartridge and chassis controller.
There are two event logs, the SEL and the IML. There are OEM specific commands for obtaining
and displaying these logs. For more information, see the related commands in “Command
specification” (page 25).
8 Introduction and key concepts
Event messages are special messages sent by management controllers when they detect significant
or critical system management events. This includes messages for events such as:
• temperature threshold exceeded
• voltage threshold exceeded
• power fault
The event message generator notifies the system by sending an Event Request Message to
the event receiver device.
When the event receiver gets a valid event message, it sends a response message to the event
message generator which is typically transferred to the SEL. The event receiver does not interpret
event messages so that new event message types can be added into the system without impacting
event receiver implementation.
SEL commands — The SEL is a non-volatile repository for system events and some system
configuration information. The SEL device access the commands sent by the SEL. Event messages
when received by the event receiver device are written to the SEL.
Table 3 SEL event records
DescriptionFieldByte
Record ID1
2
5
6
7
Generator ID8
9
ID used for SEL record access. The Record ID values 0000h and FFFFh have special
meaning in the Even Access commands and must not be used as Record ID values
for stored SEL event records.
[7:0] — Record typeRecord type3
02h = system event record
C0h-DFh = OEM timestamped, bytes 8–16 OEM defined
E0h-FFh = OEM non-timestamped, bytes 4–16 OEM defined
Time when event was logged. LS byte first.Timestamp4
RqSA & LUN if event was generated from IPMB. Software ID if event was generated
from system software.
Byte 1
[7:1] — 7–bit I2C. Slave address, or 7–bit system software ID
[0] 0b = ID is IPMB slave address
1b = System software ID
Byte 2
[7:4] — Channel number. Channel that received the event message 0h if the event
message was received via the system interface, primary IPMB, or internally generated
by the MC.
[3.2] — Reserved. Write as 00b.
[1.0] — IPMB device LUN if byte 1 holds slave address, otherwise 00b.
EvM Rev10
Event message format version (=04h for events in this specification, 03h for IPMI
v1.0 event messages).
Sensor type code for sensor that generated the event.Sensor type11
Number of sensor that generated the event.Sensor #12
Event dirEvent dir 113
[7] — 0b = Assertion event.Event type
1b = Deassertion event.
1
Sensor Data Model 9
Table 3 SEL event records (continued)
1
The MC must accept Platform Event request messages that are in IPMI v1.0 format (EvM Rev=03h) and log them as IPMI
v1.5/v2.0 records by setting the EVMRev field to 04h and setting the channel number in the generator ID field
appropriately for the channel that received the event.
SDR repository
With IPMI’s extensibility and scalability each platform implementation can have a different
population of management controllers and sensors, and different event generation capabilities.
IPMI allows system management software to retrieve information from the platform and automatically
configure itself to the platform’s capabilities, enabling the use of plug and play, platform-independent
instrumentation software.
Information that describes the platform management capabilities is provided via two mechanisms:
DescriptionFieldByte
Event type
Type of trigger for the event, such as, a critical threshold going high or state asserted.
Also indicates class of the event. Example: discrete, threshold, or OEM. The event
type field is encoded using the event/reading type code.
Event request message, event data field contents.Event data 114
Event request message, event data field contents.Event data 215
Event request message, event data field contents.Event data 316
• Capability commands — these are commands within the IPMI command set that return
• SDRs — these contain information about the type and number of sensors in the platform, sensor
The primary purpose of SDRs is to describe the sensor configuration of the platform management
subsystem to system software. SDRs also include records describing the number and type of devices
connected to the system’s IPMB, records that describe the location and type of FRU Devices (devices
that contain field replaceable unit information).
SDRs are kept in a single, centralized, non-volatile storage area managed by the MC. This storage
area is the SDR repository. In Moonshot, the SDRR is kept by the zone manager; the remaining
controllers have device SDRs. Additional device SDRs are kept at the cartridge and system node
level. All SDR repositories provide a mechanism for information to be obtained independently from
the controller by the BIOS system management or remote management.
SDR formats
The general SDR format consists of three major components: the record header, record key fields,
and the record body. To save space, sensors that only generate events do not require SDRs, in
addition, generic system management software does not access sensors unless they are reported
by SDRs.
information on other commands and functions that the controller can handle.
threshold support, event generation capabilities, and sensor type readings.
10 Introduction and key concepts
Table 4 Sensor data record formats
Record bodyRecord Key fieldsRecord header
Record ID — a value used for
accessing sensor data records.
SDR version — version number of the
SDR specification.
Record type — a number representing
the type of record. Example, 01h =
8–bit sensor with thresholds.
Record length — the number of bytes
of data following the record length
field.
The record key bytes are the
contiguous bytes following the record
header. The number of bytes vary
according to record type. Together,
they make up a set of unique fields for
a given record specifying location (for
example, slave address, LUN and Bus
ID) and sensor number.
Reading the SDR repository and device SDR repositories
An application that retrieves records from the SDR repository must first read them sequentially using
the Get SDR command. This command returns the requested record and the record ID of the next
SDR in sequence.
NOTE: Record IDs are not required to be sequential or consecutive and applications should not
assume that SDR record IDs follow any particular numeric ordering.
Retrieve succeeding records by issuing the Get SDR or Get device SDR command using the
next record ID returned in the previous response. This is continued until the End of Record ID
is encountered.
Once all the desired records have been read, the application can randomly access the records
according to their Record ID. An application that seeks to access records randomly must save a
data structure that retains the record key information according to the record ID.
Contains specific information to the
sensor data record
FRU
IMPORTANT: Record IDs may change with time, it is important for applications to first verify that
the Record Key information matches the record retrieved.
If the record ID is no longer valid for a record key, then, access the SDR records again as described
above until the record matches the record key.
An application can tell whether records have changed by examining the most recent addition
timestamp using the Get SDR repository info or Get device SDR repository info
command, depending on the zone in which the command is issued.
If the record information has changed, an application does not need to list out the entire contents
of all records. The Get SDR or Get device SDR allows a partial read of the SDR. Thus, an
application can search for a given Record Key by just retrieving that portion of the record.
The IPMI specifications include support for storing and accessing multiple sets of non-volatile FRU
data for different modules in the system. An enterprise-class system typically has FRU information
for each major system board such as the processor board, memory board or I/O board. FRU data
includes serial number, part number, model, and asset tag.
IPMI FRU information is accessible via the IPMB and management controllers. The information can
be retrieved at any time, independent of the main processor, BIOS, system software, or OS, via
out-of-band interfaces, such as the ICMB, a remote management card, or other device connected
to the IPMB. FRU information is still available when the system is powered down.
With these capabilities FRU information is available even under failure conditions when access
mechanisms that rely on the main processor are unavailable. This facilitates the creation of
automated remote inventory and service applications. IPMI does not seek to replace other FRU or
FRU 11
inventory data mechanisms such as those provided by SM BIOS, and PCI vital product data. Rather,
IPMI FRU information is typically used to complement that information or provide information access
out-of-ban or under system down conditions.
IPMI provides FRU information in two ways: via a management controller, or via FRU SEEPROMs.
FRU information that is managed by a management controller is accessed using IPMI commands.
This isolates software from direct access to the non-volatile storage device, allowing the hardware
implementor to utilize whatever type of non-volatile storage required.
FRU inventory device
The FRU inventory device contains information such as the serial number, part number, asset tag,
and short descriptive string for the FRU. The contents of a FRU inventory record are specified in
the platform management FRU information storage definition.
The FRU inventory device is a logical device and is not necessarily implemented as a separate
physical device. This device contains the SDR repository device and typically holds FRU inventory
Information for the main system board and chassis. In addition, there may be a separate FRU
inventory device that provides access to the FRU information for a replaceable module such as a
memory module.
FRU devices can be located either behind a management controller or directly on the IPMB. The
sensor data records include a FRU device locator record that tells software where the device is
located and the type of commands required to access the FRU device. FRU devices can be located
in three types of location:
• Behind a management controller and accessed using Read/Write FRU data commands.
Multiple FRU devices can be behind a management controller.
• SEEPROM on a private bus behind a management controller. These devices are accessed
using Master Write-Read commands.
• SEEPROM on the IPMB. These devices are typically accessed using a Master Write-Read
command to the IPMB via the MC.
Standardized timers
Watchdog timer
IPMI provides a standardized interface for a system watchdog timer that can also be used for
BIOS, OS, and OEM applications. The timer can be configured to automatically generate selected
actions when it expires; including power off, power cycle, reset, and interrupt. The timer function
automatically logs the expiration event. Setting 0 for the timeout interval result causes the timeout
action to be initiated immediately. This provides a means for devices on the IPMB, such as remote
management cards, to use the watchdog timer to initiate emergency reset and other recovery
actions dependent on the capability of the timer.
In Moonshot, watchdog timers are implemented by the system node controllers.
POH counter
The standardized power-on hours (POH) counter is optional. It returns a counter value proportional
to the system operating power-on hours.
In Moonshot, the POH counter is implemented at the system node controller.
Timestamp format
A timestamp is a key component of event logging and tracking changes to the SDRs and the SDR
repository.
Time is an unsigned, 32–bit value representing the local time as the number of seconds from
00:00:00,January 1, 1970.
12 Introduction and key concepts
The timestamps used for SDR and SEL records are specified in relative local time (that is, the
difference between the timestamp does not include the GMT offset). Converting the timestamp to
a GMT-based time requires adding the GMT offset for the system and is obtained from system
software level interfaces. IPMI commands do not store or return GMT offset for the system.
Applications may use ANSI C time standard library routines for converting the SEL timestamp into
other time formats.
Special timestamp values
0xFFFFFFFF indicates an invalid or unspecified time value.
0x00000000 through 0x20000000 indicate events that occur after initialization of the SEL device
up to when the timestamp is set with the system time value. These timestamp values are relative to
the completion of the SEL devices initialization, and not January 1, 1970.
Standardized timers 13
2 The virtual topology of the Moonshot 1500 CM module
Figure 1 Moonshot virtual IPMI topology
There are five virtual management controller (MC) entity types represented within the HP Moonshot
1500 Chassis Management module.
Table 5 (page 14) summarizes the various functions available in Moonshot and the virtual
management controllers to which they apply.
Table 5 Moonshot virtual management controller functions
Applicable Virtual Management ControllerDescriptionFunction
NodeCartPower
xxxxxThe MC must implement the mandatory IPM Device
xThe implementation must provide MC access via
IPM Device
System Interface
SDR Repository
ChassisZone
Supply
commands. If an IPMB is provided, the mandatory
commands must be accessible from the IPMB unless
otherwise noted.
one of the specified IPMI system interfaces.
xThe MC must provide a SDR Repository to hold
Sensor, Device Locator, and Entity Association
records for all sensors in the platform management
subsystem. This does not need to include SDRs for
sensors that only generate events. If the SDR
Repository is writable, it is recommended that at
least 20% additional space is provided for add-in
platform management extensions.
14 The virtual topology of the Moonshot 1500 CM module
Table 5 Moonshot virtual management controller functions (continued)
Applicable Virtual Management ControllerDescriptionFunction
IPMB Interface
Watchdog
Timer
The SDR Repository must be accessible via the
system interface. If an IPMB is provided, the SDR
Repository must be readable via that interface as
well. SDR update via the IPMB interface is optional.
SDR Repository access when the system is powered
up or in ACPI ‘S1’ sleep is mandatory, but access
when the system is powered -down or in a >S1
sleep state is optional.
MC must provide the system interface to the IPMB.
If an IPMB is imp lemented, at least one of the
specified IPMB connectors must be provided. Refer
to the IPMB Protocol specification for connector
definition. In addition the MC must implement a
message channel that allows messages to be sent
from the IPMB to the system interface, and
vice-versa, and any other mandatory IPMB support
functions and commands.
Timer interface, with support for system reset action.
Certain functions within the Watchdog Timer are
optional. Refer to the sections on the Watchdog
Timer for information.
ChassisZone
Supply
NodeCartPower
xxxxxThe IPMB is highly recommended, but optional. The
xThe MC must provide the standardized Watchdog
Event Receiver
SEL Interface
FRU Inventory
Initialization
Agent
xxThe MC must implement an Event Receiver function
and accept Event Messages via the system interface.
If an IPMB is provided, the Event Receiver function
must also accept Event Messages from the IPMB.
Event Receiver operation while the system is
powered up or in ACPI ‘S1’ sleep is mandatory,
but operation when the system is powered down or
in a >S1 sleep state is optional.
xxThe MC must provide a System Event Log interface.
The event log must hold at least 16 entries. SEL
access must be provided via the system interface.
The SEL must be fully accessible via all mandatory
SEL commands through all supported interfaces to
the MC whenever the system is powered up or in
ACPI 'S1' sleep state. SEL read access is always
mandatory whenever the MC is accessible, and
through any interface that is operational, regardless
of system power state.
xxxxxThe MC must provide a logical Primary FRU
inventory device , accessible via the Write- and
Read FRU Data commands. The FRU
Inventory Device Info command must also
be supported. It is highly recommended that all other
management controllers also provide a Primary FRU
inventory device. (This was optional in IPMI v1.0.)
xxxxxThe initialization agent function is one where the
MC initializes event generation and sensors both
internally and on other management controllers
according to initialization settings stored in the SDR
for the sensor.
15
Table 5 Moonshot virtual management controller functions (continued)
Applicable Virtual Management ControllerDescriptionFunction
Sensors
Internal Event
Generation
External Event
Generation
LAN Messaging
would provide sensors for baseboard temperature,
voltage, and chassis intrusion monitoring.
Watchdog Timer. It is highly recommended that
sensors generate events to eliminate the need for
system management software to poll sensors, and
to provide “post -mortem” failure information in the
SEL. Internal event generation for sensors is optional,
but highly recommended - particularly for
‘environmental’ (e.g. temperature and voltage)
sensors.
Receiver command to allow it to be set as an IPMB
Event Generator and send its event messages to
another management controller. This would
primarily be used for development and test
purposes.
Messaging over LAN
ChassisZone
Supply
xAbility for the MC to send and receive IPMI
Not implemented yet.Ability to send an Alert over the LANLAN Alerting
NodeCartPower
xxxxxThe MC can provide sensors. A typical server MC
xxxxxThe MC must generate internal events for the
xxxThe MC could be designed to accept the Set Event
Bridging
Support
Platform Event
Filtering (PEF)
Policies optional. Refer to the sections on PEF for
messages between two interfaces connected to the
MC.
The following support is required if the
corresponding interfaces are supported:
• LAN <–> IPMB
• LAN <–> System Interface
n event. This capability is mandatory if paging or
alerting is supported. Certain actions within PEF areand Alert
information. The Alert action and Alert Policies are
mandatory if serial/modem or LAN alerting is
supported.
xxxxxThe ability to transfer IPMI request and response
Not implemented yet.Ability for MC to perform a selectable action on a
16 The virtual topology of the Moonshot 1500 CM module
3 Discovering managed entities using IPMITool
Enter the IPMItool sdr list all command to show all management controller records, whether
you are querying an SDRR from the Virtual Zone MC or you are querying a device SDR for Virtual
Cartridge MC records. For example:
# ipmitool —l lanplus —H iloatx-gem-2c -U admin —P admin123 sdr list all
ZoMC | Static MC @ 20h | ok
254 | Log FRU @FEh f0.60 | ok
IPMB0 Phys Link | 0x00 | ok
ChasMgmtCtlr1 | Static MC @ 44h | ok
PsMgmtCtlr1 | Dynamic MC @ 52h | ok
PsMgmtCtlr2 | Dynamic MC @ 54h | ok
PsMgmtCtlr3 | Dynamic MC @ 56h | ok
PsMgmtCtlr4 | Dynamic MC @ 58h | ok
CaMC | Dynamic MC @ 82h | ok
CaMC | Dynamic MC @ A0h | ok
CaMC | Dynamic MC @ A6h | ok
CaMC | Dynamic MC @ DAh | ok
CaMC | Dynamic MC @ A4h | ok
Querying an SDRR from the Zone Management Controller
• Enter the sdr list all command to show all management controller records.
• Management controller records
Chassis controller – statically assigned, always should be present. Even though always
◦
assigned address 0x44, record should be parsed to learn address and channel number
(IPMB=0).
◦ Power supply controllers --- full complement of records always present. Dynamic indication
in record indicates to application that controller may or may not be present. When not
present, the controller will “nak”. Even though always assigned address 0x52-0x58,
records should be parsed to learn address and channel number (IPMB=0).
◦ Cartridge controllers are dynamically added/deleted to the SDRR upon cartridge
insertion/deletion. Possibility of “nak” condition during deletion transitions. Records
should be parsed to learn addresses and channel number (IPMB=0).
Querying a device SDR for a Cartridge Management Controller
• Management controller records
◦ System node controllers – statically assigned, always should be present. Number of system
node controllers is dependent on cartridge type. Some cartridges may not contain host
systems such as switches. Other cartridges may contain 1 or 4 system nodes. Records
should be parsed for addressing and channel number routing. System nodes routed on
channel 7 (IPMB-L).
You can learn the phsical locations of managed entities by entering the PICMG get address
info command. Use the IPMB address of the cartridge to get the physical address (slot number).
You can also learn the chassis topology through chassis FRU serial number for Zones with the same
chassis.
17
4 IPMItool
IPMI tool is a simple command-line interface to systems that support the IPMI v1.5 specification. It
provides the ability to read the sensor data repository and print sensor values, display the contents
of the system event log, print field replaceable unit information, read and set LAN configuration
parameters, and perform remote chassis power control. It was originally written to take advantage
of IPMI-over-LAN interfaces but is also capable of using the system interface as provided by a
kernal device driver such as Open IPMI. IPMItool is available under a BSD-compatible license.
System Management Software is generally complex and makes platform management only part
of a much larger management picture. However, many system administrators and developers rely
on command-line tools that can be scripted and systems that can be micro-managed. IPMItool takes
a different approach to SMS and provides a completely command-line oriented tool. Therefore, it
is not designed to replace the Open IPMI library. Where possible, it supports printing
comma-separated values for output to facilitate parsing by other scripts or programs. It is designed
to run quick command response functions that can be as simple as turning the system on or off or
as complex as reading in the sensor data records and extracting and printing detailed sensor
information for each record.
Moonshot IPMItool support — out of band
Single-bridging out of band command
You must single-bridge out of band commands to reach specific chassis management controller or
cartridge management controller to discover management controller addresses.
Enter the sdr list all command at the zone management controller to discover chassis and
cartridge management controller addresses. For example,
• Chassis Controller
-b 0 -t 0x44
• Cartridge Controller Slot 1
-b 0 –t 0x82
• Cartridge Controller Slot 2
-b 0 –t 0x84
where:
• -b <ipmi channel number>
• -t <target slave address>
Double-bridging out of band commands
You must double-bridge out of band commands to reach specific system node management
controllers to discover system node management controller addresses.
Enter the sdr list all at the cartridge management controller to discover system node
management controller addresses. For example,
• –System Node Controller 2 (0x74) on Cartridge Controller Slot 1 (0x82)
-T 0x82 -B 0 –b 7 -t 0x74
• –System Node Controller 1 (0x72) on Cartridge Controller Slot 2 (0x84)
18 IPMItool
-T 0x84 -B 0 –b 7 -t 0x72
where:
• –B <transit channel for bridged request (dual bridge)>
• –T <transit address for bridge request (dual bridge)>
• -b <ipmi channel number>
• -t <target slave address>
Interfaces
IPMItool supports dynamic loading of interfaces that correspond to low-level communication methods
for accessing IPMI systems. The most common of these are the System Interface provided by the
OpenIPMI Linux kernal driver and IPMI over LAN interfaces.
System Interface
There are multiple types of system interfaces, and they are all similar enough to enable a single
driver like OpenIPMI to support them all. They can be connected to any system bus such as ISA
or X-bus that allows the main processor to access I/O mapped locations and meet the timing
specifications. The varieties of system interfaces include KCS and SSIF. All of these are supported
in recent versions of the OpenIPMI driver for the Linux kernal. IPMItool uses this driver to access
the system interface through a character device node at /dev/ipmi0. To use this interface with
IPMItool provide the -l open parameter on the command line.
LANPlus Interface
The LANPlus interface communicates with the MC over an ethernet LAN connection using UDP
under IPv4. The LANPlus interface uses the RMCP+ protocol. RMCP+ facilitates improved
authentication and data integrity checks as well as encryption and the ability to carry multiple
types of payloads. Generic Serial Over LAN support requires RMCP+, so the IPMItool sol
activate command requires the use of LANPlus.
RMCP+ session establishment uses a symmetric challenge-response protocol called RAKP (Remote
Authenticated Key-Exchange Protocol) which allows the negotiation of many options.
NOTE: IPMItool does not allow the user to specify the value of every option, defaulting to the
most obvious settings marked as required in the v2.0 specification. Authentication and integrity
HMACS are produced with SHA1, and encryption is performed with AES-CBC-128. Role-level
logins are not yet supported.
IPMItool must be linked with the OpenSSL library in order to perform the encryption functions and
support the LANPlus interface. If the required packages are not found it will not be compiled and
supported.
ipmitool -I lanplus -H <hostname>[-U <username>][-P <password>]<command>
A hostname must be given on the command line in order to use the LAN interface with IPMItool.
The —C option allows the authentication integrity and encryption algorithms to be used for LANPlus
sessions based on the cipher suite ID found in IPMI v2.0. The default cipher suite is 3 which specifies
RAKP-HMAC-SHA1 authentication, HMAC-SHA1–96 integrity, and AES-CBC-128 encryption
algorithms.
Interfaces 19
Example 1 Raw Get Device ID to chassis satellite controller over LAN
# ipmitool -I lanplus -H 16.85.178.125 -U admin -P admin123 -L Administrator -b 0 -t 0x44 raw 6 1
15 01 02 01 02 29 0b 00 00 00 85 00 00 00 00
Example 2 Powering on C2N1 over LAN
# ipmitool -I lanplus -H 16.85.178.125 -U admin -P admin123 -L Administrator -B 0 –T 0x84 –b 7 –t 0x72 chassis
power on
Chassis Power Control: Up/On
Example 3 Activating SOL on C2N1 over LAN
# ipmitool -I lanplus -H 16.85.178.125 -U admin -P admin123 -L Administrator -B 0 –T 0x84 –b 7 –t 0x72 sol
activate
Activates SOL session for C2N1
Features
Instead of directly accessing the monitoring hardware for device entry, IPMI provides access to
sensor data through abstracted messaging commands. Some common types of sensors that can
be found in the system include baseboard and processor temperature sensors, processor and DIMM
presence sensors, fan speed and failure monitoring, and baseboard, processor and SCSI terminating
voltage sensors. The amount of data available for each sensor can be overwhelming, so by default
IPMItool only displays the sensor name, reading and status. Considerably more output can be seen
by enabling the verbose output option.
To facilitate discovery of features, IPMI includes a set of records called SDRs kept in a single
centralized non-volatile storage area. These records include software information such as how
many sensors are present, what type they are, their events, threshold info and more. This allows
software to interpret and present sensor data without any prior knowledge about the platform.
20 IPMItool
Example 4 Output from sdr list all command
ZoMC | Static MC @ 20h | ok
254 | Log FRU @FEh f0.60 | ok
IPMB0 Phys Link | 0x00 | ok
ChasMgmtCtlr1 | Static MC @ 44h | ok
PsMgmtCtlr1 | Dynamic MC @ 52h | ok
PsMgmtCtlr2 | Dynamic MC @ 54h | ok
PsMgmtCtlr3 | Dynamic MC @ 56h | ok
PsMgmtCtlr4 | Dynamic MC @ 58h | ok
CaMC | Dynamic MC @ A6h | ok
CaMC | Dynamic MC @ A8h | ok
CaMC | Dynamic MC @ AAh | ok
CaMC | Dynamic MC @ ACh | ok
CaMC | Dynamic MC @ AEh | ok.
.
.
.
CaMC | Dynamic MC @ A4h | ok
Example 5 Output from sdr list all command at cartridge
01-Front Ambient | 21 degrees C | ok
02-CPU | 40 degrees C | ok
03-DIMM | 25 degrees C | ok
04-Cart Ctrlr | 24 degrees C | ok
05-CPU Zone | 29 degrees C | ok
06-LOM Zone | 36 degrees C | ok
CaMC | Dynamic MC @ A4h | ok
SnMC | Dynamic MC @ 72h | ok
SnMC 1 | Log FRU @01h c1.62 | ok
Events
See “Verbose output examples” (page 164) for an example of verbose output from the sdr list
all command.
Events are special messages sent by the management controller when they detect system
management events. Some examples of events are temperature threshold exceeded, voltage
threshold exceed, correctable ECC memory error, etc. These events are processed and usually
logged in the SEL. This is similar to the SDR in that it provides a centralized non-volatile storage
area for platform events that are logged autonomously by the MC or directly with event messages
sent from the host.
There is an abundance of information available from an event log entry. By default IPMItool displays
only the basic data for the event and the sensor that triggered it. Detailed information is available
with the verbose option.
Example 6 Output from sel list command
0 | 04/16/2013 | 20:22:01 | Power Supply #0x04 | Failure detected | Asserted
1 | 06/28/2013 | 20:36:17 | Power Supply #0x02 | Presence detected | Deasserted
2 | 07/28/2013 | 00:20:52 | Power Supply #0x02 | Failure detected | Asserted
3 | 08/04/2013 | 00:23:10 | Power Supply #0x02 | Presence detected | Deasserted
4 | 08/09/2013 | 14:34:48 | Fan #0x07 | Transition to Off Line | Asserted
5 | 08/09/2013 | 14:34:49 | Fan #0x07 | Transition to Running | Deasserted
See “Verbose output examples” (page 164) for an example of verbose output from the sel list
command.
Events 21
Inventory
IPMI supports multiple sets of non-volatile FRU information for different parts in the system. This
provides access to data such as serial number, part number, asset tag, and other information for
major modules in the system including the baseboard, chassis, processors, memory, power supplies,
and even the management controller itself. This information is even available when the system is
powered down or non-operational, facilitating the creation of automated remote inventory and
service applications. IPMItool can read and display full FRU information for the system as well as
detailed descriptions of power supplies and full DIMM SPD data.
Example 7 Output from the fru print command
FRU Device Description : ChasMgmtCtlr1
Chassis Type : Rack Mount Chassis
Chassis Part Number : 700349-B21
Chassis Serial : 600012J0SD
Chassis Extra : d09701640003000000
Chassis Extra : d1110102000000
Board Mfg Date : Fri Dec 7 19:54:00 2012
Board Mfg : HP
Board Product : HP Moonshot 1500 Chassis Management Module
Board Serial : 1G24900006J0SE
Board Part Number : 712678-001
Board Extra : d25835
Board Extra : 700369-001
Product Manufacturer : HP
Product Name : HP Moonshot 1500 Chassis
Product Part Number : 700451-001
Chassis management
This feature provides standardized chassis status and control functions that allow a remote system
to be turned on/off or rebooted without manual intervention. It also provides commands for causing
the chassis to physically identify itself with an implementation dependant mechanism such as turning
on visible lights, displaying messages on an LCD, emitting beeps through a speaker, etc. IPMItool
fully supports the available chassis management commands and can eliminate trips to the data
center or server room to reset a frozen machine or help identify the single system in a rack that
must be removed.
Example 8 Sample chassis power commands
root@JSMITH-LX:/# ipmitool -I lanplus -H ILOH101GEMINI -U Administrator -P password sdr list all
(output)
root@JSMITH-LX:/# ipmitool -I lanplus -H ILOH101GEMINI -U Administrator -P password -t 0xa4 power status
Chassis Power is on
In all of the above examples only a portion of the available output is shown, the full output is much
richer and tells a full story about the system health and status; in addition verbose output options
are available which increase the output information. See “Verbose output examples” (page 164)
for examples of verbose output.
Synopsis
ipmitool [-chvV] [-Iopen <command>]
ipmitool [-chvV] -Ilan -H<hostname>
[-p<port>]
[-U<username>]
[-A<authtype>]
[-L<privlvl>]
[-aEPf<password>]
[-o<oemtype>]
22 IPMItool
<command>
ipmitool [-chvV] -Ilanplus -H<hostname>
[-p<port>]
[-U<username>]
[-L<privlvl>]
[-aEPf<password>]
[-o<oemtype>]
[-C<ciphersuite>]
<command>
Description
This program allows management of IPMI functions of either the local system via a kernal device
driver or a remote system using IPMI v1.5 and IPMI v2.0. These functions include printing FRU
information, LAN configuration, sensor readings and remove chassis power control.
IPMI management of a local system interface requires a compatible IPMI kernel driver to be installed
and configured. On Linux this driver is called OpenIPMI and it is included in standard distributions.
Options
Prompt for the remote server password.—a
—A <authtype>
—C<ciphersuite>
—E
—f<password_file>
—H <address>
— I <interface>
—o<oemtype>
Specify the authentication type to use during IPMI v1.5 LAN session
activation. Supported types are NONE, PASSWORD, MD5 or OEM.
Present output in CSV format. Not available with all commands.—c
The remote server authentication, integrity, and encryption algoritms to
use for IPMI v2 lanplus connections. Default = 3 and specifies
RAKP-HMAC-SHA1 authentication, HMAC-SHA1–96 integrity, and
AES-CBC-128 encryption algorithms.
The remote server password is specified by the environment variable
ipmi_password.
Specifies a file containing the remote server password. If this option is
absent or if the <password_file> is empty the password defaults to
NULL.
Get basic usage help from the command line.—h
Remote server address can be IP address or hostname. This option
is required for LAN and LANPLUS interfaces.
Selects the IPMI interface. Supported interfaces display in the usage help
output.
Force session privilege level, defaults to admin.—L<privlvl>
Set the local IPMB address. Default = 0x20.—m<local address>
Select OEM type. Use —o list to see a list of currently supported OEM
types.
-P<password>
Remote server UDP port. Default = 623.-p<port>
Remote server password specified on the command line. It is not
recommended to specify a password on the command line.
NOTE: If no password method is specified, the IPMI tool prompts the
user for a password, if no password is entered, the remote server password
is set to NULL.
Bridge IPMI requests to the remote target address.—t<target address>
Remote server username. Default = NULL—U<username>
Synopsis 23
—v
Increase verbose output level. May be specified multiple times to increase
levels of debug output, for example, specifying three times results in
hexdumps of all incoming and outgoing packets.
Display version information.—V
IPMItool Raw command syntax and example
1. Syntax — Target command towards specific virtual controller
• —b <ipmi channelnumber>
• —t <target slave address>
• -m <source slave address>
• Chassis controller —b 0 —t 0x44 —m 0x20
• Power supply A controller -b 0 -t 0x52 -m 0x20
• Power supply B controller -b 0 -t 0x54 -m 0x20
• Power supply C controller -b 0 -t 0x56 -m 0x20
• Power supply D controller -b 0 -t 0x58 -m 0x20
2. Examples:
• Raw Get Device ID to chassis satellite controller over LAN:
ipmitool -I lanplus -H 16.85.178.125 -U admin -P admin123 -L
Administrator -b 0 -t 0x44 -m 0x20 raw 6 1
• Power on to C2N1 over LAN:
ipmitool -I lanplus -H 16.85.178.125 -U admin -P admin123 -L
Administrator -B 0 –T 0x84 –b 7 –t 0x72 -m 0x20 chassis power on
• SOL to C2N1 over LAN
ipmitool -I lanplus -H 16.85.178.125 -U admin -P admin123 -L
Administrator -B 0 –T 0x84 –b 7 –t 0x72 -m 0x20 sol activate
24 IPMItool
5 Command specification
IPMI provides standardized interfaces and commands for configuring the platform managemenet
subsystem. This enables cross-platform software to SDRs are an example of the interface for
configuring sensor population and behavior on a system. There are also commands for configuring
capabilities such as LAN and serial/modem remote protocols, user passwords and privilege levels,
platform event filtering, alert destinations, and others.
This section provides specifications for elements that apply to all requests and responses.
See “Completion codes” (page 142).
Unless otherwise noted, reserved bits and fields in commands (request messages) and responses
are written as 0. Applications must ignore the state of reserved bits when they are read.
Unless otherwise specified, commands that are listed as mandatory must be accessed via LUN
00b. An implementation may elect to make any command available on any LUN or channel as
long as it does not conflict with other requirements in this specification.
Command table notation
The following section includes command tables that list the data that is included in a request or a
response for each command. The completion code for a response is included as the first byte of
the response data field for each command. The NetFn and command byte values for each command
are specified in separate tables.
The following notation is used in the command tables.
Request data
Response data
4
5:7
(3)
DescriptionNotation
Identifies the portion of the table that lists the fields that are included in the data portion of a request
message for the given command.
Identifies the portion of the table that lists the fields that are included in the data portion of a response
message for the given command. The completion code is always listed as the first byte in the
response data field.
Single byte field. A single value in the byte column of a command table is used to identify a single
byte field. The value represents the offset to the field within the data portion of the message. In some
cases a single byte field follows a variable length field in which case the single byte offset is
represented with an alphabetic variable and number representing the single byte field’s location
relative to the end of the variable length field. For example: N+1.
Multi-byte field. The byte column indicates the byte offset(s) for a given field. For a multi-byte field,
the first value indicates the starting offset, the second value (following the colon) indicates the offset
for the last byte in the field. For example, 5:7 indicates a three-byte field spanning byte offsets 5,
6, and 7.
In some cases, multi-byte fields may be variable length, in which case an alphabetic variable is
used to represent the ending offset, for example: 5:N. Similarly, a field may follow a variable length
field. In this case the starting value is shown as an offset relative to the notation used for the previous
field, for example, if the previous field were 5:N, the next field would be shown starting at N+1.
A variable length field may follow a variable length field, in which case a relative starting offset is
shown with an alphabetic value indicating a relative ending offset, for example, N+1:M.
Optional Fields. When used in the byte column of the command tables, parentheses are used to
indicate optional data byte fields. These can be absent or present at the choice of the party
generating the request or response message. Devices receiving the message are required to accept
any legal combination of optional data byte fields.
Unless otherwise indicated, if an optional byte field is present, all prior specified byte fields must
also be present. Similarly, if an optional byte field is absent all following byte fields must also be
absent. For example, suppose a request accepts 4 data bytes. If data byte 3 was shown in
parentheses as (3), it would indicate that byte 3 and following were optional. A legal request could
consist of just bytes [1 and 2], bytes [1, 2, and 3,] or bytes [1, 2, 3 and 4]. A request which
eliminates byte 3, but includes byte 4. (a request with data bytes [1, 2, and 4]), is illegal.
25
DescriptionNotation
Multi-byte fields that are shown as optional cannot be split. Either all bytes for the field are present
or absent. For example, if a four byte multi-byte field is listed as optional, it is illegal to include the
first two bytes, but not the second two bytes.
Table 6 (page 26) lists the available Moonshot IPMI commands and, where available, the equivalent
iLO Chassis Management CLI command. The IPMI commands and capabilities available for
Moonshot are not completely analogous to the commands available at the iLO Chassis Management
CLI, and so not every IPMI command has a CLI equivalent. Additionally, where there are analogous
commands, the responses offered by the two commands may not be equivalent.
Table 6 Moonshot IPMI commands and their iLO CM CLI equivalents
IPMI Device Global Commands
1
MC Watchdog Timer Commands
IPMI Messaging Support Commands
NetFnMoonshot IPMI Command
Code
0x01App (0x06)Get Device ID
0x01App (0x06)Broadcast ‘Get Device ID’
0x04App (0x06)Get Self Test Results
Moonshot iLO CM CLI command equivalentCommand
Show chassis info provides a partially
equivalent response.
Show chassis info provides a partially
equivalent response.
Reset CM0x02App (0x06)Cold Reset
Reset CM0x03App (0x06)Warm Reset
Show log IML provides a partially
equivalent response (specifically, failures
that were written to the iML)
show node power CxNy0x07App (0x06)Get ACPI Power State
IPMI specific0x22App (0x06)Reset Watchdog Timer
IPMI specific0x24App (0x06)Set Watchdog Timer
IPMI specific0x25App (0x06)Get Watchdog Timer
Capabilities
26 Command specification
IPMI specific0x2EApp (0x06)Set BMC Global Enables
IPMI specific0x2FApp (0x06)Get BMC Global Enables
IPMI specific0x30App (0x06)Clear Message Flags
IPMI specific0x31App (0x06)Get Message Flags
IPMI specific0x32App (0x06)Enable Message Channel Receive
IPMI specific0x33App (0x06)Get Message
IPMI specific0x34App (0x06)Send Message
0x37App (0x06)Get System GUID
0x59App (0x06)Get System Info Parameters
The physical node UUID is not shown in the
CLI.
Not supported in CLI.0x58App (0x06)Set System Info Parameters
Show node info returns the MAC
address; other parameters returned by the
IPMI command are IPMI specific.
IPMI specific0x38App (0x06)Get Channel Authentication
Table 6 Moonshot IPMI commands and their iLO CM CLI equivalents (continued)
NetFnMoonshot IPMI Command
Code
Moonshot iLO CM CLI command equivalentCommand
IPMI specific0x3BApp (0x06)Set Session Privilege Level
IPMI specific0x3CApp (0x06)Close Session
IPMI specific0x3DApp (0x06)Get Session Info
IPMI specific0x3FApp (0x06)Get AuthCode
IPMI specific0x40App (0x06)Set Channel Access
IPMI specific0x41App (0x06)Get Channel Access
IPMI specific0x42App (0x06)Get Channel Info
Set user privilege0x43App (0x06)Set User Access
show user0x44App (0x06)Get User Access
add user0x45App (0x06)Set User Name
show user0x46App (0x06)Get User Name
set user password0x47App (0x06)Set User Password
IPMI specific0x48App (0x06)Activate Payload
IPMI specific0x49App (0x06)Deactivate Payload
Chassis Device Commands
IPMI specific0x4AApp (0x06)Get Payload Activation Status
IPMI specific0x4BApp (0x06)Get Payload Instance Info
IPMI specific0x4CApp (0x06)Set User Payload Access
IPMI specific0x4DApp (0x06)Get User Payload Access
IPMI specific0x4EApp (0x06)Get Channel Payload Support
IPMI specific0x4FApp (0x06)Get Channel Payload Version
No CLI equivalent0x52App (0x06)Master Write-Read
IPMI specific0x54App (0x06)Get Channel Cipher Suites
IPMI specific0x55App (0x06)Suspend/Resume Payload Encryption
IPMI specific0x56App (0x06)Set Channel Security Keys
IPMI specific0x57App (0x06)Get System Interface Capabilities
IPMI specific0x00Chassis (0x00)Get Chassis Capabilities
0x01Chassis (0x00)Get Chassis Status
show chassis status or show node
status
set node power0x02Chassis (0x00)Chassis Control
0x04Chassis (0x00)Chassis Identify
set chassis uid or set cartridge
uid
set chassis autopower0x06Chassis (0x00)Set Power Restore Policy
set node boot or set node bootonce0x08Chassis (0x00)Set System Boot Options
show node boot0x09Chassis (0x00)Get System Boot Options
No CLI equivalent0x0FChassis (0x00)Get POH Counter
27
Table 6 Moonshot IPMI commands and their iLO CM CLI equivalents (continued)
Event Commands
Sensor Device Commands
NetFnMoonshot IPMI Command
Code
0x21S/E (0x04)Get Device SDR show chassis status
0x27S/E (0x04)Get Sensor Thresholds
0x2DS/E (0x04)Get Sensor Reading show chassis status
Moonshot iLO CM CLI command equivalentCommand
IPMI specific0x00S/E (0x04)Set Event Receiver
IPMI specific0x01S/E (0x04)Get Event Receiver
No CLI equivalent0x02S/E (0x04)Platform Event (Event Message)
IPMI specific0x20S/E (0x04)Get Device SDR Info
show chassis powersupply
show chassis temperature
show cartridge temperature
IPMI specific0x22S/E (0x04)Reserve Device SDR Repository
show chassis temperature and show
cartridge temperature
show chassis powersupply
show chassis temperature
show cartridge temperature
FRU Device Commands
SDR Device Commands
SEL Device Commands
IPMI specific0x10Storage (0x0A)Get FRU Inventory Area Info
show fru0x11Storage (0x0A)Read FRU Data
No CLI equivalent0x12Storage (0x0A)Write FRU Data
IPMI specific0x20Storage (0x0A)Get SDR Repository Info
IPMI specific0x21Storage (0x0A)Get SDR Repository Allocation Info
IPMI specific0x22Storage (0x0A)Reserve SDR Repository
0x23Storage (0x0A)Get SDR show chassis status
show chassis powersupply
show chassis temperature
show cartridge temperature
IPMI specific0x24Storage (0x0A)Add SDR
IPMI specific0x26Storage (0x0A)Delete SDR
IPMI specific0x27Storage (0x0A)Clear SDR Repository
IPMI specific0x2CStorage (0x0A)Run Initialization Agent
28 Command specification
IPMI specific0x40Storage (0x0A)Get SEL Info
IPMI specific0x42Storage (0x0A)Reserve SEL
show log IML0x43Storage (0x0A)Get SEL Entry
No CLI equivalent0x44Storage (0x0A)Add SEL Entry
clear log0x47Storage (0x0A)Clear SEL
Table 6 Moonshot IPMI commands and their iLO CM CLI equivalents (continued)
LAN Device Commands
Serial/Modem Device Commands
DCMI Specific commands
NetFnMoonshot IPMI Command
Code
0x07DCGRP (0xDC)Get DCMI Sensor Info
Moonshot iLO CM CLI command equivalentCommand
show time0x48Storage (0x0A)Get SEL Time
set time0x49Storage (0x0A)Set SEL Time
set network0x01Transport (0x0C)Set LAN Configuration Parameters
show network0x02Transport (0x0C)Get LAN Configuration Parameters
IPMI specific0x21Transport (0x0C)Set SOL Configuration Parameters
IPMI specific0x22Transport (0x0C)Get SOL Configuration Parameters
IPMI specific0x01DCGRP (0xDC)Get DCMI Capability Info
show chassis asset0x06DCGRP (0xDC)Get Asset Tag
show chassis temperature and show
cartridge temperature
set chassis asset0x08DCGRP (0xDC)Set Asset Tag
IPMI specific0x09DCGRP (0xDC)Get Controller Id String
PICMG Specific commands
1
Only relevant to satellite controllers.
NOTE: The IPMI commands and capabilities available for Moonshot are not completely analogous
to those available to the iLO Chassis Management CLI, and so not every IPMI command has a CLI
equivalent.
Standard command specification
This section presents the commands that are common to all IPMI devices that follow this
specification’s message/command interface. This includes management controllers that connect
to the system via a compatible message interface, as well as IPMB devices.
Global commands
IPMI management controllers shall recognize and respond to these commands via LUN 0.
Get device ID command
IPMI specific0x0ADCGRP (0xDC)Set Controller Id String
IPMI specific0x00PICMG (0x00)Get PICMG Properties
IPMI specific0x01PICMG (0x00)Get Address Info
IPMI specific0x1FPICMG (0x00)Fru Inventory Device Lock Control
This command is available to MC, ChMC, and PSMC.
This command is used to retrieve the intelligent device’s hardware revision, firmware/software
revision, and sensor and event interface command specification revision information. The command
also returns information regarding the additional logical device functionality (beyond application
and IPM device functionality) that is provided within the intelligent device, if any.
Standard command specification 29
While broad dependence on OEM-specific functionality is discouraged, two fields in the response
allow software to identify controllers for the purpose of recognizing controller specific functionality.
These are the device ID and the product ID fields. A controller that just implements standard IPMI
commands can set these fields to unspecified.
Table 7 Device ID command response data
Data fieldResponse data
byte number
Completion code1
Device ID. 00h = unspecified2
Device revision3
• [7] — 1=device provides device SDRs and 0=device does not provide device SDRs.
• [6:4) — Reserved. Return as 0.
• [3:0] — Device revision, binary encoded.
Firmware revision 14
• [7] — Device available: 0=normal operation, device firmware, SDR repository update or
self-initialization in progress. Firmware or SDR repository updates can be differentiated by issuing
a get SDR command and checking the completion code.
• [6:0] — Major firmware revision, binary encoded.
Firmware revision 2: minor firmware revision. BCD encoded.5
6
7
8:10
IPMI version. Holds IPMI command specification version. BCD encoded. 00h = reserved. Bits 7:4
hold the least significant digit of the revision, while bits 3:0 hold the most significant bits. For example,
a value of 51h indicates revision 1.5 functionality. 02h for implementations that provide IPMI v2.0
capabilities per this specification.
Additional device support (formerly called IPM device support) lists the IPMI logical device commands
and functions supported by the controller that are in addition to the mandatory IPM and application
commands.
• [7] — Chassis device
• [6] — Bridge (device responds to bridge NetFn commands)
• [5] — IPMB event generator. Device generates event messages (platform event request messages)
from the IPMB.
• [4] — IPMB event receiver. Device accepts event messages (platform event request messages) from
the IPMB.
• [3] — FRU inventory device
• [2] — SEL device
• [1] — SDR repository device
• [0] — Sensor device
manufacturer ID, LS byte first. The manufacturer ID is a 20-bit value that is derived from the IANA
private enterprise ID (see below). Most significant four bits = reserved (0000b).
000000h = unspecified. 0FFFFFh = reserved. This value is binary encoded. For example, the ID for
the IPMI forum is 7154 decimal, which is 1BF2h, and would be stored in this record as F2h, 1Bh,
00h for bytes 8 through 10, respectively.
11:12
(13:16)
30 Command specification
Product ID, LS byte first. This field can be used to provide a number that identifies a particular system,
module, add-in card, or board set. The number is specified according to the manufacturer given by
manufacturer ID (see below).
0000h = unspecified. FFFFh = reserved.
Auxiliary firmware revision information. This field is optional. If present, it holds additional information
about the firmware revision, such as boot block or internal data structure version numbers. The meanings
of the numbers are specific to the vendor identified by manufacturer ID (see below). When the
Loading...