VMware tools are installed, but it is not managed by VMWare. (Critical)

[morgajel]

"VMware recommends using open-vm-tools redistributed by operating system vendors."

Seeing as how VMware now recommends this, perhaps it should no longer be critical? :)

[BaldMansMojo]

Hi Jesse, you're right (partly). That was one reason why I have changed the status for tools which are newer than the ones on the server to ok (former warning I think). But I think I will changed some other stati too. But not to ok. Should be warning. And in cases this won't fit your environment you can use --ignore_warning. that will result in a green status.

Best regards Martin

[morgajel]

I understand why you'd be hesitant to allow it, but keep in mind that vcenter-managed tools are deprecated for linux and no longer supported, meaning anyone with linux hosts will have the check be in continuous warning (or force you to ignore warnings). VMware itself is saying this is an acceptable state.

All of our linux hosts are causing the check to fail, including the vcenter server appliance itself. The blacklist was getting large enough to be unmanageable, so I've modified the local .pm files to set the $actual_state to 0.

I'm not trying to be difficult or argumentative, I just want to make sure I'm explaining it adequately.

[BaldMansMojo]

Just for understanding - which part makes the trouble? I think it can only be "VMware Tools is installed, but it is not managed by VMWare". Right? I yes I can add a switch like --tool-not-managed. You are right - VMware recommends the rpm based tools for Linux. But what is with M$Windows? Or running "unspported" Linux systems like Debian or Ubuntu? Or something else running on virtual Intel based hardware? Below is a block based on information for Esx 5.x:

VirtualMachineToolsRunningStatus

guestToolsExecutingScripts VMware Tools is starting. guestToolsNotRunning VMware Tools is not running. guestToolsRunning VMware Tools is running.

VirtualMachineToolsVersionStatus

guestToolsBlacklisted VMware Tools is installed, but the installed version is known to have a grave bug and should be immediately upgraded. Since vSphere API 5.0 guestToolsCurrent VMware Tools is installed, and the version is current. guestToolsNeedUpgrade VMware Tools is installed, but the version is not current. guestToolsNotInstalled VMware Tools has never been installed. guestToolsSupportedNew VMware Tools is installed, supported, and newer than the version available on the host. Since vSphere API 5.0 guestToolsSupportedOld VMware Tools is installed, supported, but a newer version is available. Since vSphere API 5.0 guestToolsTooNew VMware Tools is installed, and the version is known to be too new to work correctly with this virtual machine. Since vSphere API 5.0 guestToolsTooOld VMware Tools is installed, but the version is too old. Since vSphere API 5.0 guestToolsUnmanaged VMware Tools is installed, but it is not managed by VMWare.

What do you think? Which one should give which returncode under all possible circumstances? And which one should be given another behaviour for rpm based tools?

And - please - tell me which checks failed. Instead of giving in the single check mentioned above a 1 (warning) I can also give an unknown and you can set to green by using --ignore_unknown.

Regards Martin

[BaldMansMojo]

Stupid me. The question I had was answered by the title of this issue. I looked at the wrong part of the code. I have to see how to fix it. Set it to ok will not work (Windows systems etc.). Just checked the availbility for non rpm distros (http://pkgs.org/download/open-vm-tools). Looks good. So I will implement an additional switch to the plugin this evening. Unfortunately it is not possible to check directly via the SDK. The switch will be named --open-vm-tools.

Regards - Martin

[morgajel]

Outstanding.

It would be nice if vmware used a different status code for open-vm-tools; that'd make our lives a lot easier. For example, they could change it to "VMware Tools is installed, but it is managed by the Guest OS." As is, they have a return message that may be OK or may be the sign of a problem. In either case, you're making the best of an ugly situation. Thank you, Martin.

[BaldMansMojo]

Hi Jesse,

0.9.25 is online. Should fix your problem. Look at the readme if you have a mixed landscape (Windows and Linux).

Best regards Martin

[morgajel]

Whoops!

Bareword found where operator expected at /opt/check_vmware_esx/check_vmware_esx.pl line 1380, near "3 Jun"
        (Missing operator before Jun?)
Number found where operator expected at /opt/check_vmware_esx/check_vmware_esx.pl line 1380, near "Jun 2015"
        (Do you need to predeclare Jun?)
Bareword found where operator expected at /opt/check_vmware_esx/check_vmware_esx.pl line 1380, near "2015 M"
        (Missing operator before M?)                                                                                                                                                                                             
    syntax error at /opt/check_vmware_esx/check_vmware_esx.pl line 1380, near "our                                                                                                                                                   
-"                                                                                                                                                                                                                               
Global symbol "$openvmtools" requires explicit package name at /opt/check_vmware_esx/check_vmware_esx.pl line 1448.                                                                                                              
Execution of /opt/check_vmware_esx/check_vmware_esx.pl aborted due to compilation errors.   

I think there may be a problem with that checkin :)

[BaldMansMojo]

Copied unfotunately some comments on the variable declaration for $openvmtools. It's fixed now. Thanks for the hint.