Re: [Freeipmi-users] HP iL03 1.5 adds support for Drive Monitoring

[Albert Chu]

On Thu, 2013-01-17 at 10:03 +0100, Daniele Sluijters wrote:
> Hello,
> 
> I managed to get 1.1.5 going on the Debian machine.
> 
> Unfortunately, the ipmi-sensors -vv -r sensorid isn't particularly 
> informative:
> Record ID: 61
> Record Type: Full Sensor Record (1h)
> ID String: Cntlr 4 Bay 8
> Sensor Type: Drive Slot (Dh)
> Sensor Number: 239
> IPMB Slave Address: 10h
> Sensor Owner ID: 20h
> Sensor Owner LUN: 0h
> Channel Number: 0h
> Entity ID: disk or disk bay (4)
> Entity Instance: 8
> Entity Instance Type: Physical Entity
> Event/Reading Type Code: 6Fh
> Accuracy: 0.000000%
> Sensor Direction: Unspecified
> 
> Is this due to the FreeIPMI version or HP not providing the data? I'm getting 
> that
> same behaviour with about every sensor I try with -vv -r, Sensor Direction is 
> the
> last thing outputted. 

Skimming the code, it was available in the 1.1.X line.  It's very likely
the information just isn't available/published on your system.

> It would also seem that --output-sensors-state isn't doing anything for our HP
> machines right now, none of the output is affected.

At the minimum there should be a new column of output.  For example:

# > ipmi-sensors -g drive_slot        
ID | Name  | Type       | Reading    | Units | Event
66 | Drive | Drive Slot | N/A        | N/A   | 'Drive Presence'

# > ipmi-sensors --output-sensor-state -g drive_slot
ID | Name  | Type       | State    | Reading    | Units | Event
66 | Drive | Drive Slot | Nominal  | N/A        | N/A   | 'Drive Presence'

Are you not getting the column?  It's possible that if you're getting
nothing but N/As that the sensor state "interpretations" are not
programmed for the sensors on your motherboard. Which we can add them as
needed.

> Turns out that --bridge-sensors isn't going to work in our case, we have one 
> of
> the SmartArray controllers that do not feature the capability to provide 
> temperature
> information through IPMI (my best guess being there's no sensors for it on 
> the controller).
> 
> Is there some kind of wiki or another place for FreeIPMI where users could 
> document
> their findings working with different hardware? It might prove useful to 
> others without
> having to go through mailing list archives.

So far I document all hardware workarounds via the manpages and on the
webpage via a text document.  But this isn't so much a workaround but
more of a "what to expect on certain hardware".

I personally haven't set up a wiki, but that is a good idea and would be
useful.  Unfortunately, it seems that Savannah doesn't have a wiki
capability.

Al

> Kind regards,
> 
> -- 
> Daniele Sluijters
> w: http://www.nedap.com
> e: address@hidden
> t: +31 (0) 544 471 1764
> 
> N.V. Nederlandsche Apparatenfabriek 'Nedap'
> Parallelweg 2 NL-7141 DC GROENLO
> Trade Register 08013836
> 
> On Jan 16, 2013, at 18:50 , Albert Chu <address@hidden> wrote:
> 
> > On Wed, 2013-01-16 at 16:00 +0100, Daniele Sluijters wrote:
> >> Hello,
> >> 
> >> HP has "recently" released an update to iLO3, bringing it up to v1.50. 
> >> Most important in this update is
> >> the ability to monitor disk drives through IPMI. This update only applies 
> >> to BL/ML/SL/DL servers G7.
> >> 
> >> A complete list of enhancements can be found at: http://is.gd/aCWHvd
> >> 
> >> It seems unlikely a similar update is in the works for iLO2.
> >> 
> >> HP has also updated its severely limited documentation but doesn't seem to 
> >> have expanded the iLO
> >> sections in the documentation at all.
> >> 
> >> I've tested this on a few of our machines and with the new firmware and 
> >> freeipmi 0.7.17 (Debian stable).
> >> We now get disk status, the output looks like this:
> > 
> > As an FYI this is very old.  FreeIPMI already has gone through a line of
> > 0.8.X, 1.0.X, 1.1.X lines and now is at 1.2.4.
> > 
> >> 46: Cntlr 1 Bay 1 (Drive Slot): [Drive Presence]
> >> 47: Cntlr 1 Bay 2 (Drive Slot): [Drive Presence]
> >> 48: Cntlr 1 Bay 3 (Drive Slot): [Drive Presence]
> >> 49: Cntlr 1 Bay 4 (Drive Slot): [OK]
> >> 50: Cntlr 2 Bay 5 (Drive Slot): [Drive Presence]
> >> 51: Cntlr 2 Bay 6 (Drive Slot): [Drive Presence]
> >> 52: Cntlr 2 Bay 7 (Drive Slot): [Drive Presence]
> >> 53: Cntlr 2 Bay 8 (Drive Slot): [Drive Presence]
> >> 54: Cntlr 3 Bay 1 (Drive Slot): [Drive Presence]
> >> 55: Cntlr 3 Bay 2 (Drive Slot): [Drive Presence]
> >> 56: Cntlr 3 Bay 3 (Drive Slot): [Drive Presence]
> >> 57: Cntlr 3 Bay 4 (Drive Slot): [Drive Presence]
> >> 58: Cntlr 4 Bay 5 (Drive Slot): [Drive Presence]
> >> 59: Cntlr 4 Bay 6 (Drive Slot): [Drive Presence]
> >> 60: Cntlr 4 Bay 7 (Drive Slot): [Drive Presence]
> >> 61: Cntlr 4 Bay 8 (Drive Slot): [Drive Presence]
> >> 
> >> A status of OK means there's no drive installed in that slot, Drive 
> >> Presence means a drive is installed and
> >> operational. Turning on the UID of a drive does not affect the output, it 
> >> will still display Drive Presence or OK.
> >> I've yet to determine what it will output when a drive is failing.
> > 
> > It depends on the manufacturer.  The possible outputs for a drive are:
> > 
> >    "Drive Presence",
> >    "Drive Fault",
> >    "Predictive Failure",
> >    "Hot Spare",
> >    "Consistency Check / Parity Check in progress",
> >    "In Critical Array",
> >    "In Failed Array",
> >    "Rebuild/Remap in progress",
> >    "Rebuild/Remap Aborted (was not completed normally)",
> > 
> > the manufacturer can implement all, none, or some of these.  If you look
> > at the output of ipmi-sensors w/ -vv you should be able to see what
> > events are possible on your hardware (caveat: I'm not sure if this is
> > available in 0.7.0, it's a half new feature).  In the newer FreeIPMI I
> > see something like this:
> > 
> > # ipmi-sensors -vv -r 48
> > Record ID: 48
> > Record Type: Compact Sensor Record (2h)
> > ID String: Drive
> > Sensor Type: Drive Slot (Dh)
> > Sensor Number: 128
> > IPMB Slave Address: 10h
> > Sensor Owner ID: 20h
> > Sensor Owner LUN: 0h
> > Channel Number: 0h
> > Entity ID: Disk Drive Bay (26)
> > Entity Instance: 1
> > Entity Instance Type: Physical Entity
> > Event/Reading Type Code: 6Fh
> > Sensor Direction: Unspecified
> > Assertion Event Enabled: 'Drive Presence'
> > Assertion Event Enabled: 'Drive Fault'
> > Deassertion Event Enabled: 'Drive Presence'
> > Deassertion Event Enabled: 'Drive Fault'
> > Share Count: 8
> > ID String Instance Modifier Type: Numeric
> > ID String Instance Modifier Offset: 0
> > Entity Instance Sharing: Same for all records
> > Sensor Event: 'OK'
> > 
> > So in this drive slot sensor, the only events are 'Drive Presence' and
> > 'Drive Fault' (similarly it outputs 'OK' b/c there is no drive here).
> > 
> > In newer FreeIPMIs there is an option --output-sensor-state that will
> > map all of the errors into either NOMINAL, WARNING, or CRITICAL status,
> > which is easier for scripting and monitoring.  The same status can be
> > found in the old ipmimonitoring tool.
> > 
> >> ipmi-sensors -L now also has a new category:
> >> Drive_Slot
> >> 
> >> According to the release notes it it also possible to read temperature 
> >> sensors on select Smart Array Controllers,
> >> but I haven't been able to figure out what ours are and if it should work.
> > 
> > One possibility is that sensor bridging needs to be done to do this.  It
> > can be done w/ --bridge-sensors.
> > 
> >> bmc-info now gives:
> >> 
> >> Device ID:         19
> >> Device Revision:   1
> >> Firmware Revision: 1.50
> >>                   [Device Available (normal operation)]
> >> IPMI Version:      2.0
> >> Additional Device Support:
> >>                   [Sensor Device]
> >>                   [SDR Repository Device]
> >>                   [SEL Device]
> >>                   [FRU Inventory Device]
> >>                   [Chassis Device]
> >> Manufacturer ID:   11
> >> Product ID:        8192
> >> Channel Information:
> >>       Channel No: 0
> >>      Medium Type: IPMB (I2C)
> >>    Protocol Type: IPMB-1.0
> >>       Channel No: 2
> >>      Medium Type: 802.3 LAN
> >>    Protocol Type: IPMB-1.0
> >>       Channel No: 7
> >>      Medium Type: OEM
> >>    Protocol Type: KC
> >> 
> >> Kind regards,
> >> 
> > -- 
> > Albert Chu
> > address@hidden
> > Computer Scientist
> > High Performance Systems Division
> > Lawrence Livermore National Laboratory
> > 
> > 
> 
-- 
Albert Chu
address@hidden
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory