A P P E N D I X D |
Using IPMItool to View System Information |
Note - This chapter applies to all Sun Fire X4100/X4100 M2 and X4200/X4200 M2 servers, unless otherwise noted. |
This appendix contains information about using the Intelligent Platform Management Interface (IPMI) to view monitoring and maintenance information for your server. This appendix contains the following sections:
IPMI is an open-standard hardware management interface specification that defines a specific way for embedded management subsystems to communicate. IPMI information is exchanged though baseboard management controllers (BMCs), which are located on IPMI-compliant hardware components. Using low-level hardware intelligence instead of the operating system has two main benefits: first, this configuration allows for out-of-band server management, and second, the operating system is not burdened with transporting system status data.
Your ILOM Service Processor (SP) is IPMI v2.0 compliant. You can access IPMI functionality through the command line with the IPMItool utility either in-band or out-of-band. Additionally, you can generate an IPMI-specific trap from the web interface, or manage the server's IPMI functions from any external management solution that is IPMI v1.5 or v2.0 compliant. For more information about the IPMI v2.0 specification, go to http://www.intel.com/design/servers/ipmi/spec.htm#spec2.
IPMItool is included on the Resource CD, also titled Tools and Drivers CD in later servers (705-1438). IPMItool is a simple command-line interface that is useful for managing IPMI-enabled devices. You can use this utility to perform IPMI functions with a kernel device driver or over a LAN interface. IPMItool enables you to manage system hardware components, monitor system health, and monitor and manage system environmentals, independent of the operating system.
Locate IMPItool and its related documentation on your Resource CD (705-1438), or download this tool from the following URL: http://ipmitool.sourceforge.net/
After you install the IPMItool package, you can access detailed information about command usage and syntax from the man page that is installed. From a command line, type this command:
To connect over a remote interface you must supply a user name and password. The default user with admin-level access is root with password changeme. This means you must use the -U and -P parameters to pass both user name and password on the command line, as shown in the following example:
ipmitool -I lanplus -H <IPADDR> -U root -P changeme chassis status
In order to enable the Anonymous/NULL user you must alter the privilege level on that account. This will let you connect without supplying a -U user option on the command line. The default password for this user is anonymous.
ipmitool -I lanplus -H <IPADDR> -U root -P changeme channel setaccess 1 1 privilege=4
ipmitool -I lanplus -H <IPADDR> -P anonymous user list
You can also change the default passwords for a particular user ID. First get a list of users and find the ID for the user you wish to change, then supply it with a new password, as shown in the following command sequence:
ipmitool -I lanplus -H <IPADDR> -U root -P changeme user list
ID Name Callin Link Auth IPMI Msg Channel Priv Limit
2 root false false true ADMINISTRATOR
ipmitool -I lanplus -H <IPADDR> -U root -P changeme user set password 2 newpass
ipmitool -I lanplus -H <IPADDR> -U root -P newpass chassis status
You can use IPMItool to configure an SSH key for a remote shell user. To do this, first determine the user ID for the desired remote SP user with the user list command:
ipmitool -I lanplus -H <IPADDR> -U root -P changeme user list
Then supply the user ID and the location of the RSA or DSA public key to use with the ipmitool sunoem sshkey command. For example:
ipmitool -I lanplus -H <IPADDR> -U root -P changeme sunoem sshkey set 2 id_rsa.pub
Setting SSH key for user id 2.......done
You can also clear the key for a particular user, for example:
ipmitool -I lanplus -H <IPADDR> -U root -P changeme sunoem sshkey del 2
For more information about supported IPMI 2.0 commands and the sensor naming for this server, also refer to the Integrated Lights-Out Manager (ILOM) Administration Guide, 819-1160 and the Integrated Lights-Out Manager Supplement for Sun Fire X4100 and Sun Fire X4200 Servers, 819-5464.
There are a number of ways to read sensor status, from a broad overview that lists all sensors, to querying individual sensors and returning detailed information on them. See the following sections:
To get a list of all sensors in these servers and their status, use the sdr list command with no arguments. This returns a large table with every sensor in the system and its status.
The five fields of the output lines, as read from left to right are:
1. IPMI sensor ID (16-character maximum)
3. Sensor status, indicating which thresholds have been exceeded
fp.t_amb | 0Ah | ok | 12.0 | 22 degrees C
Although the default output is a long list of sensors, it is possible to refine the output to see only specific sensors. The sdr list command can use an optional argument to limit the output to sensors of a specific type.TABLE D-1 describes the available sensor arguments.
For example, to see only the temperature, voltage, and fan sensors, you would use the following command, with the full argument.
ipmitool -I lanplus -H <IPADDR> -U root -P changeme sdr elist full
fp.t_amb | 0Ah | ok | 12.0 | 22 degrees C
ps.t_amb | 11h | ok | 10.0 | 21 degrees C
ps0.f0.speed | 15h | ok | 10.0 | 11000 RPM
ps1.f0.speed | 19h | ok | 10.1 | 0 RPM
mb.t_amb | 1Ah | ok | 7.0 | 25 degrees C
mb.v_bat | 1Bh | ok | 7.0 | 3.18 Volts
mb.v_+3v3stby | 1Ch | ok | 7.0 | 3.17 Volts
mb.v_+3v3 | 1Dh | ok | 7.0 | 3.34 Volts
mb.v_+5v | 1Eh | ok | 7.0 | 5.04 Volts
mb.v_+12v | 1Fh | ok | 7.0 | 12.22 Volts
mb.v_-12v | 20h | ok | 7.0 | -12.20 Volts
mb.v_+2v5core | 21h | ok | 7.0 | 2.54 Volts
mb.v_+1v8core | 22h | ok | 7.0 | 1.83 Volts
mb.v_+1v2core | 23h | ok | 7.0 | 1.21 Volts
io.t_amb | 24h | ok | 15.0 | 21 degrees C
p0.t_core | 2Bh | ok | 3.0 | 44 degrees C
p0.v_+1v5 | 2Ch | ok | 3.0 | 1.56 Volts
p0.v_+2v5core | 2Dh | ok | 3.0 | 2.64 Volts
p0.v_+1v25core | 2Eh | ok | 3.0 | 1.32 Volts
p1.t_core | 34h | ok | 3.1 | 40 degrees C
p1.v_+1v5 | 35h | ok | 3.1 | 1.55 Volts
p1.v_+2v5core | 36h | ok | 3.1 | 2.64 Volts
p1.v_+1v25core | 37h | ok | 3.1 | 1.32 Volts
ft0.fm0.f0.speed | 43h | ok | 29.0 | 6000 RPM
ft0.fm1.f0.speed | 44h | ok | 29.1 | 6000 RPM
ft0.fm2.f0.speed | 45h | ok | 29.2 | 6000 RPM
ft1.fm0.f0.speed | 46h | ok | 29.3 | 6000 RPM
ft1.fm1.f0.speed | 47h | ok | 29.4 | 6000 RPM
ft1.fm2.f0.speed | 48h | ok | 29.5 | 6000 RPM
You can also generate a list of all sensors for a specific Entity. Use the list output to determine which entity you are interested in seeing, then use the sdr entity command to get a list of all sensors for that entity. This command accepts an entity ID and an optional entity instance argument. If an entity instance is not specified, it will display all instances of that entity.
The entity ID is given in the 4th field of the output, as read from left to right. For example, in the output shown in the previous example, all the fans are entity 29. The last fan listed (29.5) is entity 29, with instance 5:
ft1.fm2.f0.speed | 48h | ok | 29.5 | 6000 RPM
For example, to see all fan-related sensors, you would use the following command that uses the entity 29 argument.
ipmitool -I lanplus -H <IPADDR> -U root -P changeme sdr entity 29
ft0.fm0.fail | 3Dh | ok | 29.0 | Predictive Failure Deasserted
ft0.fm0.led | 00h | ns | 29.0 | Generic Device @20h:19h.0
ft0.fm1.fail | 3Eh | ok | 29.1 | Predictive Failure Deasserted
ft0.fm1.led | 00h | ns | 29.1 | Generic Device @20h:19h.1
ft0.fm2.fail | 3Fh | ok | 29.2 | Predictive Failure Deasserted
ft0.fm2.led | 00h | ns | 29.2 | Generic Device @20h:19h.2
ft1.fm0.fail | 40h | ok | 29.3 | Predictive Failure Deasserted
ft1.fm0.led | 00h | ns | 29.3 | Generic Device @20h:19h.3
ft1.fm1.fail | 41h | ok | 29.4 | Predictive Failure Deasserted
ft1.fm1.led | 00h | ns | 29.4 | Generic Device @20h:19h.4
ft1.fm2.fail | 42h | ok | 29.5 | Predictive Failure Deasserted
ft1.fm2.led | 00h | ns | 29.5 | Generic Device @20h:19h.5
ft0.fm0.f0.speed | 43h | ok | 29.0 | 6000 RPM
ft0.fm1.f0.speed | 44h | ok | 29.1 | 6000 RPM
ft0.fm2.f0.speed | 45h | ok | 29.2 | 6000 RPM
ft1.fm0.f0.speed | 46h | ok | 29.3 | 6000 RPM
ft1.fm1.f0.speed | 47h | ok | 29.4 | 6000 RPM
ft1.fm2.f0.speed | 48h | ok | 29.5 | 6000 RPM
Other queries can include a particular type of sensor. The command in the following example would return a list of all Temperature type sensors in the SDR.
ipmitool -I lanplus -H <IPADDR> -U root -P changeme sdr type temperature
sys.tempfail | 03h | ok | 23.0 | Predictive Failure Deasserted
mb.t_amb | 05h | ok | 7.0 | 25 degrees C
fp.t_amb | 14h | ok | 12.0 | 25 degrees C
ps.t_amb | 1Bh | ok | 10.0 | 24 degrees C
io.t_amb | 22h | ok | 15.0 | 23 degrees C
p0.t_core | 2Ch | ok | 3.0 | 35 degrees C
p1.t_core | 35h | ok | 3.1 | 36 degrees C
The ILOM SP System Event Log (SEL) provides storage of all system events. You can view the SEL with IPMItool. See the following sections.
There are two different IPMI commands that you can use to see different levels of detail.
ipmitool -I lanplus -H <IPADDR> -U root -P changeme sel list
100 | Pre-Init Time-stamp | Entity Presence #0x16 | Device Absent
200 | Pre-Init Time-stamp | Entity Presence #0x26 | Device Present
300 | Pre-Init Time-stamp | Entity Presence #0x25 | Device Absent
400 | Pre-Init Time-stamp | Phys Security #0x01 | Gen Chassis intrusion
500 | Pre-Init Time-stamp | Entity Presence #0x12 | Device Present
Note - When you use this command, an event record gives a sensor number, but does not display the name of the sensor for the event. For example, in line 100 in the sample output above, the sensor number 0x16 is displayed. For information about how to map sensor names to the different sensor number formats that might be displayed, see Sensor Numbers and Sensor Names in SEL Events. |
ipmitool -I lanplus -H <IPADDR> -U root -P changeme sel elist first 3
100 | Pre-Init Time-stamp | Temperature fp.t_amb | Upper Non-critical going high | Reading 31 > Threshold 30 degrees C
200 | Pre-Init Time-stamp | Power Supply ps1.pwrok | State Deasserted
300 | Pre-Init Time-stamp | Entity Presence ps1.prsnt | Device Present
Certain qualifiers are available to refine and limit the SEL output. If you want to see only the first NUM records, add that as a qualifier to the command. If you want to see the last NUM records, use that qualifier. For example, to see the last three records in the SEL, use this command:
ipmitool -I lanplus -H <IPADDR> -U root -P changeme sel elist last 3
800 | Pre-Init Time-stamp | Entity Presence ps1.prsnt | Device Absent
900 | Pre-Init Time-stamp | Phys Security sys.intsw | Gen Chassis intrusion
a00 | Pre-Init Time-stamp | Entity Presence ps0.prsnt | Device Present
If you want to get more detailed information on a particular event, you can use the sel get ID command, in which you specify an SEL record ID. For example:
ipmitool -I lanplus -H <IPADDR> -U root -P changeme sel get 0x0a00
SEL Record ID : 0a00
Record Type : 02
Timestamp : 07/06/1970 01:53:58
Generator ID : 0020
EvM Revision : 04
Sensor Type : Entity Presence
Sensor Number : 12
Event Type : Generic Discrete
Event Direction : Assertion Event
Event Data (RAW) : 01ffff
Description : Device Present
Sensor ID : ps0.prsnt (0x12)
Entity ID : 10.0
Sensor Type (Discrete): Entity Presence
States Asserted : Availability State
[Device Present]
In the example above, this particular event describes that the Power Supply #0 is detected and present.
To clear the SEL, use the sel clear command:
ipmitool -I lanplus -H <IPADDR> -U root -P changeme sel clear
Clearing SEL. Please allow a few seconds to erase.
When working with the ILOM SP, certain operations can be expensive in terms of execution time and the amount of data transferred. Typically, issuing the sdr elist command requires the entire SDR to be read from the SP. Similarly, the sel elist command needs to read both the SDR and the SEL from the SP in order to cross-reference events and display useful information.
To speed up these operations, it is possible to pre-cache the static data in the SDR and feed it back into IPMItool. This can have a dramatic effect in the processing time for some commands. In order to generate an SDR cache for later ruse, use the sdr dump command. For example:
ipmitool -I lanplus -H <IPADDR> -U root -P changeme sdr dump galaxy.sdr
Dumping Sensor Data Repository to 'galaxy.sdr'
After you have generated a cache file, it can be supplied to future invocations of IPMItool with the -S option. For example:
ipmitool -I lanplus -H <IPADDR> -U root -P changeme -S galaxy.sdr sel elist
100 | Pre-Init Time-stamp | Entity Presence ps1.prsnt | Device Absent
200 | Pre-Init Time-stamp | Entity Presence io.f0.prsnt | Device Absent
300 | Pre-Init Time-stamp | Power Supply ps0.vinok | State Asserted
...
Depending on which IPMI command you use, the sensor number that is displayed for an event might appear in slightly different formats. See the following examples:
The output from certain commands might not display the sensor name along with the corresponding sensor number. To see all sensor names in your server mapped to the corresponding sensor numbers, you can use the following command:
ipmitool -H 129.144.82.21 -U root -P changeme sdr elist
sys.id | 00h | ok | 23.0 | State Asserted
sys.intsw | 01h | ok | 23.0 |
sys.psfail | 02h | ok | 23.0 | Predictive Failure Asserted ...
In the sample output above, the sensor name is in the first column and the corresponding sensor number is in the second column.
For a detailed explanation of each sensor, listed by name, refer to the Integrated Lights Out Manager Supplement For Sun Fire X4100 and Sun Fire X4200 Servers, 819-5464.
You can view information about system hardware components. The software refers to these components as field-replaceable unit (FRU) devices.
To read the FRU inventory information on these servers, you must first have the FRU ROMs programmed. After that is done, you can see a full list of the available FRU data by using the fru print command, as shown in the following example (only two FRU devices are shown in the example, but all devices would be shown).
ipmitool -I lanplus -H <IPADDR> -U root -P changeme fru print
FRU Device Description : Builtin FRU Device (ID 0)
Board Mfg : BENCHMARK ELECTRONICS
Board Product : ASSY,SERV PROCESSOR,X4X00
Board Serial : 0060HSV-0523000195
Board Part Number : 501-6979-02
Board Extra : 000-000-00
Board Extra : HUNTSVILLE,AL,USA
Board Extra : b302
Board Extra : 06
Board Extra : GRASP
Product Manufacturer : SUN MICROSYSTEMS
Product Name : ILOM
FRU Device Description : sp.net0.fru (ID 2)
Product Manufacturer : MOTOROLA
Product Name : FAST ETHERNET CONTROLLER
Product Part Number : MPC8248 FCC
Product Serial : 00:03:BA:D8:73:AC
Product Extra : 01
Product Extra : 00:03:BA:D8:73:AC
In these servers, all LEDS are active-driven; that is, the SP is responsible for the I2C commands that assert and deassert each GPIO pin for each flash cycle.
The IPMItool command for reading LED status is:
ipmitool -I lanplus -H <IPADDR> sunoem led get <sensor ID>
The IPMItool command for setting LED status is:
ipmitool -I lanplus -H <IPADDR> sunoem led set <sensor ID> <LED mode>
It is possible for both of these commands to operate on all sensors at once by substituting all for the sensor ID. That way, you can easily get a list of all LEDs and their status with one command.
See LED Sensor IDs and LED Modes for information about the variables in these commands.
All LEDs in these servers are represented by two sensors:
Each LED has both a descriptor and a status reading sensor, and the two are linked; that is, if you use the .led sensor to turn on a particular LED, then the status change is represented in the associated .fail sensor. Also for some of these, an event is generated in the SEL. For LEDs that blink on failure instead of steady-on, there events are not generated (this is because display an event every time it flashed in the blink cycle).
TABLE D-2 lists the LED sensor IDs in these servers. See Status Indicator LEDs for diagrams of the LED locations.
You supply the modes in TABLE D-3 to the led set commands to specify in which mode you want the LED to be placed.
Because each LED has its own sensor and can be controlled independently, there is some overlap in sensors. In particular there are separate LEDs defined for the power, locate, and alert LEDs on the front and back panels.
It is desirable to have these sensors "linked" so that both the front and back panel LEDs can be controlled at the same time. This is handled through the use of Entity Association Records. These are records in the SDR that contain a list of entities that are considered part of a group.
For each Entity Association Record we also define another Generic Device Locator as a logical entity to indicate to system software that it refers to a group of LEDS rather than a single physical LED. TABLE D-4 describes the LED sensor groups.
For example, to set both the front and back panel Power/OK leds to a standby blink rate, you could use this command:
ipmitool -I lanplus -H <IPADDR> -U root -P changeme sunoem led set sys.power.led standby
Set LED fp.power.led to STANDBY
Set LED bp.power.led to STANDBY
Then you could turn off the back panel Power/OK LED but leave the front panel Power/OK LED blinking by using this command:
ipmitool -I lanplus -H <IPADDR> -U root -P changeme sunoem led set bp.power.led off
For testing purposes, it is often useful to change the status of all (or at least several) LEDs at once. You can do this by constructing an IPMItool script and executing it with the exec command.
For example, a script to turn on all Fan module LEDS would look like:
sunoem led set ft0.fm0.led on
sunoem led set ft0.fm1.led on
sunoem led set ft0.fm2.led on
sunoem led set ft1.fm0.led on
sunoem led set ft1.fm1.led on
sunoem led set ft1.fm2.led on
If this script file were then named, leds_fan_on.isc, you would use it in a command as shown here:
ipmitool -I lanplus -H <IPADDR> -U root -P changeme exec leds_fan_on.isc
Copyright © 2007, Sun Microsystems, Inc. All Rights Reserved.