Important: If want to configure a machine that's located in either AT or KB for this purpose, please refer to the AT & KB IPMI power management for older machines equipped with IPMI v1.5 instructions instead. |
Ctrl-E
when prompted in order to enter the Remote Access Configuration Utility, then make the following changes:
Remote Access Configuration Utility | DEFAULT: | CHANGE TO: |
---|---|---|
IPMI Over LAN | Off | On |
LAN Parameters -> | ||
IP Address Source | Static | DHCP |
MAC Address | < take a note of this > | |
VLAN Enable | Off | On |
VLAN ID | 0001 | 468 |
LAN User Configuration -> | ||
Account User Name: | root | root |
Enter Password: | < something you can remember > |
scimitar
(i.e. the old mars7
).
192.168.68/23
.
SOL
(i.e. the VLAN whose 802.1Q tag is 468
) as an additional tagged VLAN. To achieve this, the machine's port entry in the relevant ports file needs to look something like:port n myserver - S33 SOL
<machinename>.bmc.inf.ed.ac.uk
bmchostname
and bmcmac
must both be specified: bmchostname
should be the fully-qualified domain name chosen in the preceding step; bmcmac
should be the MAC address identified in Section 2 above.
[sandilands]idurkacz: rfe -g lcfg/myserver
...[snip]... dhclient.hostname myserver.inf.ed.ac.uk dhclient.mac 00:1d:09:6a:c9:b7 !dhclient.cluster mSET(dhcp/all) /* BMC */ dhclient.bmchostname myserver.bmc.inf.ed.ac.uk dhclient.bmcmac 00:1d:09:6a:c9:bb !dhclient.cluster mADD(dhcp/forum/consoles) /* Inventory information */ ...[snip]...Allow time for these DNS and DHCP changes to propagate.
ping
'ing the BMC. This appears to be normal for Dell BMC's which implement IPMI v1.5: they don't respond to ping
requests.)
Now, set its 'root' user password to our standard one, using the conserver-ipmisetpass
command (which is provided by the conserver
component) as follows:
ssh
to marriner
nsu
to root
/usr/sbin/conserver-ipmisetpass -I lan <machinename>.bmc
marriner
) via IPMI. To do this, use the conserver-ipmipower
command (a wrapper to ipmitool
) which is provided by the conserver
component:
ssh
to marriner
nsu
to root
/usr/sbin/conserver-ipmipower -I lan <bmchostname> <power command>
[marriner]root: /usr/sbin/conserver-ipmipower Usage: conserver-ipmipower [-hv] [-I <channel>] <bmchostname> <power command> Wrapper for 'ipmitool -I <channel> -H <bmchostname> chassis power <power command>' Options: -h This help -v Verbose -I <channel> Selects the IPMI interface to be used Must be either 'lanplus' (the default) or 'lan' chassis power Commands: status, on, off, cycle, reset, diag, soft [marriner]root: /usr/sbin/conserver-ipmipower -I lan myserver.bmc status Chassis Power is onThe effect of the various power commands is as follows:
status | Show current power status |
on | Power up chassis, and reboot |
off | Power down chassis (Note that this does not initiate a clean shutdown: the effect is the same as abruptly hitting the front-panel power button.) |
cycle | Power cycle chassis (Has the effect: abrupt power off, 1 second wait, power on.) |
soft | Initiate a soft shutdown and power-off of a live machine (Has the effect of shutdown -h now .) |
AC Power Recovery
parameter has no effect on any of the above behaviour. That setting affects the behaviour of the system when mains power is restored to the system as a whole (i.e. through the incoming power cables); but the fact that the IPMI interface is functional at all implies that mains power is being applied to the system. So, for example, a soft shutdown, followed by a on, should always result in a reboot.
For more information on the details of the available power commands, man ipmitool
.
ping
requests. That can be confusing, and certainly makes liveness testing difficult. Looking at the DHCP logs (found in /var/log/lcfg/syslog
) on the relevant site DHCP server can be useful if you're trying to ascertain whether or not a BMC is acquiring an IP address as expected.
"BMC management traffic will not function if the LAN on motherboard (LOM) is used in an EtherChannel or Link Aggregation team."The implication is that IPMI will probably not work as expected on a machine which is equipped with IPMI v1.5 and which has also been set up to use a pair of bonded ethernet interfaces. Certainly, IPMI traffic will not failover in such circumstances (as it does when configured appropriately on a Dell equipped with IPMI v2.0). Any such configuration should be tested - it's possible that the results will vary from one machine model to another.
xterm
as follows:
nsu
to root.
/sbin/modprobe ipmi_msghandler /sbin/modprobe ipmi_si /sbin/modprobe ipmi_devintf
ipmitool bmc info
and look for the IPMI Version
field.