hpmgmtbase Utilities

hpuid — hp Unique Identifer (UID) utility

Syntax

 /sbin/hpuid [-d] [-e] [-s] [-v]

The Unique Identifier (UID) is a flashing LED on the chassis used to identify a box. This can be a great aid when confronted with a server farm of hundreds of boxes.

On entry-level systems the UID is a blue LED that is present on both front and rear panels. The LED is also a pushbutton which will toggle the state of the LED. The current state of the UID can be read or changed with the hpuid command.

On midrange and high-end systems (cellular/partitioned platforms) there is no pushbutton. The UID is not a single LED but a collection of all LEDs for the components of the running partition. Thus if there was a partition that consisted of one cell in cabinet 0, one cell in cabinet one, and one I/O chassis in cabinet 8, the UID consists of the following:

hpseld — HP System Event Log (SEL) Daemon

Syntax

hpseld [-p pollinterval]

The SEL daemon is started by the /etc/init.d/hpmgmtbase script during normal boot operation and should not be run manually. hpseld manages several features related to chassis events.

hpbmc — Manage the IPMI BMC on HP Integrity Servers

Syntax

hpbmc [-d path] [-b busaddr] [command [ data ]]

hpbmc is a general purpose utility that gives complete access to the BMC. Its primary command argument is one of a list of directives that expose a particular feature of the BMC (for example, SELprint lists the current contents of the System Event Log).

There are open source tools available that have similar functionality, such as ipmitool (found at http://ipmitool.sourceforge.net and shipped with some commercial distributions). hpbmc exceeds those tools by handling the OEM IPMI extensions of HP Integrity Servers.

Refer to hpbmc(8) for an explanation of all directives. This section discusses some of the background processing done by hpmgmtbase and hpbmc.

All IPMI commands are a command/response message protocol with a requestor and a responder. In most cases on HP hardware using HP software, programs running under Linux are the requestor, and the system's BMC is the responder.

The BMC hardware is exposed through a System Interface as described in the IPMI specification. This channel requires a device driver and device file to exchange commands and responses. The hpmgmtbase installation will load the Open IPMI driver modules and set up the character device files /dev/ipmi/0 and /dev/ipmi0. These files are well-known to the Linux Open IPMI community (such as ipmitool).

By default, hpbmc uses these files to access the local BMC. SELprint is implemented similar the following conversation:

Another task done at hpmgmtbase installation is caching of the Sensor Data Record Repository (SDRR). IPMI is intended to be self-describing and the SDRR holds the material list for the system (along with sensors). Software can construct a coherent view of the entire system starting from this material list.

The SDRR is thus crucial to the completion of most hpbmc directives. Not only is the SDRR a large list, the IPMI interface is a relatively slow channel. It can take over twenty seconds to read the SDRR on some Integrity servers. Fortunately the SDRR is a static collection on Integrity Servers and can easily be cached to a disk file. This is done at hpmgmtbase installation and by default hpbmc will read this cache.

The -d path option changes the path to the BMC. The HPBMC_DEVICE environment variable can be set for the same purpose. Specifying an alternate Open IPMI device file is of interest only to IPMI utility developers and is usually not seen in practice.

hpmgmtbase utilities also support the Remote Management Control Protocol (RMCP), or IPMI over LAN. This works against any BMC (or IPMI controller) which speaks RMCP. An RMCP exchange always needs a host target (DNS name or IP address), and optionally a password and user name. The path argument then takes the form

[[user:]password]@hostname

Either use the -d option or set HPBMC_DEVICE. Here are some things to remember:

The final complexity in addressing an IPMI responder or target device is the IPMI Bus, or IPMB. IPMB is an address-based I2C bus that passes IPMI commands back and forth between intelligent controllers.

Some HP Integrity Servers do have IPMB, but its use is hidden by hpbmc and not directly exposed. However, on the HP ATCA platform this functionality is of immense interest. Consult ATCA documentation for details.

The IPMI Send Message command is used to bridge data from external sources (System Interface or RMCP) to and from an IPMB behind the BMC. The -b argument to hpbmc takes a hexadecimal IPMB address to specify the target. For example, to issue Get Device ID command to IPMB address 0x82 behind an RMCP responder at atca.fc.hp.com with password please, the syntax is

# hpbmc -d please@atca.fc.hp.com -b 82 IPMIraw 18 1

Decoding Events

hpmgmtbase libraries and utilities generate extensive decoding of System Event Log (SEL) entries. HP Integrity Servers support several event types in the SEL. The first is type 02 events which are mostly documented and described in the IPMI specification. It is possible to synthesize a complete textual description of any type 02 event by successively decoding the bitfields and looking at various tables in the IPMI specification. These tables and resolution algorithms are coded into libezbmc and thus accessible to hpbmc.

Type 02 events have an OEM extension subclass which are used for some events. hpbmc decodes those events as well (obviously a feature not found in the any open source tools).

For various historical and technical reasons, the coverage of type 02 events is insufficient for the entire Integrity Server line. This is especially true across multiple operating systems and the cellular platforms. Integrity servers also generate full OEM events; for that HP has chosen type E0 and E1 events. These events consume two SEL entries, one for the primary data set and the second for a timestamp.

Internally HP maintains an event database that contains all these events along with additional information about each event:

This database tends to grow over time as new platforms are added to the server families. A static snapshot of this database called the event dictionary ships with hpmgmtbase and is crucial to the decoding and handling of all events. This snapshot is updated with each release of hpmgmtbase.

There are several hpbmc directives concerned with event decoding. The first is SELprint which gives the decoded text for all contents of the SEL. Similar to that is FPLprint. HP Integrity Servers have a custom log called the Forward Progress Log, or FPL. This is where all status and transactions are logged, along with errors and mroe serious events found only in the SEL. The FPL can be considered a superset of the SEL. The FPL is not part of the IPMI specification.

SELprintraw and FPLprintraw print the same decoded event data along with the actual bytes of the SEL entry.

Another useful directive is SELdecode. The MP/iLO cards of Integrity Servers and some EFI utilities report a SEL event in its raw 16-byte form as two large 8-byte numbers. SELdecode takes those numbers as input arguments and provides a textual decode.

The final event directive is EventLookup, used to generate decodes for partial event information. Entry-level servers (non- cellular) type 02 events can be categorized by an event triplet, three of the key bytes from a SEL entry. These triplets are described in the Operations and Maintenance Guide of each server. This triplet can be used as input for EventLookup.

Finally, the entire event dictionary can be dumped with either EventLookup LIST (a very verbose form) or EventLookup TABLE ( | -separated fields suitable for further parsing or import into a spreadsheet).