vmware-config-tools.pl Always Runs
sgrimee opened this issue · comments
the tools config exec is run at each puppet run because it fails to detect the kernel module, searching for
/lib/modules/${::kernelrelease}/misc/vmci.ko
but it is on:
Ubuntu' => "/lib/modules/${::kernelrelease}/kernel/drivers/misc/vmw_vmci/vmw_vmci.ko",
'CentOS' => "/lib/modules/${::kernelrelease}/weak-updates/vmware-tools-vmci/vmci.ko",
This change caused the opposite problem on my systems, they were working before, but now tools-config is running all the time.
I am running 12.04 LTS VMs on ESXi with vmwaretools_version = 8.6.11-1310128 and the vmci module wants to install to misc/vmci.ko (the legacy location), not kernel/drivers/misc/vmw_vmci/vmw_vmci.ko.
12.04 LTS has different point releases which have different kernel versions. 12.04 LTS came with kernel 3.2, 12.04.2 LTS came with 3.5, 12.04.3 LTS came with 3.8, and 12.04.4 LTS came with 3.11. Unless you explicitly tell apt to upgrade the kernel version per the instruction on Ubuntu's wiki, the major kernel version is not upgraded ( https://wiki.ubuntu.com/Kernel/LTSEnablementStack ). I personally only have the 3.2 and 3.5 kernel on 12.04 LTS VMs.
I decided to manually upgrade some testing VMs to 3.8 and 3.11 kernels.
For my 3.2 and 3.5 kernel VMs, the module is installing to misc/vmci.ko. These are not working correctly and tools-config is compiling and doing it's thing every time puppet runs.
For the new 3.8 kernel VMs, it's the same as 3.2 and 3.5. The module is installing into misc/vmci.ko. tools-config is kicked off every puppet run.
For the new 3.11 kernel VMs, it's installing to kernel/drivers/misc/vmw_vmci/vmw_vmci.ko. These are now working correctly with the vmwaretools module.
It appears the params.pp file needs to look at $::kernelmajversion and use the default path /lib/modules/${::kernelrelease}/misc/vmci.ko if it's 3.8 or below and /lib/modules/${::kernelrelease}/kernel/drivers/misc/vmw_vmci/vmw_vmci.ko at 3.11 or higher. I don't believe any Ubuntu releases came with kernel 3.9 or 3.10, so I guess you could use 3.8 or 3.11 as the cut-off point to decide what config_creates_real path to use.
Ubuntu 13.10 runs kernel 3.11, so it'd be understandable why @sgrimee had issues with the module location initially.
@Slashbunny - thanks a lot for the explanation!
I'll try and work on a solution over the next few days (I'm away over Easter unfortunately).
@Slashbunny I have at least 2 VMs running 12.04.3 LTS boxes on kernel 3.8.0-29-generic and there is no such vmci.ko file created even after vmware-tools-config.pl -d run.
linux-headers-3.8.0-29-generic is installed:
Error: Command exceeded timeout
Error: /Stage[main]/Vmwaretools::Config_tools/Exec[vmware_config_tools]/returns: change from notrun to 0 failed: Command exceeded timeout
# more /etc/issue
Ubuntu 12.04.3 LTS \n \l
root@worker01:~# uname -r
3.8.0-29-generic
root@worker01:~# find /lib/modules/3.8.0-29-generic -name *vmci.ko
root@worker01:~#
root@worker01:~# /usr/bin/vmware-config-tools.pl -d
Initializing...
Making sure services for VMware Tools are stopped.
vmware-tools stop/waiting
The module vmmemctl has already been installed on this system by another
installer or package and will not be modified by this installer. Use the flag
--clobber-kernel-modules=vmmemctl to override.
The VMware Host-Guest Filesystem allows for shared folders between the host OS
and the guest OS in a Fusion or Workstation virtual environment. Do you wish
to enable this feature? [no]
The vmblock enables dragging or copying files between host and guest in a
Fusion or Workstation virtual environment. Do you wish to enable this feature?
[no]
WARNING: This program cannot compile any modules for the following reason(s)...
- This program could not find a valid path to the kernel headers of the running
kernel. Please ensure that the header files for the running kernel are
installed on this sytem.
[ Press Enter key to continue ]
The fast network device driver (vmxnet module) is used only for our fast
networking interface. The rest of the software provided by VMware Tools is
designed to work independently of this feature.
If you wish to have the fast network driver enabled, you can install the driver
by running vmware-config-tools.pl again after making sure that gcc, binutils,
make and the kernel sources for your running kernel are installed on your
machine. These packages are available on your distribution's installation CD.
[ Press Enter key to continue ]
The communication service is used in addition to the standard communication
between the guest and the host. The rest of the software provided by VMware
Tools is designed to work independently of this feature.
If you wish to have the VMCI feature, you can install the driver by running
vmware-config-tools.pl again after making sure that gcc, binutils, make and the
kernel sources for your running kernel are installed on your machine. These
packages are available on your distribution's installation CD.
[ Press Enter key to continue ]
The VM communication interface socket family is used in conjunction with the VM
communication interface to provide a new communication path among guests and
host. The rest of this software provided by VMware Tools is designed to work
independently of this feature. If you wish to have the VSOCK feature you can
install the driver by running vmware-config-tools.pl again after making sure
that gcc, binutils, make and the kernel sources for your running kernel are
installed on your machine. These packages are available on your distribution's
installation CD.
[ Press the Enter key to continue.]
The module vmxnet3 has already been installed on this system by another
installer or package and will not be modified by this installer. Use the flag
--clobber-kernel-modules=vmxnet3 to override.
The module pvscsi has already been installed on this system by another
installer or package and will not be modified by this installer. Use the flag
--clobber-kernel-modules=pvscsi to override.
No X install found.
Creating a new initrd boot image for the kernel.
update-initramfs: Generating /boot/initrd.img-3.8.0-29-generic
vmware-tools start/running
The configuration of VMware Tools 8.3.18 build-975338 for Linux for this
running kernel completed successfully.
You must restart your X session before any mouse or graphics changes take
effect.
You can now run VMware Tools by invoking the following command:
"/usr/bin/vmware-toolbox" during an X server session.
To enable advanced X features (e.g., guest resolution fit, drag and drop, and
file and text copy/paste), you will need to do one (or more) of the following:
1. Manually start /usr/bin/vmware-user
2. Log out and log back into your desktop session; and,
3. Restart your X session.
Enjoy,
--the VMware team
@craigwatson
Also I'm running
# more /etc/issue
CentOS release 6.3 (Final)
Kernel \r on an \m
# uname -r
2.6.32-279.el6.x86_64
And path to vmci.ko is the default (/lib/modules/${::kernelrelease}/misc/vmci.ko) not the one specified in RedHat params.pp. Not sure what version of RedHat or kernel requires the /lib/modules/${::kernelrelease}/weak-updates/vmware-tools-vmci/vmci.ko as @sgrimee originally posted for this merge.
@cdenneen: Have you confirmed whether or not your particular version of vmware tools supports 12.04.3 (kernel 3.8)? Support was added at the end of August, so if you haven't upgraded since then, that might be why the installation is not generating the kernel module. Since config tools isn't returning an error, I'm not sure what else you can do to troubleshoot.
I noticed the 12.04.4 VMs (3.11) "appeared" to install correctly (and the module was created/installed), but ESXi was reporting vmware tools as not running. We upgraded vmware tools to the latest version distributed with ESXi 5.5, and it resolved the issue.
@cdenneen I am running:
CentOS release 6.5 (Final)
2.6.32-431.3.1.el6.x86_64
Ok do then the module path should be CentOS minor version related since it
appears to have changed from 6.3 to 6.5
On Wednesday, April 23, 2014, Sam Grimee notifications@github.com wrote:
@cdenneen https://github.com/cdenneen I am running:
CentOS release 6.5 (Final)
2.6.32-431.3.1.el6.x86_64—
Reply to this email directly or view it on GitHubhttps://github.com//issues/33#issuecomment-41133463
.
Thanks to all for your comments and investigation, much appreciated!
Basing the $config_creates variable on the ever-increasing combination of OS and kernel seems very unwieldy to me. Does anyone have any suggestions for kernel-specific files that will be the same across distros (or minimally different)?
The vmware_config_tools Exec command can use some other test or trigger - creates was only used in the module's infancy for simplicity. Is there any other way of determining that the tarball version of the Tools is installed rather than open-vm-tools or the OSPs provided by VMware?
An (admittedly hacky) workaround would be to add && echo ${::kernelrelease} > /etc/vmwaretools/kernel to the end of the config-tools Exec, then test the file in either an onlyif or unless Exec parameter.
what about just testing the presence of the module with lsmod ?
The tarball version creates /etc/vmware-tools/config and this file is not created by the open-vm-tools package.
Unfortunately, the OSPs from VMWare also create this file (at least on RHEL), but this could be checked with rpm -qf /etc/vmware-tools/config.
Maybe this is a solution? Of course, this will no longer check for the proper kernel modules :/
I think an lsmod check is going to be the most reproducible check - I have a dedi server being generously donated in the next few weeks so I'm hoping to have a testing VM up soon.
Not sure, if this is the right way, but this code in config_tools.pp seems to work for me (Ubuntu 12.04 and 14.04):
exec { 'vmware_config_tools':
command => '/usr/bin/vmware-config-tools.pl -d',
unless => '/sbin/lsmod | /bin/grep -q vmci'
}
@Tuxdiver I confirm, this seems to work for me too and sounds simple enough.
Thanks to @sgrimee and @Tuxdiver (and all others here) for your contributions, and huge apologies for the delay in getting this issue fixed, R/L has been extremely busy recently!
I've committed 12385d7 which replaces creates with the unless check.
Can everyone please update to the GitHub HEAD code and report back?
Thanks!
I can confirm that trunk fixes this issue
Thanks all for your input - I'll close this issue as fixed and release to the forge in the next few days.