Check that vm-open-tools are installed

[msterin]

Summary:
need to check that either vm-open-tools or vmware-tools (or just vmci kernel module) are installed

Details:
The code works only if the Linux VM (running Docker) is running under ESX and vm-open-tools or vmware-tools are installed. If they are not, some mystery bugs will be reported.
Plugin GO code needs to check that the vm-open-tools or vmware-tools are installed, and that it is indeed ESX VM (we can see it in BIOS). This will simplify troubleshooting and accelerated solving customer install issues.

As an alternative, we can write a "check-prerequisites" script thst does all that and (eventually) more.

[msterin]

I believe can be a big issues if we silently do not work if cm-open-tools is not installed. We absolutely should do a simple check and at least print an error message IMO.

[kerneltime]

One option is to add the dependency to rpm and deb to check for vm tools being installed.

[msterin]

that would be very good. However there are "Vmware tools" (no rpm package) and open-vm-tools. Can you put dependency on presence of a kernel module (lsmod | grep vmw_vmci) ?

[msterin]

NOTE: this obviously includes test and doc if needed, so closing #268 as dup

[pdhamdhere]

Document for TP and add code level dependency for Beta.

[kerneltime]

There are complications for checking VMCI.

• It can be installed in more than one ways. (open vm tools, VMware tools, built into the kernel)
• It is not always loaded as loadable modules. (Photon)
• Installed does not imply running vmci communication (I have a box where vsock is loaded but does not work since tools are not installed in it's entirety)
  At a minimum when we discover communication failures we should log the possible reasons.

Thus, adding pre installation checks are both complex and not sufficient. Run time checks equate to calling the VMCI code and getting a failure. Thus, logging has been enhanced to help outline the possible reasons.

[kerneltime]

#452 will address the logging requirements.