IPMI on these systems is nearly as straightforward as it ought to be. There were only a few 'annoyances' which I'll briefly mention, in case anyone else sees them / and wonders if they are alone.

I had initially followed hints from the URL, http://lonesysadmin.net/2007/06/21/how-to-configure-ipmi-on-a-dell-poweredge-running-red-hat-enterprise-linux/ , regarding setup of OpenIPMI on RHEL/ CentOS - which is a site that Dell tech support unofficially referred me to at a later time :-)

Basic drill:

  • if you are booting the systems anyhow, press Ctrl-E at boot time and enable IPMI; then configure a static IP for IPMI access, and set a password for "root" user.
  • otherwise, you will have to install openipmi-tools to configure these parameters from command-line on each system.
  • note in some cases you may have to use openipmitools to do it, even if you set at boot the parameters. For a group of 27 pe1950 systems recently configured, I found that approximately 5 machines failed to 'work' for IPMI until impi-tools was used to set parameters. ie, setting via BIOS didn't work perfectly in all cases, and I have no idea why. But at least it worked fine after ipmi-tools was used.

Basic assumptions, I believe:

  • IPMI is a 'shared' interface off the first physical interface of the system
  • IPMI won't be happy if that interface is trunked at the OS level with any other interface
  • the easiest way to access the IPMI interface, is from other machines in the same physical subnet / as the first interfaces where IPMI is exposed.

In my case, for illustrative example:

  • "Head Node" system eth0 was configured as 10.1.1.1 subnet; IPMI piggyback on this was configured as 192.168.35.29 . A virtual interface, eth0:1 was plumbed with an IP of 192.168.35.229 so it was possible to "ping" the IPMI interfaces of all (27) machines in this same physical subnet / network.
  • note, it seems that a machine configured thus is unable to ping its OWN IPMI interface, nor to issue commands to that interface. Presumably a feature of the virtual interface / IPMI interface and how the 'coexist'.

So, a few examples / work captures for reference:

Install IPMI Tools, and get IPMI enabled to run at boot: 

  483  yum install OpenIPMI-tools
  485  chkconfig --list ipmi
  486  chkconfig --level 2345 ipmi on
  487  service ipmi start

Poll a nearby machine to see IPMI is behaving as expected: 

root@box ~]# ipmitool -I lan -U root -H 192.168.35.12 -a chassis power status
Password: GIVE_PASSWORD_HERE
Chassis Power is on


Send the power cycle command:
[root@box ~]# ipmitool -I lan -U root -H 192.168.35.12 -a chassis power cycle
Password: GIVE_PASSWORD_HERE
Chassis Power Control: Cycle

In theory you have just power cycled the machine specified by 192.168.35.12; give it a minute to recover and it should be back following a boot cycle.

Note that if IPMI was NOT working / configured happily on a given node, you will see something like this when you try to poll IPMI status: 

[root@box ~]# ipmitool -I lan -U root -H 192.168.35.6 -a chassis power status
Password:
Activate Session command failed
Error: Unable to establish LAN session
Unable to get Chassis Power Status
[root@box ~]# ipmitool -I lan -U root

In a problem case like this,

  • Connect to the 'problem system'
  • ensure IPMI tools are installed
  • Configure local parameters directly
  • then repeat your test to see if IPMI behaves when polled remotely.

Approximately as follows, 


  /usr/bin/ipmitool -I open lan set 1 ipaddr 192.168.35.23
  /usr/bin/ipmitool -I open lan set 1 defgw ipaddr 192.168.35.29
  /usr/bin/ipmitool -I open lan set 1 netmask 255.255.255.0
  /usr/bin/ipmitool -I open lan set 1 access on
  /usr/bin/ipmitool -I open lan set 1 password @b1ggl35!
  /usr/bin/ipmitool -I open user set password 2 @b1ggl35!
  /usr/bin/ipmitool -I open lan print 1

you should expect the last command to return output approx thus, 


[root@compute-0-20 ~]#   /usr/bin/ipmitool -I open lan print 1
Set in Progress         : Set Complete
Auth Type Support       : NONE MD2 MD5 PASSWORD
Auth Type Enable        : Callback : MD2 MD5
                        : User     : MD2 MD5
                        : Operator : MD2 MD5
                        : Admin    : MD2 MD5
                        : OEM      :
IP Address Source       : Static Address
IP Address              : 192.168.35.23
Subnet Mask             : 255.255.255.0
MAC Address             : 00:22:19:4f:bd:72
SNMP Community String   : public
IP Header               : TTL=0x40 Flags=0x40 Precedence=0x00 TOS=0x10
Default Gateway IP      : 192.168.35.29
Default Gateway MAC     : 00:00:00:00:00:00
Backup Gateway IP       : 0.0.0.0
Backup Gateway MAC      : 00:00:00:00:00:00
802.1q VLAN ID          : Disabled
802.1q VLAN Priority    : 0
RMCP+ Cipher Suites     : 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14
Cipher Suite Priv Max   : aaaaaaaaaaaaaaa
                        :     X=Cipher Suite Unused
                        :     c=CALLBACK
                        :     u=USER
                        :     o=OPERATOR
                        :     a=ADMIN
                        :     O=OEM
[root@compute-0-20 ~]#

and in theory, after doing this, the 'problem node' may be more responsive to remote IPMI requests from nearby machines / without complaints regarding "can't establish LAN Connection".

your mileage may vary :-)