[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: t5140 hardware monitoring from the os + raid + sparc64



You can use ipmitool[1] to grab HW info (temps, voltages, fault status, etc) from the LoM, and if you have a RAID card, use the megacli utility to grab RAID status info[2]


Info from the above tools can be polled via snmpd with the addition of some 'exec' statements to your snmpd.conf, or you can have your monitoring-tool-of-choice execute commands locally on the node to parse-and-return the values you want to monitor[3]


[1] http://docs.oracle.com/cd/E24707_01/html/E24528/z400000c1016683.html
[2] https://distortion.io/p/8
[3] http://www.barryodonovan.com/2007/04/11/dell-ipmi



> On Sep 9, 2015, at 12:58 PM, Mark Morgan Lloyd <markMLl.debian-sparc@telemetry.co.uk> wrote:
> 
> Harka Gyozo SA wrote:
>> Hi!
>> I'm new to this list, I have debian on fire V240, blade100, t2000, and now on
>> a t5140.
>> So on the t5140 the debian runs well, there was no problem with the install.
>> The sc's snmp, and so on is really impressive, but I wanted to get
>> temperatures, ventillators state, etc. from the os. Is there any support for it?
>> Or should I use snmp to get the values from the sc? (management is on
>> different vlan now, so I would avoid connections to there if there is another
>> solution)
>> lm-sensors dmi scanning stopped the whole server :(
>> For the raid as I can see there is only solaris utils, etc. have I right that
>> it's a fakeraid? So I don't have to try hard to use that, and in this case the
>> sw raid is my friend?
> 
> I make no claim to be an expert here, but my understanding is that there is no general Linux support for temperature etc. monitoring and that Sun/Oracle have always held this sort of thing fairly close to their chest.
> 
> I did hack together a partial solution which relied on the OpenBoot (i.e. Forth) lom@ and lom! commands, however since (a) these are only supported on a very small number of systems (b) using these will temporarily monopolise the kernel (c) there's no reentrancy protection and (d) the code makes absolutely no attempt to test compatibility or recover from errors I really don't suggest that you try doing things this way.
> 
>> That sparc64 platform is pretty unclear for me, can I benefit anything from it?
> 
> My understanding is that it's work-in-progress and too immature for serious use.
> 
> -- 
> Mark Morgan Lloyd
> markMLl .AT. telemetry.co .DOT. uk
> 
> [Opinions above are the author's, not those of his employers or colleagues]
> 


Reply to: