Smart Array 6i, SNMP traps for physical disk failure (Linux)

[Asko Tuomela]

Proliant Smart Array 6i monitoring using snmp:

I have installed/configured hpasm and snmpd, and snmp traps are successfully sent to monitoring system when eg. redundant power supply fails. However, physical disk failure in Smart Array 6i doesn't produce snmp trap. Disk failure can't be seen in hplog -v either:
"
# hplog -v

ID Severity Initial Time Update Time Count
-------------------------------------------------------------
0003 Caution 13:15 05/04/2005 13:42 05/04/2005 0005
LOG: POST Error: 1794-Drive Array - Array Accelerator Battery Charge Low

0004 Caution 13:09 02/13/2006 13:09 02/13/2006 0001
LOG: POST Error: 1724-Drive Array - Physical Drive Position Change(s) Detected

0005 Caution 13:10 02/13/2006 13:10 02/13/2006 0001
LOG: POST Error: 1786-Drive Array Recovery Needed

0006 Repaired 15:05 04/10/2006 15:13 04/10/2006 0001
LOG: System Power Supply: General Failure (Power Supply 2)

0007 Repaired 15:05 04/10/2006 15:13 04/10/2006 0001
LOG: System Power Supplies Not Redundant
"
However, there are some other Smart Array 6i alarms.

Am I missing some software component? hpacucli can show failed disk, can I configure it to send snmp trap when disk fails?


Thanks in advance,
Asko Tuomela

[Christian Charette]

Had a similar problem.

Try installing cciss (Smart Array Controller Driver) first before installing HPASM. The hooks hpasm uses to monitor disk status are not normally included in standard Linux, and must be installed using this driver.

For the latest drivers, you may also need to make sure the OpenIPMI package is installed.

[David Claypool]

Who is the receiver of the SNMP trap? Are you sure it's not the receiver that is ignoring the trap?

"hplog -v" is showing what's in the Integrated Maangement Log in NVRAM. It's independent of having the software set up correctly. When you pull the drive, do you get any messages in /var/log/messages? That would tell you if the storage agents are correctly set up.

What version of hpasm are you using? Does your receiving end have a MIB of a matching version? There has been quite a bit of volatility in the storage section of the MIBs and un-matched MIB versions can cause what you're reporting...