Header RSS Feed
If you only want to see the articles of a certain category, please click on the desired category below:
ALL Android Backup BSD Database Hacks Hardware Internet Linux Mail MySQL Monitoring Network Personal PHP Proxy Shell Solaris Unix Virtualization VMware Windows Wyse

New version of check_esxi_hardware supports pywbem 0.9.x
Thursday - Oct 13th 2016 - by - (6 comments)

If someone would have told me two years ago, that we'll have pywbem version 0.9.0 soon, I'd have laughed. Two years ago, pywbem was in some kind of coma. It existed and was supported from all major distributions (even with their own packages), yet upstream was dead. For security fixes, the distributions put together some patched versions; resulting in pywbem being differently depending on the distribution. But still running with the same old version 0.7.0.

But then came Andy Maier and revived the project in September 2014. Succeeding several months of beta versions, the final version of 0.8.1 was released in March 2016. Back then the monitoring plugin check_esxi_hardware was adapted to support both the old and everlasting 0.7.0 but also the newer 0.8.0. Unfortunately this was done in a hard coded way:

elif '0.8.' in pywbemversion:

See the problem? Yep. Version 0.9.0 was released last month, in September 2016. Of course the plugin didn't know how to handle the newer version. And version 0.10.0 is also around the corner, so that wouldn't have worked either.

So today's update of check_esxi_hardware.py (version 20161013) removes that hard-coded way - except for the old 0.7.0 version which was abused - sorry - overpatched by the distributions. Call it legacy code because that's what it is.

By the way if you're interested in installing pywbem 0.9.0 (that's the latest release as of this wrigin), you can install it with pip.
On a Debian or Ubuntu system you first need to install the following requirements:

apt-get install python-pip swig libpcre3 libpcre3-dev libssl-dev g++ python-dev

Then run:

pip install --upgrade pywbem

This should install the latest available pywbem version from pypi.

Make sure at the end you get an output like this:

  Running setup.py install for typing
Successfully installed pywbem PyYAML six ply M2Crypto typing
Cleaning up...

And this is how you can verify which pywbem version is being used by your python installation:

$ python
Python 2.7.6 (default, Jun 22 2015, 17:58:13)
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pywbem
>>> import pkg_resources
>>> pkg_resources.get_distribution("pywbem").version
>>> exit()



Add a comment

Show form to leave a comment

Comments (newest first):

ck from Switzerland wrote on Mar 21st, 2017:
Max, please show the verbose output and also give some additional information like Linux Distribution/Version? Pywbem version? ESXi version? CIM Offline Bundles installed?
According to the FAQ the problem could be in the installed OMSA package if your ESXi runs on a DELL hardware.

Max wrote on Mar 20th, 2017:
i'am getting recently an Error for my Checks: UNKNOWN: Execution time too long

If i search inside the Script for this Error i find Section:

Not quit sure what i need to Change to get this Error away.it's running on Linux

"on_windows = True
os_platform = sys.platform
if os_platform != "win32":
on_windows = False
import signal
def handler(signum, frame):
print 'UNKNOWN: Execution time too long!'

ck from Switzerland wrote on Mar 10th, 2017:
max, you should verify if these elements are really correctly shown in the Hardware Status tab in your vsphere client or via the vsphere web UI. These CIM classes may also depend on certain hardware.

max wrote on Mar 9th, 2017:
ah thx ;) that was the Reason. worked on wrong place ha.

i would have another question here. i don't find the Reason behind. i wanted to add some more checks to the sript


to see also Healthstate for Network Cards,...

the EthernetPort give me only back "Element Name"
and once trying PCIDevice it's giving me Element Name and Element Healthstate back.

But Healthstate is 0 for all Devices. not sure why - because everything is online and should be "5".

i checked with


any Hints? ;)

ck from Switzerland wrote on Mar 9th, 2017:
Hello Max. Verify that you have increased the Nagios timeout itself which can be configured in nagios.conf if I remember correctly. Test it also on the command line if the timeout happens, too.

Max wrote on Mar 8th, 2017:
Getting everytime Error from Nagios after a while

Service check timed out after 60.01 seconds

i added already -t 500 and changed inside the script from 0 to 500. but getting that error after 60s

Go to Homepage home
Linux Howtos how to's
Monitoring Plugins monitoring plugins
Links links

Valid HTML 4.01 Transitional
Valid CSS!
[Valid RSS]

7512 Days
until Death of Computers