New version of check_esxi_hardware supports pywbem 0.9.x

Written by Claudio Kuenzler - 18 comments

Published on October 13th 2016 - Listed in Nagios Icinga Monitoring VMware

---

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
'0.9.0'
>>> exit()

Enjoy.

Add a comment

Show form to leave a comment

Comments (newest first)

ck from Switzerland wrote on Jul 20th, 2017:

Max, please also check the FAQ (https://www.claudiokuenzler.com/blog/308/check-esxi-hardware-faq-frequently-asked-questions) for troubleshooting. Also read the comments, they're often very helpful.
You can also try to manually comment the OMC_DiscreteSensor from the plugin to see if this helps.

---

Max from Austria wrote on Jul 19th, 2017:

Hi Claudio.

Sry was definitly a Typo. should be seconds. ms was mistake.

i see Job stucking 1min and 52s at
"Check classe OMC_DiscreteSensor"

---

Ricou from wrote on Jul 19th, 2017:

I installed the version 2.7.5 of Python but i don't find the file /usr/local/bin/python2.7, I d'ont understand.

---

Ricou from wrote on Jul 19th, 2017:

I arrive with the option --proxy. But I have this, now :
[root@]$pip --proxy http://proxy2.justice.gouv.fr:8080 install --upgrade python
DEPRECATION: Python 2.6 is no longer supported by the Python core team, please upgrade your Python. A future version of pip will drop support for Python 2.6
[root@]

I havde to upgrade python, too ?

---

ck from Switzerland wrote on Jul 19th, 2017:

Ricou, looks like your machine has no direct Internet access? If pip (python-pip) doesn't work, you can try to manually compile and install pywbem. An idea how to do this is here: https://www.claudiokuenzler.com/blog/542/installing-testing-pywbem-0.8-development-version, but that's still the old 0.8 version, meanwhile a much newer version is out of course.

---

Ricou from wrote on Jul 19th, 2017:

The command "pip install --upgrade pywbem" doesn't work :

Retrying (Retry(total=4, connect=None, read=None, redirect=None)) after connection broken by 'ProtocolError('Connection aborted.', error(101, 'Network is unreachable'))': /simple/pywbem/
[...]
Requirement already up-to-date: pywbem in /usr/lib/python2.6/site-packages

---

ck from Switzerland wrote on Jul 19th, 2017:

Ricou you should install the EPEL repository first. See https://support.rackspace.com/how-to/install-epel-and-additional-repositories-on-centos-and-red-hat/.

---

Ricou from wrote on Jul 19th, 2017:

I tried with this command : rpm -ivh https://dl.fedoraproject.org/pub/epel/6/x86_64/python-pip-7.1.0-1.el6.noarch.rpm

But it doesn't work.

---

ck from Switzerland wrote on Jul 19th, 2017:

Ricou, you can install python-pip from EPEL repositories for Centos: https://dl.fedoraproject.org/pub/epel/6/x86_64/python-pip-7.1.0-1.el6.noarch.rpm

---

Ricou from wrote on Jul 19th, 2017:

Hi,

I have CentOS 6.5. I have not the command "pip". How must I do ?

---

ck from Switzerland wrote on Jul 19th, 2017:

Hi Max. Run the plugin in verbose mode (-v) to see where it takes such a long time. But 33ms on the old machine is not possible (unless you don't get any results from CIM).

---

Max from Austria wrote on Jul 17th, 2017:

Hi there,

we got a new HW Box.

old = 3 core VM
new = 2x 12 Core Dedicated Host with LSI Raid

old centos 6.x =

pywbem = 0.10.0
python = 2.6.6
GCC = 4.4.7

new centos 7.x =

pywbem = 0.10.0
python = 2.7.5
GCC = 4.8.5

the checks on old VM takes about 33ms

on the new machine it takes more then 2M

i don't find any Reason why such long. i don't see any Perf Issues.

Any Clue?

Best regards

Max

---

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 from 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!'
sys.exit(ExitUnknown)"

---

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

VMware_EthernetPort
VMware_PCIDevice

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

http://pubs.vmware.com/vsphere-60/index.jsp#com.vmware.cimsdk.smashref.doc/class_VMware_PCIDevice.html

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

---