check_esx3/check_vmware_api error "SOAP request error - possibly a protocol issue"

There's a problem in the Perl module Net::HTTP versions 6.05 and 6.06 (at least up to the date of writing this post) that drops this error when running check_esx/check_vmware_api, no matter which version of  VMWare API is being used.

The solution is based on downgrading Net::HTTP to its version 6.03. In order to check the installed module version (and thus determining that the problem matches the previously described), run this command from a shell session:

cpan -D Net::NTTP

... and in order to downgrade it, run this command:

cpan install GAAS/Net-HTTP-6.03.tar.gz

Once done, you could find that, though the error message has changed, you continue getting an error when running the check_esx3/check_vmware_api. That's due because Net::HTTP and libwww-perl Perl modules doesn't match after downgrading the first one, so you have to downgrade libwww-perl too in order to solve the problem. To do it run this command from a shell session:

cpan install GAAS/libwww-perl-6.03.tar.gz

Tweet

check_esx3/check_vmware_api error 'Cannot complete login due to an incorrect user name or password' when upgrading to ESXi5

If you've upgraded your VMWare infrastructure to ESXi5 and you're getting the error 'Cannot complete login due to an incorrect user name or password' when running OP5's check_esx3 or check_vmware_api plugins, bet that you're using a Windows domain username without setting the domain itself.

Up to ESXi5 you could use a domain username in order to login to VCenter/ESX servers without the need of specifying the domain. Starting at ESXi5 you need to set the user domain in two of these ways:

• user@domain
• domain\user

So there's a chance that you, as I, were using the OP5 check_esx3.pl / check_vmware_api.pl Nagios plugin in order to get info from your virtualization infrastructure and that the plugin based checks stopped working after upgrading to ESXi5. In order to solve the problem apply the previous rule when setting the -u (--user) argument. 

Have in mind that, since the backslash (\) is a shell special character, you must quote the username value ('domain\user') or escape the backslash (domain\\user) in order to work when using the syntax domain\user.

Tweet

OP5's check_esx3 timeouts when querying VSphere servers

I've been using the fantastic OP5's check_esx3 (now known as check_vmware_api) Nagios Core compatible plugin for years in different systems with success. In one of my last installs I got an strange problem: Plugin froze for minutes, even timed-out, when requesting info from any server (VCenter or ESX).

Debugging the code I saw that it happened when the VSphere API performed an HTTP POST to the  server SOAP webservice querying the properties of an object. Since prior to that operation VSphere API had successfully opened an SSL conection to the server I discarded a problem in the Perl LWP libraries, those that manage the SSL data flow from the monitoring system to the VSphere servers.

The monitoring system was using VSphere SDK for Perl 5.1 and Perl LWP 6.05 module, both the last available releases at the time of writing this post. 

After many tests I solved the problem downgrading Perl LWP from 6.05 to the 5.837 release. I'm not very sure why it happened and I've not tested it with different Perl LWP 6.x releases in order to find a more recent running version. The fact is that now it works like a charm.

Tweet

Monitoring VMWare: Installing vSphere SDK for Perl

Considering the huge growth that virtualization platforms are experiencing in these last years, specially but not only VMWare based ones, monitoring these platforms and supported hosts becomes a must be for every monitoring administrator.

You can find a bunch of good plugins addressed to monitor VMWare platforms on Nagios compatible tools (Nagios itself, Icinga, Babel or Zenoss, among others), perhaps being the most adopted the versatile check_esx from OP5. Anyway, the key point is that the most of them are based on VMWare's vSphere SDK for Perl, a set of libraries acting as API, as interface, between plugins and VCenters/ESX(i) servers.

vSphere SDK is all but light in terms of disk space requirements... ok, maybe I was a bit extreme: It requires more than 80Mbytes of space in your Gigabyte drive, the most of this space being used by:

• vCli: a shell client for managing vSphere based platforms.
• WSMAN libraries for getting server hardware information by vSphere.

Well, the truth is that I don't want neither managing vSphere platforms nor getting hardware information by vSphere (I prefer getting it directly from the servers), so these components lack of interest for someone who only wants monitoring VCenter, ESX(i) and virtualized servers. The only thing I need is the Perl modules, a set of files located on lib/VMware/share/VMware installation package directory... and requiring 3Mbytes of disk space:

• VICommon.pm
• VICredStore.pm
• VIExt.pm
• VILib.pm
• VIM2Runtime.pm
• VIM2Stub.pm
• VIM25Runtime.pm
• VIM25Stub.pm
• VIMRuntime.pm
• VIRuntime.pm

So to start playing the only thing you must do it copying VMware libraries full directory to one of the locations where your distro stores Perl libraries (one of them is /usr/local/share/perl/ in Debian) and checking if all dependent libraries are properly installed, specifically:

• Crypt-SSLeay-0.55 (0.55-0.9.7 or 0.55-0.9.8)
• IO-Compress-Base-2.005
• Compress-Zlib-2.005
• IO-Compress-Zlib-2.005
• Compress-Raw-Zlib-2.017
• Archive-Zip-1.26
• Data-Dumper-2.121
• XML-LibXML-1.63
• libwww-perl-5.805
• LWP-Protocol-https-6.02
• XML-LibXML-Common-0.13
• XML-NamespaceSupport-1.09
• XML-SAX-0.16
• Data-Dump-1.15
• URI-1.37
• UUID-0.02
• SOAP-Lite-0.710.08
• HTML-Parser-3.60
• version-0.78

I imagine that it must exist a right procedure for checking if these libraries are present in the system, but I recommend the "trial and error" approach as the fastest: Just download one of the most plugins the uses the API (as check_esx does), run it from the command line and install each non satisfied dependency the script dropped as runtime error.

Dealing with Debian platforms, you can find problems when trying to install XML::LibXML from CPAN (perl -MCPAN -e "install XML::LibXML"), specifically you can get  a MAKEFILE.pl error message talking about the impossibility of finding some libraries:

...
looking for -lxml2... no
looking for -llibxml2... no
libxml2 not found
...

The best way to solve it is installing the libxml-libxml-perl Debian package (apt-get install libxml-libxml-perl) instead of doing it by CPAN.

Tweet