| Sun Fire X4500/X4540 Servers Diagnostics Guide |    
|
| C H A P T E R 12 |
|
Using IPMItool to View System Information |
This chapter contains information about using the Intelligent Platform Management Interface (IPMI) to view monitoring and maintenance information for your server. This chapter includes 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. Second, the operating system is not burdened with transporting system status data.
Your Sun Fire X4540 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 a simple, command-line interface used to manage IPMI-enabled devices. You can use this utility to perform IPMI functions with a kernel device driver or over a LAN interface. IPMItool allows you to manage system hardware components, monitor system health, and monitor and manage system environmentals, independent of the operating system.
IPMItool is included on the Sun Fire X4540 server Tools and Drivers CD (705-1438). Locate IMPItool and its related documentation on your Sun Fire X4540 Server Tools and Drivers CD, or download this tool at:
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 the following command:
To connect over a remote interface, you must supply a user name and password. The default user with administrator-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.
To enable the anonymous user, type the following commands:
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 1 false false true NO ACCESS 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 Deleted SSH key for user id 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 Administration Guide, 819-1160.
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.
For information on the physical locations of the sensors in the system, see Sun Fire X4540 Sensor Locations.
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 12-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 Cps.t_amb | 11h | ok | 10.0 | 21 degrees Cps0.f0.speed | 15h | ok | 10.0 | 11000 RPMps1.f0.speed | 19h | ok | 10.1 | 0 RPMmb.t_amb | 1Ah | ok | 7.0 | 25 degrees Cmb.v_bat | 1Bh | ok | 7.0 | 3.18 Voltsmb.v_+3v3stby | 1Ch | ok | 7.0 | 3.17 Voltsmb.v_+3v3 | 1Dh | ok | 7.0 | 3.34 Voltsmb.v_+5v | 1Eh | ok | 7.0 | 5.04 Voltsmb.v_+12v | 1Fh | ok | 7.0 | 12.22 Voltsmb.v_-12v | 20h | ok | 7.0 | -12.20 Voltsmb.v_+2v5core | 21h | ok | 7.0 | 2.54 Voltsmb.v_+1v8core | 22h | ok | 7.0 | 1.83 Voltsmb.v_+1v2core | 23h | ok | 7.0 | 1.21 Voltsio.t_amb | 24h | ok | 15.0 | 21 degrees Cp0.t_core | 2Bh | ok | 3.0 | 44 degrees Cp0.v_+1v5 | 2Ch | ok | 3.0 | 1.56 Voltsp0.v_+2v5core | 2Dh | ok | 3.0 | 2.64 Voltsp0.v_+1v25core | 2Eh | ok | 3.0 | 1.32 Voltsp1.t_core | 34h | ok | 3.1 | 40 degrees Cp1.v_+1v5 | 35h | ok | 3.1 | 1.55 Voltsp1.v_+2v5core | 36h | ok | 3.1 | 2.64 Voltsp1.v_+1v25core | 37h | ok | 3.1 | 1.32 Voltsft0.fm0.f0.speed | 43h | ok | 29.0 | 6000 RPMft0.fm1.f0.speed | 44h | ok | 29.1 | 6000 RPMft0.fm2.f0.speed | 45h | ok | 29.2 | 6000 RPMft1.fm0.f0.speed | 46h | ok | 29.3 | 6000 RPMft1.fm1.f0.speed | 47h | ok | 29.4 | 6000 RPMft1.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 fourth 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 Deassertedft0.fm0.led | 00h | ns | 29.0 | Generic Device @20h:19h.0ft0.fm1.fail | 3Eh | ok | 29.1 | Predictive Failure Deassertedft0.fm1.led | 00h | ns | 29.1 | Generic Device @20h:19h.1ft0.fm2.fail | 3Fh | ok | 29.2 | Predictive Failure Deassertedft0.fm2.led | 00h | ns | 29.2 | Generic Device @20h:19h.2ft1.fm0.fail | 40h | ok | 29.3 | Predictive Failure Deassertedft1.fm0.led | 00h | ns | 29.3 | Generic Device @20h:19h.3ft1.fm1.fail | 41h | ok | 29.4 | Predictive Failure Deassertedft1.fm1.led | 00h | ns | 29.4 | Generic Device @20h:19h.4ft1.fm2.fail | 42h | ok | 29.5 | Predictive Failure Deassertedft1.fm2.led | 00h | ns | 29.5 | Generic Device @20h:19h.5ft0.fm0.f0.speed | 43h | ok | 29.0 | 6000 RPMft0.fm1.f0.speed | 44h | ok | 29.1 | 6000 RPMft0.fm2.f0.speed | 45h | ok | 29.2 | 6000 RPMft1.fm0.f0.speed | 46h | ok | 29.3 | 6000 RPMft1.fm1.f0.speed | 47h | ok | 29.4 | 6000 RPMft1.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 Deassertedmb.t_amb | 05h | ok | 7.0 | 25 degrees Cfp.t_amb | 14h | ok | 12.0 | 25 degrees Cps.t_amb | 1Bh | ok | 10.0 | 24 degrees Cio.t_amb | 22h | ok | 15.0 | 23 degrees Cp0.t_core | 2Ch | ok | 3.0 | 35 degrees Cp1.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. This topic includes 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 Absent200 | Pre-Init Time-stamp | Entity Presence #0x26 | Device Present300 | Pre-Init Time-stamp | Entity Presence #0x25 | Device Absent400 | Pre-Init Time-stamp | Phys Security #0x01 | Gen Chassis intrusion500 | 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, type the following command:
ipmitool -I lanplus -H <IPADDR> -U root -P changeme sel elist last 3 800 | Pre-Init Time-stamp | Entity Presence ps1.prsnt | Device Absent900 | Pre-Init Time-stamp | Phys Security sys.intsw | Gen Chassis intrusiona00 | 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 : 0a00Record Type : 02Timestamp : 07/06/1970 01:53:58Generator ID : 0020EvM Revision : 04Sensor Type : Entity PresenceSensor Number : 12Event Type : Generic DiscreteEvent Direction : Assertion EventEvent Data (RAW) : 01ffffDescription : Device Present Sensor ID : ps0.prsnt (0x12)Entity ID : 10.0Sensor Type (Discrete): Entity PresenceStates Asserted : Availability State [Device Present]
In the example above, this particular event describes that Power Supply #0 is detected and present.
To clear the SEL, type 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 use, type 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 Absent200 | Pre-Init Time-stamp | Entity Presence io.f0.prsnt | Device Absent300 | 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.
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 activity-oriented; 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 this server 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, the events are not generated (this is because it would display an event every time the LED flashed in the blink cycle).
TABLE 12-2 lists the LED sensor IDs in these servers. See Identifying Status and Fault LEDs for diagrams of the LED locations.
You supply the modes in TABLE 12-3 to the led set commands to specify the mode in which 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 12-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 type the following command:
ipmitool -I lanplus -H <IPADDR> -U root -P changeme sunoem led set sys.power.led standby Set LED fp.power.led to STANDBYSet LED bp.power.led to STANDBY
You could turn off the back panel Power/OK LED but leave the front panel Power/OK LED blinking by typing the following command:
ipmitool -I lanplus -H <IPADDR> -U root -P changeme sunoem led set bp.power.led off Set LED bp.power.led to 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.
The following example shows a script to turn on all fan module LEDS:
sunoem led set ft0.fm0.led onsunoem led set ft0.fm1.led onsunoem led set ft0.fm2.led onsunoem led set ft1.fm0.led onsunoem led set ft1.fm1.led onsunoem 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 follows:
ipmitool -I lanplus -H <IPADDR> -U root -P changeme exec leds_fan_on.isc
| Sun Fire X4500/X4540 Servers Diagnostics Guide | 819-4363-12 |
|
Copyright © 2009 Sun Microsystems, Inc. All rights reserved.