Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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:

enter image description here

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:

realStorageUnits bails on us

--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?

share|improve this question
    
You say installing Net-SNMPD didn't fix the issue. Do you mean that it doesn't adjust AllocationUnits as intendet or didn't you succeed in getting it to run? –  Alexander Janssen Oct 3 '12 at 15:56
    
It didn't seem to change the allocation units. The service ran fine, but in the end, it didn't seem to change what was being reported - the disk value was still incorrect, and the various values reported were still the same as before. I can confirm though, that "SNMP Service" was stopped, and "Net-SNMP Service" was started. Any chance I'm configuring something wrong? –  John K Oct 4 '12 at 18:12
    
A small additional note, I'm exposing the trees using a very basic v2c "rwcommunity <string>" setup for testing purposes. –  John K Oct 4 '12 at 18:16
    
For a start, you could query the OID .1.3.6.1.4.1.2021.100.2.0 to check if it's really Net-SNMP which is answering. On my (Linux) hosts with Net-SNMP it gives SNMPv2-SMI::enterprises.2021.100.2.0 = STRING: "5.4.1" –  Alexander Janssen Oct 4 '12 at 18:23
    
I get "UCD-SNMP-MIB::versionTag.0 = STRING: 5.5" Looks a little different, but netSNMP 5.5 is the version I have installed. Turning off Net-SNMP and turning on the Windows SNMP service, I get "UCD-SNMP-MIB::verionTag.0 = No more variables left in thie MIB View" So it looks like NetSNMP is definitely running –  John K Oct 4 '12 at 18:35
add comment

2 Answers

up vote 2 down vote accepted
+300

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.

share|improve this answer
    
Thanks Alex, we've tried that before - with much hope - unfortunately when we do, we get the following error -- C:/usr/etc/snmp/snmpd.conf: line 2: Warning: Unknown token: realStorageUnits. Is that directive just dropped anywhere i.e. right below "rwcommunity private" for example? –  John K Oct 4 '12 at 20:33
    
Haha, yeah I've made that mistake once before - I double checked, but I'll update my question with a pic. –  John K Oct 4 '12 at 20:40
    
Any chance I'm writing that directive wrong? –  John K Oct 4 '12 at 20:51
    
No, it looks good. Sorry, I'm lost now. I don't have an appropriate machine with your version of Windows to verify this, but, to be honest, your snmpd.conf looks a little "small". Try this minimal config for v2c instead. Not sure if it will help, but it will make sure that nothing other funky stuff occurs. And, adapt the network in the localnet directive. –  Alexander Janssen Oct 4 '12 at 21:16
    
5.5 on Linux with my minimal config starts happily with the realStorageUnits directive. If this still doesn't work for you I have the distinct feeling that this feature is somehow not included in the NetSNMP binary you're using. –  Alexander Janssen Oct 4 '12 at 21:27
show 6 more comments

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.

share|improve this answer
    
You could also use it to query WMI counters instead, perhaps. –  SpacemanSpiff Oct 1 '12 at 15:20
    
Not a bad idea, I'll be sure to into this. In theory the Net-SNMP libraries should do the same, but their apparent level of customization might be helpful, thanks! –  John K Oct 4 '12 at 18:13
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.