16TB Volumes and SNMP On Windows

Question

As volumes larger than 16TB became more common, it was recognized that the 32 bit value used to report disk size and usage within the standard "HOST-RESOURCES" MIB in SNMP was not large enough to report the proper disk size.

Net-SNMP seems to have addressed this issue by simply manipulating the value of "AllocationUnits" to maintain a 32 bit value for disk utilization (since total disk size/usage is equal to the 32 bit space value times the allocation unit), to allow for the calculation of a volume larger than 8/16TB. Presuming you don't have any reporting interest in the allocation unit, and are ok with a small level of inaccuracy. this seems like an elegant solution.

https://bugzilla.redhat.com/show_bug.cgi?id=654384

Window's built in SNMP service, however, seems to continue to suffer from this error, simply reporting the modulo of the used/assigned disk space, resulting in inaccurate disk size reporting.

Is there a way to enable Windows to correctly report disk usage for volumes over 16TB? We attempted to simply install Net-SNMP 5.5 x64 and disable Windows SNMP service entirely, however this unfortunately did not fix our issue.

When using the NetSNMP extensions, the information we collect for the particular disk we're interested in is as follows:

These results are the same regardless of whether we're using the vanilla Windows SNMP service, or NetSNMP.

I've seen people in the Cacti community mention simply scripting out a solution. Unfortunately, we're using Observium for quick and basic systems monitoring. If the issue can't be corrected on the Window's side, can Observium be made to report custom MIBs?

--Update--

Looking into the bug report's mention of adding "realStorageUnits" to the snmpd.conf file, we experienced the following problem when setting that directive:

--Update 2--

Well, after much tinkering, it doesn't look like any of the Windows versions of Net-SNMP like the "realStorageUnits" directive. Including the directive results in a warning when starting SNMP. We tried on version 5.5, 5.6, and 5.7. Has anyone has here ever figured out how to get SNMP to report out 16+ TB volumes on Windows?

Answer 1

A while ago there was a patch for Net-SNMP 5.5 which introduced a new option realStorageUnits for the configuration file.

From the Redhat Bugreport #748410:

To address this issue [negative hrStorageSite values], this update adds a new option to the /etc/snmp/snmpd.conf configuration file, realStorageUnits. By changing the value of this option to 0, users can now enable recalculating all values in hrStorageTable to ensure that the multiplication of hrStorageSize and hrStorageAllocationUnits always produces an accurate device size.

(text in [brackets] is mine)

So adding the configuration directive realStorageUnits 0 to your snmpd.conf might be solving your problem.

However, the values will not be correct up to the very last megabyte; ymmv.

I can't tell if this patch was included in your binary distribution of Net-SNMP, but it would be great if you could report the results and what binary you are using. Also, I didn't test it for the lack of adequate hardware right now.

Answer 2

I know this is not a direct answer to your question, but perhaps it will help. I suggest you try contacting the team that makes SNMP Informant: http://www.snmp-informant.com/

They extend the Windows SNMP agent to work around Microsoft's limitations for some of their OIDs. I use it with Zenoss to get more accurate CPU utilization and storage numbers and there is a good chance this will work around your issue, but I can't say for certain.