Visuals of the final version might differ slightly. However, the video below should give a good idea on how the screen will look like.

Update 1.3 for both apps is now available on the AppStore!

In addition to unconditional power on/off functionality currently implemented in the app, IPMI protocol provides a way to cleanly shutdown a machine (‘chassis power soft’ command in ipmitool). The action is equivalent to physically pushing server’s power button and should results in orderly or graceful shutdown if supported by OS.

The thinking behind not including soft shutdown originally was that if the server is up then there is a way to get to it (via remote desktop, SSH, VNC etc) to call normal shutdown and therefor the functionality is redundant. However, it is clear now that it is really convenient to have that option exposed in IPMI touch.

Below are two V1.3 screenshots showing new Soft-shutdown button and Soft-shutdown request in progress status message.

System Power         : on
Power Overload       : false
Power Interlock      : inactive
Main Power Fault     : false
Power Control Fault  : false
Power Restore Policy : always-off
Last Power Event     : command
Chassis Intrusion    : inactive
Front-Panel Lockout  : inactive
Drive Fault          : false
Cooling/Fan Fault    : false
Front Panel Light    : off
Sleep Button Disable : not allowed
Diag Button Disable  : not allowed
Reset Button Disable : not allowed
Power Button Disable : allowed
Sleep Button Disabled: false
Diag Button Disabled : false
Reset Button Disabled: false
Power Button Disabled: true

As of version 1.2 the app does not collect and show all data provided by the status command. The list is very extensive. We made a decision to concentrate on fault flags first.

Below are two screenshots showing a trouble free server (front panel locked) and a server with a security violation.

Unlike compact SDRs, full IPMI sensors usually report a value that a sensor is able to measure and a unit of measurement. To help identify fails and warnings each full sensor is also programmed with a set of limits that define normal and abnormal operational ranges; or to be more precise, upper and lower limits for non-critical, critical and non-recoverable sensor reads. It is worth mentioning that the values are intended for informational purposes only. They are not used to identify problems directly. Instead, IPMI-over-LAN protocol defines a bit-mask with six dedicated values for each abnormal event: LNR for Lower non-recoverable, LCR for Lower critical, UNC for Upper non-critical and so on.

Deciding which groups to include is a balancing act. Too many and the app slows down too much (i.e. forget running on Edge). Too few and the usefulness is hard to justify. An option to control the list of sensor groups for every server is probably ideal but will require major rethinking of how the application manages and stores its state. Definitely not something we want to deal with for 1.X versions.

Security groups seem to be a needed addition though. On most hardware the groups only include a handful of sensors so the extra overhead is really low. More importantly, it will provide essential clarification for security-related alarms. Chassis status cell already shows an aggregated  security indicator (lock icon) that lights up red if security is compromised. However by design it does not provide any explanation of what happened.

With new groups the apps will potentially recognize (depending on server’s BMC) and report the following list of events:

Screenshots below show output from a server running with cover off.

First stop is compact sensors. Unlike full sensors, IPMI compact sensors do not have a value or reading. Instead, compact SDRs have a list of supported ‘events’ they can potentially report. Any number of events from the supported list can be active (raised) at a given time. For example the Power Supply sensor (VRM) below can simultaneously report ‘Presence detected’ (meaning that the device itself exists) and ‘AC lost’ (meaning that it does not have any AC).

This was one of the easier things to implement. Sensor events are represented as bit masks in IPMI-over-LAN protocol. The data was already stored in the app so no extensive re-working was needed. There is a lot of information for every sensor to potentially display (think ipmitool sdr get) but we are going to start with the most essential parts first. Oh, and one more thing, events are color-coded to illustrate the severity of the problem.

]]> http://www.yellowkompressor.com/ipmi-touch/2010/04/inactive/feed/ 0