Module of the Week: razorsedge/vmwaretools part 2 – Manage VMware Virtualization Tools

Purpose Helps you automate the management of VMware Tools.
Module rasorsedge/vmwaretools (v4.1.1 tested)
Puppet Version Tested on 2.7+ (Puppet Enterprise 2.0+)
Platforms RHEL, CentOS, SUSE, OEL (post written with CentOS)

Last time, on Module of the Week...

In a previous MOTW, I covered what problem this module solves and addressed a very simple workflow for using the module to manage VMware Tools. This time, I'm going to dive into how the module is structured and explore some of the more advanced things you can do with it. Again, for the purpose of this blog post, I'm going to use razorsedge/vmwaretools to establish the vmware-tools service on the Learning Puppet VM.

Installing the module

Complexity Easy
Installation Time 2 minutes

To install this module, use the Puppet Module Tool (available in Puppet ≥2.7.14 or Puppet Enterprise ≥2.5.).

[root@learn ~]# puppet module install razorsedge-vmwaretools
Preparing to install into /etc/puppetlabs/puppet/modules ...
Downloading from http://forge.puppetlabs.com ...
Installing -- do not interrupt ...
/etc/puppetlabs/puppet/modules
└─┬ razorsedge-vmwaretools (v4.1.1)
  └── puppetlabs-stdlib (v3.0.1)

Exploring the module

    The razorsedge-vmwaretools module contains three classes:

  • vmwaretools
  • vmwaretools::ntp
  • vmwaretools::params
Let's start with vmwaretools::params.

class vmwaretools::params { The bulk of this class simply declares the particulars of the package names and service names used on particular operating systems. The goal here is to set $package_name & $service_name for use by the vmwaretools class that we'll look at shortly. For example, here's a snippet from the code:
case $::osfamily {
    'RedHat': {
      case $::operatingsystem {
        'Fedora': {
          fail("Unsupported platform: ${::operatingsystem}")
          $package_name = 'open-vm-tools'
          $service_name = 'vmware-tools'
        }
        default: {
          $package_name = 'vmware-tools-nox'
          $service_name = 'vmware-tools'
        }
      }
      $yum_basearch = $::architecture ? {
        'i386'  => 'i686',
        default => $::architecture,
      }
      $baseurl_string = 'rhel'  # must be lower case
    }
    default: {
      fail("Unsupported platform: ${::operatingsystem}")
    }
  }
The author has broken down the logic for setting the aforementioned variables into two case statements that break the osfamily fact into individual operatingsystem fact matches inside each osfamily. This gives the author and outside contributors a clear pattern for extending the modules platform support. Want to add support for Ubuntu? Add some elements to the case statements, declare the $package_name & $service_name variables and give it a test! With that in mind, let's take a look at the vmwaretools class.

class vmwaretools { The vmwaretools class is a parameterized class that inherits vmwaretools::params. This means that it offers you several parameters for changing its behaviour and leverages the OS abstractions established in the vmwaretools::params class covered above. By default, the vmwaretools class does the following.
  • Detects if the agent is a VMware based virtual machine & if so,
  • Configures a YUM repository for the VMware OSPs.
  • Installs the VMware Tools package from that repo.
  • Configures and ensures the vmware-tools service is running.
Here's a list of the class parameters straight from the authors documentation.
# [*tools_version*]
#   The version of VMware Tools to install.
#   Default: 4.1latest
#
# [*ensure*]
#   Ensure if present or absent.
#   Default: present
#
# [*autoupgrade*]
#   Upgrade package automatically, if there is a newer version.
#   Default: false
#
# [*package*]
#   Name of the package.
#   Only set this if your platform is not supported or you know what you are
#   doing.
#   Default: auto-set, platform specific
#
# [*service_ensure*]
#   Ensure if service is running or stopped.
#   Default: running
#
# [*service_name*]
#   Name of VMware Tools service
#   Only set this if your platform is not supported or you know what you are
#   doing.
#   Default: auto-set, platform specific
#
# [*service_enable*]
#   Start service at boot.
#   Default: true
#
# [*service_hasstatus*]
#   Service has status command.
#   Default: true
#
# [*service_hasrestart*]
#   Service has restart command.
#   Default: true
As you can tell from the authors documentation, the class's interface is designed to let you control how the VMware Tools package is maintained and how the service should be managed. On my Learning Puppet VM, let's take a look at a few example node definitions in /etc/puppetlabs/puppet/manifests/site.pp At the bottom of the file, I create a node definition for learn.localdomain which is the certificate name for this pre-installed Puppet Enterprise agent. This first example simply includes the vmwaretools class, using default parameters.
node 'learn.localdomain' {

  include vmwaretools

}
If I want the service to be fully managed by Puppet and I want the tools be automatically updated, I'd declare the following.
node 'learn.localdomain' {

  class { 'vmwaretools':
    autoupgrade => true,
    # accepting defaults for service & package status
  }

}
It's important to note that currently, the author configures a yum repository to retrieve the tools package from VMware. This is a great solution but it limits the modules functionality to systems where yum is installed. If you're interested in the exact Puppet DSL logic used to achieve the parameters listed above, take a look at the manifest source code on GitHub.

class vmwaretools::ntp { This class isn't what you might think. It's not intended to manage NTP for you, it's designed to keep VMware tools from getting in the way of NTP. The vmwaretools::ntp class is a simple class that disables VMware Tools periodic time synchronization via the tools.syncTime setting. If that's what you want, you need to declare the vmwaretools::ntp class along with your existing vmwaretools declaration. This is intended for use with your own ntp class or another module from the Forge. For this to work properly, you'll need to use a relationship metaparameter to trigger a refresh inside the vmwaretools::ntp class. The following example uses notify.
node 'learn.localdomain' {

  class { 'vmwaretools':
    autoupgrade => true,
    # accepting defaults for service & package status
  }
  include vmwaretools::ntp

  class { 'my_ntp':
    notify => Class['vmwaretools::ntp'],
  }

}

Conclusion

There you go! It's nothing fancy but it's a useful module for managing your RedHat derivatives (and SUSE!) VMWare tools. Enjoy! Learn More:
Puppet sites use proprietary and third-party cookies. By using our sites, you agree to our cookie policy.