We're adding support for a new object that will be represented in a
table. Right now the priority is to get the trap support working, and IF
we have time in the schedule we'll also add support for the MIB table.
Here's an abbreviated layout of the new table:
vmTable OBJECT IDENTIFIER ::= { pvt3SysVM 1 }
vmEntry OBJECT IDENTIFIER ::= { pvt3VMTable 1 }
vmIndex OBJECT IDENTIFIER ::= { pvt3VMEntry 1 }
vmName OBJECT IDENTIFIER ::= { pvt3VMEntry 2 }
vmState OBJECT IDENTIFIER ::= { pvt3VMEntry 3 }
...
The trap will be something like "vmStateFailed" and needs to include the
vmName as a variable. But when I get the information for the actual
event to trigger the trap, I won't be getting the index into the table,
I'll only be getting the vmName piece. Do I have to include the index
value in the OID for the vmName object in the trap (which would mean I'd
have to do a secondary lookup to match the vmName to the corresponding
index), or can I just set it to the "base" part of the vmName OID?
Would it be better to define a MIB item for vmName solely for the use of
the trap, or is that considered "bad form"?
Thanks for any input!
Wendy
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Net-snmp-users mailing list
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
