AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20090415170102.1180e4b2@ripper.onstor.net>
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:mail.onstor.net
NSV:
SSH:
R:<brian.stark@onstor.com>
MAID:1
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/andys@onstor.net@exch1.onstor.net/INBOX	0	49E674C2.4030204@nexenta.com
X-Sylpheed-End-Special-Headers: 1
Date: Wed, 15 Apr 2009 17:01:18 -0700
From: Andrew Sharp <andy.sharp@onstor.com>
Cc: Brian Stark <brian.stark@onstor.com>
Subject: Re: storage JBOD fault reporting
Message-ID: <20090415170118.55212a95@ripper.onstor.net>
In-Reply-To: <49E674C2.4030204@nexenta.com>
References: <20090414120057.1c9dd707@ripper.onstor.net>
	<49E51ABD.7040504@nexenta.com>
	<102AB4F33EBBDB4C91915B145C8E9FB31284F9B535@exch1.onstor.net>
	<49E66CE7.1000802@nexenta.com>
	<6041AEBD8A3E264785ABDA2F60B52DB4FEE6E01D@exch1.onstor.net>
	<102AB4F33EBBDB4C91915B145C8E9FB31284F9B542@exch1.onstor.net>
	<49E674C2.4030204@nexenta.com>
Organization: Onstor
X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Ahahahahahahahaaaaaaaaaaaa


On Wed, 15 Apr 2009 16:58:58 -0700 Alex Aizman <alex@nexenta.com> wrote:

> None. The whole subject of SES integration is at its initial stage. We 
> just started with slot mapping and drive blinking on demand.
> 
> Thanks
> 
> Brian Stark wrote:
> > Alex,
> > 
> > Which of the runners would flag events like power supply and fan failures?  
> > 
> > 
> > Brian
> > 
> > 
> > -----Original Message-----
> > From: Brian Stark 
> > Sent: Wednesday, April 15, 2009 4:31 PM
> > To: Alex Aizman
> > Cc: Dmitry Yusupov; Andy Sharp
> > Subject: RE: storage JBOD fault reporting
> > 
> > Alex,
> > 
> > We're not seeing any events reported by FMA when we pull a power supply out, induce a fan failure, etc. in the server or the JBOD.  When we induce one of these events, 'fmdump' is empty.
> > 
> > 
> > Brian
> > 
> > 
> > -----Original Message-----
> > From: Alex Aizman [mailto:alex@nexenta.com] 
> > Sent: Wednesday, April 15, 2009 4:25 PM
> > To: Brian Stark
> > Cc: Dmitry Yusupov; Andy Sharp
> > Subject: Re: storage JBOD fault reporting
> > 
> > It is configured. If we are not getting events, or getting them 
> > belatedly, that'd be a bug..
> > 
> > Brian Stark wrote:
> >> Dmitry,
> >>
> >> We've done some reading on FMA, but it's not clear how we configure
> >> FMA to capture events.  Unlike processor and memory faults, it's also
> >> not clear that FMA can capture the events like fan and power supply
> >> failures on either the server or JBOD.
> >>
> >> Could you provide some further details on how FMA could be used for
> >> this?  Do you have examples of how we would configure FMA?
> >>
> >> We've also seen some examples of how to use ipmitool to query BMC
> >> modules in the server.  This would cover the hardware events like fan
> >> and power supply failures.  However, ipmitool does not appear to be
> >> installed.
> >>
> >>
> >> Thanks, Brian
> >>
> >>
> >> -----Original Message----- From: Dmitry Yusupov
> >> [mailto:dmitry@nexenta.com] Sent: Tuesday, April 14, 2009 4:23 PM To:
> >> Andy Sharp Cc: Alex Aizman; Brian Stark Subject: Re: storage JBOD
> >> fault reporting
> >>
> >> Hi Andrew,
> >>
> >> I would let ZFS handle error. We have full blown FMA integration, so
> >> in case of ZFS detecting error, the e-mail with FMA details will be
> >> sent. Customer also could dump FMA events using fmadm/fmdump
> >> commands.
> >>
> >> Thanks!
> >>
> >> Andrew Sharp wrote:
> >>> Hi Dmitry,
> >>>
> >>> I'm temporarily filling in for Larry as best I can, and I have a 
> >>> question regarding snmp that I hope you can address.
> >>>
> >>> I need to connect up log messages coming in from syslog that are
> >>> caused by non-disk fault events on the JBOD, like fan or power
> >>> supply death and so forth.
> >>>
> >>> So I need to get those events into either the nexenta fault
> >>> reporting infrastructure, or simply comb that log data for the
> >>> particular messages we're looking for and use the snmptrap command
> >>> to issue an snmp trap.  The second option would be the easiest and
> >>> quickest from my point of view.  The problem is that it appears
> >>> that only the snmpd and snmptrapd are built and installed.  I
> >>> assume that all the snmp commands come from the same source
> >>> package, so I'm hoping that you can just add those other commands
> >>> to the distro.
> >>>
> >>> Let me know what you think.
> >>>
> >>> Thanks,
> >>>
> >>> a
> >>>
> >>>
> >>
> > 
> > 
> > 
> 
