Hi, I tried to get the timesync to kick off. But reading through the code I am fairly certain the "refreshonly" will only work with a subscribe or a notice.

    subscribe   => Package[$::vmwaretools::package_real],

The latest version of puppetlabs_spec_helper defaults STRICT_VARIABLES=yes. (I'm not too sure why, but perhaps this will be the default or only setting when puppet 5 is released??)

params.pp references lots of top scope variables with the design being they might have come from an ENC. With strict variables, if they're not set, catalog compilation will fail. The solution is to use getvar from stdlib. See https://blog.yo61.com/test-for-undefined-fact-in-puppet-with-strict_variables/

@razorsedge Is there also a typo here https://github.com/razorsedge/puppet-vmwaretools/blob/6.0.0/manifests/params.pp#L95 ?

I recently upgraded my stdlib module to puppetlabs-stdlib (v4.16.0) from (v4.6.0). As a consequence, vmwaretools no longer works. I reverted back to 4.6.0 and there is no error.

My guess is that Package[$package_real] seems to be the issue, since that's the only relevant Hash. Note that in the output, Puppet may be choosing not to add the Package to the catalog.

• CentOS 6
• Puppet 3.8.7
• puppetlabs-stdlib (v4.16.0)
• razorsedge-vmwaretools (v6.0.0)

Usage:

class{ "vmwaretools": ensure => 'absent' }

Error:

Debug: Executing '/bin/rpm -q vmware-tools-esx-nox --nosignature --nodigest --qf %{NAME} %|EPOCH?{%{EPOCH}}:{0}| %{VERSION} %{RELEASE} %{ARCH}\n'
Debug: /Stage[main]/Vmwaretools/Package[vmware-tools-esx-nox]: Nothing to manage: no ensure and the resource doesn't exist
Debug: Executing '/bin/rpm -q vmware-tools-esx-kmods --nosignature --nodigest --qf %{NAME} %|EPOCH?{%{EPOCH}}:{0}| %{VERSION} %{RELEASE} %{ARCH}\n'
Debug: /Stage[main]/Vmwaretools/Package[vmware-tools-esx-kmods]: Nothing to manage: no ensure and the resource doesn't exist
Error: /Stage[main]/Vmwaretools/File_line[disable-tools-version]: Could not evaluate: can't convert Hash into String
Notice: /Stage[main]/Vmwaretools/Service[vmware-tools-services]: Dependency File_line[disable-tools-version] has failures: true
Warning: /Stage[main]/Vmwaretools/Service[vmware-tools-services]: Skipping because of failed dependencies
Debug: Class[Vmwaretools]: The container Stage[main] will propagate my refresh event

I attempted to verify that ensure is set to a value for the Package[$package_real] resource by adding this to init.pp:

notify{"Package ensure is ${package_ensure}":}

And the printout confirms that the value is "absent" and not undef.

3.* and 4.* version requires restricted and main repos to found vmware-tools-nox package

I'm attempting to update our VMWare Tools OSP RPMs using autoupgrade => true but have found that I have to list all packages including dependencies like this.

Is this how you intended the autoupgrade to work?

    if ($facts['osfamily'] == 'RedHat') and ($facts['os']['release']['major'] == '5') {
      class { '::vmwaretools':
        manage_repository => false,
        autoupgrade       => true,
        tools_version     => $tools_version,
        scsi_timeout      => $scsi_timeout,
        package           => ['vmware-tools-esx-nox',
                              'vmware-tools-esx-kmods',
                              'kmod-vmware-tools-pvscsi',
                              'kmod-vmware-tools-vmci',
                              'kmod-vmware-tools-vmmemctl',
                              'kmod-vmware-tools-vmxnet',
                              'kmod-vmware-tools-vmxnet3',
                              'kmod-vmware-tools-vsock',
                              'vmware-tools-pvscsi-common',
                              'vmware-tools-vmci-common',
                              'vmware-tools-vmmemctl-common',
                              'vmware-tools-vmxnet-common',
                              'vmware-tools-vmxnet3-common',
                              'vmware-tools-vsock-common']
      }
    }

    if ($facts['osfamily'] == 'RedHat') and ($facts['os']['release']['major'] == '6') {
      class { '::vmwaretools':
        manage_repository => false,
        autoupgrade       => true,
        tools_version     => $tools_version,
        scsi_timeout      => $scsi_timeout,
        package           => ['vmware-tools-esx-nox',
                              'vmware-tools-esx-kmods',
                              'kmod-vmware-tools-vmci',
                              'kmod-vmware-tools-vmxnet',
                              'kmod-vmware-tools-vsock',
                              'vmware-tools-vmci-common',
                              'vmware-tools-vmxnet-common',
                              'vmware-tools-vsock-common']
      }
    }

Hi,

As it stands, it looks like the $vmwaretools::service_pattern selector match may not have up-to-date values. Do you know of any reference to the service name for each version of the tools?

Also, why include the vmwaretools class from inside ntp? This prevents users from declaring the vmwaretools class with the specific parameters they might want to tweak (like autoupgrade). It seems more flexible to remove that include and either make the exec subscribe to the vmwaretools class or make that activity a resource type that we can use in an idempotent fashion.

What do you think?

The logic in the init.pp causes udevadm (which doesn't exist) to be called instead of udevcontrol on OEL 5.11 because you check for "operatingsystem == 'RedHat'" instead of perhaps a better option of "osfamily == 'RedHat'".

I cant seem to get this module to play nice with hiera,

I can get it to work via the PE node classifier without any issues but with hiera code it just ignores anything I put in and puts in the default values of vmware as defined in the params

I have tried the following

vmwaretools::repopath: /my/path
vmwaretools::reposerver: http://my.server
vmwaretools::gpgkey_url: my key

and
vmwaretools::repopath: '/my/path'
vmwaretools::reposerver: 'http://my.server'
vmwaretools::gpgkey_url: 'my key'

and
vmwaretools::repopath: "/my/path"
vmwaretools::reposerver: "http://my.server"
vmwaretools::gpgkey_url: "my key"

If you include ::apt inside your module I can not initialize class {'::apt' with custom values (using role/profile pattern)

on Ubuntu 12.04.5 LTS:

err: /Stage[main]/Vmwaretools/Service[vmware-tools-services]: Could not evaluate: Could not find init script for 'vmware-tools-services'

looks like vmware-tools v5 on 12.04 is now using Upstart.

adding 'provider' => 'upstart' to the service stanza fixes it, but this needs to be implemented properly.

Not really an issue but a suggestion. I modified this to change disable-tools-version=true to false. This allows the vmware tools to report the version of the tools to vCenter.

I simply integrated this.

sed -i 's/disable-tools-version=true/disable-tools-version=false/g' /etc/vmware-tools/tools.conf

There are instances where tools.conf does not exist, I am suggesting that it checks for existence and create the file if not found.

it would be nice if vmwaretools::ntp would use a onlyif instead of refreshonly.
to quote @ffrank: "Friends Don't Let Friends Use Refreshonly"

This is the error I get.

Notice: Scope(Class[Vmwaretools::Params]): Your operating system CentOS is unsupported and will not have the VMware Tools OSP installed.

I want to downgrade from 'latest' to '5.5latest'. This does not seem to happen when I change tools_version => '5.5latest' and autoupgrade => 'false', instead the latest RPM files are still found on the system.

Is it supposed to be possible to downgrade tools version?

reason for downgrading is that we seem to be hitting a bug with latest tools that causes VM's to crash when quiescing filesystem for backup.

http://packages.vmware.com/tools/esx/latest/ does not exist. It is referenced several times in the repo spec file.

manifests/repo.pp constructs the following (invalid) url on SLES11.3:

http://packages.vmware.com/tools/esx/latest/sles11.3/x86_64/
It uses $::operatingsystemrelease in the string which is "11.3" on this version.

The correct URL would be:
https://packages.vmware.com/tools/esx/latest/sles11sp3/x86_64/
(note "11sp3" instead of "11.3")

If I get this working properly I may make a PR

The requirements for this project are getting stale, and require updating.

At the very least update the supported puppet versions. Also update the stdlib version requirement.

Hi

From what I can tell, (for RHEL6) the module is using
https://packages.vmware.com/tools/esx/latest/rhel6/x86_64/index.html

It appears these packages haven't been updated since August?
Have vmware done some reorganising?
Perhaps
https://packages.vmware.com/tools/releases/latest/rhel6/x86_64/index.html is the correct url these days?

Not sure.

When running on RHEL6 and esx5.0
...
err: /Stage[main]/Vmwaretools/Service[vmware-tools-services]/ensure: change from stopped to running failed: Could not start Service[vmware-tools-services]: Execution of '/sbin/start vmware-tools-services' returned 1: at /etc/puppetlabs/puppet/modules/vmwaretools/manifests/init.pp:287
...
It is trying to use /sbin/start instead of /sbin/service /vmware-tools-services start

The problem is in the regex, it is using one or more instead of zero or more, the fix is to change + to *:

  $rhel_upstart = $tools_version ? {
    /3\..+/   => false,
    /4\..+/   => false,
   ### /(5.0).+/ => false,
    /(5.0).*/ => false,
    default   => true,
  }

Is it possible to add rhel7/centos7 support?

Hi

Is there a clean way to get rid of those warning ?

[root@ppbgows01 ~]# puppet apply --environment preproduction /etc/puppetlabs/code/environments/preproduction/manifests/
Warning: Unknown variable: '::vmwaretools_reposerver'. at /etc/puppetlabs/code/environments/preproduction/modules/vmwaretools/manifests/params.pp:21:17
Warning: Unknown variable: '::vmwaretools_repopath'. at /etc/puppetlabs/code/environments/preproduction/modules/vmwaretools/manifests/params.pp:26:15
Warning: Unknown variable: '::vmwaretools_repopriority'. at /etc/puppetlabs/code/environments/preproduction/modules/vmwaretools/manifests/params.pp:31:19
Warning: Unknown variable: '::vmwaretools_repoprotect'. at /etc/puppetlabs/code/environments/preproduction/modules/vmwaretools/manifests/params.pp:36:18
Warning: Unknown variable: '::vmwaretools_gpgkey_url'. at /etc/puppetlabs/code/environments/preproduction/modules/vmwaretools/manifests/params.pp:41:17
Warning: Unknown variable: '::vmwaretools_proxy'. at /etc/puppetlabs/code/environments/preproduction/modules/vmwaretools/manifests/params.pp:46:12
Warning: Unknown variable: '::vmwaretools_proxy_username'. at /etc/puppetlabs/code/environments/preproduction/modules/vmwaretools/manifests/params.pp:51:21
Warning: Unknown variable: '::vmwaretools_proxy_password'. at /etc/puppetlabs/code/environments/preproduction/modules/vmwaretools/manifests/params.pp:56:21
Warning: Unknown variable: '::vmwaretools_tools_version'. at /etc/puppetlabs/code/environments/preproduction/modules/vmwaretools/manifests/params.pp:61:20
Warning: Unknown variable: '::vmwaretools_ensure'. at /etc/puppetlabs/code/environments/preproduction/modules/vmwaretools/manifests/params.pp:68:13
Warning: Unknown variable: '::vmwaretools_package'. at /etc/puppetlabs/code/environments/preproduction/modules/vmwaretools/manifests/params.pp:73:14

Regards,

When running the module I'm getting an error
Retrieving key from https://packages.vmware.com/tools/keys/VMWARE-PACKAGING-GPG-DSA-KEY.pub

GPG key retrieval failed: [Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 404 Not Found"

Checking the repository, the GPG-DSA-KEY is no longer offered in the /keys directory.

An option to set the gpgcheck=0 would be helpful as well.

I just installed and used this module for the first time. However, it fails immediately after Puppet modifies /etc/yum.repos.d/vmware-tools.repo for the first time.

We're using Puppet OSS 3.8 on Scientific Linux release 6.6 (A clone of RHEL/CentOS 6).

My class calls this module with a very basic include:

include ::vmwaretools

However, in the end, this module creates a blank file for the VMware Tools repository, and thus every command afterwards fails:

[root@dev1 ~]# ll /etc/yum.repos.d/vmware*
-rw-r--r-- 1 root root 317 Aug  3 10:51 /etc/yum.repos.d/vmware.repo
-rw-r--r-- 1 root root   0 Aug  3 10:51 /etc/yum.repos.d/vmware-tools.repo
[root@dev1 ~]# 

The command fails immediately after Notice: /Stage[main]/Vmwaretools::Repo/Yumrepo[vmware-tools]/protect: defined 'protect' as '0'.

Here's a log showing the command execution:

[root@dev1 ~]# puppet agent --test
Info: Retrieving pluginfacts
Info: Retrieving plugin
Notice: /File[/var/lib/puppet/lib/facter/vmware.rb]/ensure: defined content as '{md5}fdf0c987ebc1d390d4e2da3d914469a3'
Notice: /File[/var/lib/puppet/lib/puppet/type/zypprepo.rb]/ensure: defined content as '{md5}81f249c4403b0bc1228896da6041eabc'
Info: Loading facts
Info: Loading facts
Info: Caching catalog for dev1.example.org
Info: Applying configuration version '1470246658'
admin'
Notice: /Stage[main]/Vmwaretools::Repo/Yumrepo[vmware-tools]/descr: descr changed 'VMware Tools for Red Hat Enterprise Linux $releasever - $basearch' to 'VMw
are Tools latest - rhel6 x86_64'
Notice: /Stage[main]/Vmwaretools::Repo/Yumrepo[vmware-tools]/baseurl: baseurl changed 'http://packages.vmware.com/tools/esx/latest/rhel6/$basearch' to 'http:
//packages.vmware.com/tools/esx/latest/rhel6/x86_64/'
Notice: /Stage[main]/Vmwaretools::Repo/Yumrepo[vmware-tools]/gpgkey: gpgkey changed 'http://packages.vmware.com/tools/keys/VMWARE-PACKAGING-GPG-RSA-KEY.pub'
to 'http://packages.vmware.com/tools/keys/VMWARE-PACKAGING-GPG-DSA-KEY.pub
    http://packages.vmware.com/tools/keys/VMWARE-PACKAGING-GPG-RSA-KEY.pub'
Notice: /Stage[main]/Vmwaretools::Repo/Yumrepo[vmware-tools]/protect: defined 'protect' as '0'
Notice: /Stage[main]/Vmwaretools::Repo/Yumrepo[vmware-tools]/priority: defined 'priority' as '50'
Notice: /Stage[main]/Vmwaretools::Repo/File[/etc/yum.repos.d/vmware-tools.repo]/ensure: created

Error: Execution of '/usr/bin/yum -d 0 -e 0 -y install vmware-tools-esx-kmods' returned 1: Error Downloading Packages:
  vmware-tools-esx-kmods-9.0.17-1.el6.x86_64: failure: vmware-tools-esx-kmods-9.0.17-1.el6.x86_64.rpm from vmware-tools: [Errno 256] No more mirrors to try.
  vmware-tools-vmxnet-common-9.0.17-5.el6.x86_64: failure: vmware-tools-vmxnet-common-9.0.17-5.el6.x86_64.rpm from vmware-tools: [Errno 256] No more mirrors to try.
  kmod-vmware-tools-vmxnet-2.0.14.0-2.6.32.71.el6.x86_64.5.el6.x86_64: failure: kmod-vmware-tools-vmxnet-2.0.14.0-2.6.32.71.el6.x86_64.5.el6.x86_64.rpm from vmware-tools: [Errno 256] No more mirrors to try.
  vmware-tools-vmci-common-9.0.17-5.el6.x86_64: failure: vmware-tools-vmci-common-9.0.17-5.el6.x86_64.rpm from vmware-tools: [Errno 256] No more mirrors to try.
  kmod-vmware-tools-vsock-9.3.4.0-2.6.32.71.el6.x86_64.5.el6.x86_64: failure: kmod-vmware-tools-vsock-9.3.4.0-2.6.32.71.el6.x86_64.5.el6.x86_64.rpm from vmware-tools: [Errno 256] No more mirrors to try.
  vmware-tools-vsock-common-9.0.17-5.el6.x86_64: failure: vmware-tools-vsock-common-9.0.17-5.el6.x86_64.rpm from vmware-tools: [Errno 256] No more mirrors to try.
  kmod-vmware-tools-vmci-9.3.20.0-2.6.32.71.el6.x86_64.5.el6.x86_64: failure: kmod-vmware-tools-vmci-9.3.20.0-2.6.32.71.el6.x86_64.5.el6.x86_64.rpm from vmware-tools: [Errno 256] No more mirrors to try.
Error: /Stage[main]/Vmwaretools/Package[vmware-tools-esx-kmods]/ensure: change from absent to present failed: Execution of '/usr/bin/yum -d 0 -e 0 -y install vmware-tools-esx-kmods' returned 1: Error Downloading Packages:
  vmware-tools-esx-kmods-9.0.17-1.el6.x86_64: failure: vmware-tools-esx-kmods-9.0.17-1.el6.x86_64.rpm from vmware-tools: [Errno 256] No more mirrors to try.
  vmware-tools-vmxnet-common-9.0.17-5.el6.x86_64: failure: vmware-tools-vmxnet-common-9.0.17-5.el6.x86_64.rpm from vmware-tools: [Errno 256] No more mirrors to try.
  kmod-vmware-tools-vmxnet-2.0.14.0-2.6.32.71.el6.x86_64.5.el6.x86_64: failure: kmod-vmware-tools-vmxnet-2.0.14.0-2.6.32.71.el6.x86_64.5.el6.x86_64.rpm from vmware-tools: [Errno 256] No more mirrors to try.
  vmware-tools-vmci-common-9.0.17-5.el6.x86_64: failure: vmware-tools-vmci-common-9.0.17-5.el6.x86_64.rpm from vmware-tools: [Errno 256] No more mirrors to try.
  kmod-vmware-tools-vsock-9.3.4.0-2.6.32.71.el6.x86_64.5.el6.x86_64: failure: kmod-vmware-tools-vsock-9.3.4.0-2.6.32.71.el6.x86_64.5.el6.x86_64.rpm from vmware-tools: [Errno 256] No more mirrors to try.
  vmware-tools-vsock-common-9.0.17-5.el6.x86_64: failure: vmware-tools-vsock-common-9.0.17-5.el6.x86_64.rpm from vmware-tools: [Errno 256] No more mirrors to try.
  kmod-vmware-tools-vmci-9.3.20.0-2.6.32.71.el6.x86_64.5.el6.x86_64: failure: kmod-vmware-tools-vmci-9.3.20.0-2.6.32.71.el6.x86_64.5.el6.x86_64.rpm from vmware-tools: [Errno 256] No more mirrors to try.
Notice: /Stage[main]/Vmwaretools/File_line[disable-tools-version]: Dependency Package[vmware-tools-esx-kmods] has failures: true
Warning: /Stage[main]/Vmwaretools/File_line[disable-tools-version]: Skipping because of failed dependencies
Notice: /Stage[main]/Vmwaretools/Service[vmware-tools-services]: Dependency Package[vmware-tools-esx-kmods] has failures: true
Warning: /Stage[main]/Vmwaretools/Service[vmware-tools-services]: Skipping because of failed dependencies
Notice: /Stage[main]/Vmwaretools/File[/etc/udev/rules.d/99-vmware-scsi-udev.rules]: Dependency Package[vmware-tools-esx-kmods] has failures: true
Warning: /Stage[main]/Vmwaretools/File[/etc/udev/rules.d/99-vmware-scsi-udev.rules]: Skipping because of failed dependencies
Notice: /Stage[main]/Vmwaretools/Exec[udevrefresh]: Dependency Package[vmware-tools-esx-kmods] has failures: true
Warning: /Stage[main]/Vmwaretools/Exec[udevrefresh]: Skipping because of failed dependencies
Notice: Finished catalog run in 69.06 seconds
[root@dev1 ~]#

With tools_version set to "5.5p02", the regex on line https://github.com/razorsedge/puppet-vmwaretools/blob/master/manifests/init.pp#L192 that is intended to match tools version 5.0 will match "5p0" and incorrectly set rhel_upstart to false. This could be fixed by either escaping the period in 5.0 (so it matches the period character) or by prefixing the regex with the ^ character such that the match can only happen at the beginning of the string. Lost a few hairs to this one before I realized what was happening!

This should be set to ensure time sync is enabled when vmwaretools::ntp isn't enabled. Currently it does not.

I receive this error every time I run "puppet agent --test" and the open-vm-tools service is running already.

Error: Could not start Service[open-vm-tools]: Execution of '/etc/init.d/open-vm-tools start' returned 1: * Starting open-vm daemon vmtoolsd
Error: /Stage[main]/Openvmtools/Service[open-vm-tools]/ensure: change from stopped to running failed: Could not start Service[open-vm-tools]: Execution of '/etc/init.d/open-vm-tools start' returned 1: * Starting open-vm daemon vmtoolsd

Err http://packages.vmware.com precise/main amd64 Packages
Undetermined Error
Err http://packages.vmware.com precise/main i386 Packages
Undetermined Error
Ign http://packages.vmware.com precise/main Translation-en_US
Ign http://packages.vmware.com precise/main Translation-en
Fetched 5,116 kB in 18min 3s (4,724 B/s)
W: Failed to fetch http://packages.vmware.com/tools/esx/5.5latest/ubuntu/dists/precise/main/binary-amd64/Packages Undetermined Error

W: Failed to fetch http://packages.vmware.com/tools/esx/5.5latest/ubuntu/dists/precise/main/binary-i386/Packages Undetermined Error

Hi there,

I would like to extend the code for some SLES specific stuff, as we use a lot of SLES server VMs.

As on SLES there is "zypper" as the default and only supported tool, I would like to extend the code to use the zypprepo type created by Darin (https://forge.puppetlabs.com/darin/zypprepo), which was not included into core puppet but published as a module (see Feature #11864 http://projects.puppetlabs.com/issues/11864).
Of course this adds a dependency to this module, but it would be really nice to have a real zypper repo.

Kind regards, Poikilotherm

The update for 9th of september removed /etc/init.d/vmware-tools-services which makes the module fail the service test.

They seem to have moved the init script to /etc/vmware-tools/init/vmware-tools-services for reasons way beyond me.

On my CentOS 5 system (Puppet Learning VM), using the following declaration:

class { 'vmwaretools':
autoupgrade => true,
}
include vmwaretools::ntp

The following repository is generated:

[vmware-tools]
name=VMware Tools 5.0latest - rhel5 i686
baseurl=http://packages.vmware.com/tools/esx/5.0latest/rhel5/i686/
enabled=1
gpgcheck=1
gpgkey=http://packages.vmware.com/tools/keys/VMWARE-PACKAGING-GPG-DSA-KEY.pub
http://packages.vmware.com/tools/keys/VMWARE-PACKAGING-GPG-RSA-KEY.pub
protect=0
priority=50

The problem is, VMWare has killed the links for rhel5 & rhel6 in the *latest tree, suggesting the use of direct releases until they've fixed an upgrade issue. See http://packages.vmware.com/tools/esx/5.0latest/rhel5 for example.

I guess the question is, should one wait it out or should the module change to use absolute releases instead of *latest?

Running RHEL 6.7 on ESXi 6.0, using this module in version 5.0.1 throws the following error:

change from stopped to running failed: Could not start Service[vmware-tools-services]: Execution of '/sbin/start vmware-tools-services' returned 1: at /etc/puppet/environments/production/modules/vmwaretools/manifests/init.pp:324

The VM is deployed and managed by Foreman 1.8.4

Every time I run puppet agent --test I get a meesage Service[vmware-tools]/ensure: ensure changed 'stopped' to 'running'. It appears that at least on SL 6.2 the vmware--guestd deamon is not run. I solved this locally by changing the service pattern to "vmtoolsd".

Do you have plans to add support for RHEL/Centos 7?

I might be interested in providing a PR in the near future if you'd be willing to accept such an addition

Current release of apt is 4.1.0 and dependency is locked to < 3.0.0
Please update to 5.0.0

The vmware-uninstall-tools.pl script (at least in the version we were running) leaves behind the directory /usr/lib/vmware-tools. This causes the rpm install of vmware-tools to fail. This directory needs to be removed before attempting to install the vmware-tools package. For our installation, I modified the vmware-unistall-tools exec command as follows to resolve the issue:

command => '/usr/bin/vmware-uninstall-tools.pl ; /bin/rm -rf /usr/lib/vmware-tools',

This is the error message returned by puppet:

Error unpacking rpm package vmware-open-vm-tools-common-8.3.12-559003.el5.x86_64
error: unpacking of archive failed on file /usr/lib/vmware-tools/lib64: cpio: rename failed - Is a directory
at /etc/puppet/modules/vmwaretools/manifests/init.pp:89

vmwaretools v4.4.1 fails to start the vmware tools service on RHEL6 if "manage_repository" is false because it does not compute "majdistrelease"

naive patch below:

--- modules/vmwaretools/manifests/init.pp
+++ modules/vmwaretools/manifests/init.pp
@@ -220,23 +220,23 @@
       $yum_basearch = $tools_version ? {
         /3\..+/ => $vmwaretools::params::yum_basearch_4x,
         /4\..+/ => $vmwaretools::params::yum_basearch_4x,
         default => $vmwaretools::params::yum_basearch_5x,
       }
+
+      $majdistrelease = $::lsbmajdistrelease ? {
+            ''      => regsubst($::operatingsystemrelease,'^(\d+)\.(\d+)','\1'),
+            default => $::lsbmajdistrelease,
+      }

       if $manage_repository {
         # We use $::operatingsystem and not $::osfamily because certain things
         # (like Fedora) need to be excluded.
         case $::operatingsystem {
           'RedHat', 'CentOS', 'Scientific', 'SLC', 'Ascendos', 'PSBM',
           'OracleLinux', 'OVS', 'OEL', 'SLES', 'SLED', 'OpenSuSE',
           'SuSE': {
-            $majdistrelease = $::lsbmajdistrelease ? {
-              ''      => regsubst($::operatingsystemrelease,'^(\d+)\.(\d+)','\1'),
-              default => $::lsbmajdistrelease,
-            }
-
             if ( $yum_path == $vmwaretools::params::yum_path ) or ( $just_prepend_yum_path == true ) {
               $gpgkey_url  = "${yum_server}${yum_path}/keys/"
               $baseurl_url = "${yum_server}${yum_path}/esx/${tools_version}/${vmwaretools::params::baseurl_string}${majdistrelease}/${yum_basearch}/"
             } else {
               $gpgkey_url  = "${yum_server}${yum_path}/"

Currently VMware haven't released a repo for RHEL 7 - http://packages.vmware.com/tools/esx/latest/index.html

This module either needs to take no action on RHEL 7, or it needs to set up the RHEL 6 repo and hope for the best.

Currently it sets up a repo with the URL set for RHEL 7 and breaks the yum configuration on the box.

[root@centos7 ~]# yum update
Loaded plugins: fastestmirror, langpacks
http://packages.vmware.com/tools/esx/latest/rhel7/x86_64/repodata/repomd.xml: [Errno 14] HTTP Error 404 - Not Found

If the packages are already synchronized by a satellite server to a custom channel, the module should not manage the yum repo.