DFM 5.2 doesn't see volume

[billshaffer]

I'm running DFM 5.2 on RHEL 5.11.  I noticed that, in the GUI, one of the volumes was not updating stats.  I tried doing a dfm host discover.  I did a dfm volume list -a, and saw the volume listed, along with what looked to be an  old version of the volume on another (non-existent) host, which was deleted.  Thinking the identical names was an issue, I deleted the volume (dfm volume delete), removed both volumes from the deleted list (dfm volume delete -f), and ran dfm host discover again.

The controller is an N-Series N6240 running 8.1.2P3.

The volume still doesn't show up in dfm volume list -a.  Does anyone have any insight?

Thanks

Bill

[JGPSHNTAP]

That's interesting.. do dfm detail on the object id

[billshaffer]

...but the volume doesn't show as an object, how do I get the object ID?

Bill

[argiri]

Need few clarifiation

Is it a CDOT OCUM installation?

what is the monsnmpTimeout configured on OCUM server?

OCUM discovers the volumes using SNMp (snmpbulkwalk) by querying the table volTable.

Enable this tetspoint TESTPOINT(0, fsmon, "snmp-stats") , share the DFMDC logs

Does the externam snmpbulkwalk on volTable show the volume?

[billshaffer]

Thanks for the response.

This is 7-mode - apologies for not stating that.

monsnmpTimeout is 60.

I tried snmpbulkwalk -c public -v 2c <host> volTable, but got

volTable: Unknown Object Identifier (Sub-id not found: (top) -> volTable)

If I try snmpbulkwalk -c public -v 2c <host> system, I get a response that looks reasonably accurate.

I'm not very vluent with snmp - not sure if the above is what you meant by "Does the externam snmpbulkwalk on volTable show the volume?", and I'm not sure what you mean by enabling a testpoint?

The last few lines of dfmcmd.log show my refreshing the host system, then nothing else:

Jul 27 10:54:42 [dfm: INFO]: [7696:0x2b475d2b0100]: Refreshing data from host <host> (3801) now.
Jul 27 13:34:16 [dfm: INFO]: [7730:0x2b22a96c5100]: Refreshing data from host <host> (3801) now.
Jul 29 08:31:34 [dfmconfig: INFO]: [2583:0x2b12e4843100]: No configurations were found.

I think another admin was doing some work on snmp with the controllers; I think this problem may predate that, but for now DFM is reporting that snmp is down.  I will followup there.

Bill

[billshaffer]

So, that was the problem.  The snmp community had gotten renamed, and DFM wasn't happy.  Thanks for getting me going in the right direction!

Bill

[argiri]

Bill,

Tablename should be replaced with its corresponding OID.

Syntax to run snmp query:

snmpbulkwalk -c public -v 2c <host> .1.3.6.1.4.1.789.1.5.8.X

where .1.3.6.1.4.1.789.1.5.8.X is the OID for volTable

Hope this helps.

Thanks

Giridhar