Linux - Software Lifecycle - Install open-vm-tools (VMWare-Tools)

What the open-vm-tools deployment Worklet does

This Automox Worklet™ deploys the open-vm-tools package to Linux endpoints running as guests on a VMware hypervisor. The Worklet inspects each endpoint, detects whether yum, apt-get, or zypper is the active package manager (checked in that order), and queries that manager for an existing open-vm-tools installation. If the package is already present, the Worklet exits clean. If the package is missing, remediation installs it from the distribution's standard repository.

Open-vm-tools is the open-source replacement for the legacy VMware Tools tarball. VMware recommends it for all supported Linux guests because the distribution maintainers ship updates through the same channel as the rest of the OS. The Worklet uses that same channel: yum install -y open-vm-tools on RHEL, CentOS, Rocky, Alma, and Fedora (where yum routes to dnf on RHEL 8+), apt-get install -y open-vm-tools on Debian and Ubuntu, and zypper install -y open-vm-tools on openSUSE and SLES.

After the package lands, the Worklet relies on systemd to start vmtoolsd and on the systemctl enable open-vm-tools step that the package's post-install script registers. The next boot brings the service up automatically, and the VMware hypervisor immediately reports the guest as having complete tools installed.

Why deploy open-vm-tools on Linux VMs

Linux VMs without open-vm-tools are missing the integration features VMware administrators rely on. The hypervisor cannot synchronize time against the host clock. vMotion is blocked or degraded. Guest customization fails during cloning, and the quiesced snapshot path does not flush filesystem buffers. Shared clipboard and folder features between host and guest are unavailable. The vCenter inventory then flags the guest as 'tools not running,' which affects operational dashboards and several compliance reports.

Apply this Worklet to the Linux VMware guest endpoint group on the Automox console; the package-manager detector routes RHEL and Fedora through yum, Ubuntu and Debian through apt-get, and SUSE through zypper, so a single policy lands open-vm-tools across every supported guest. The next vMotion window, snapshot job, or DR drill no longer stalls on guests that were missed during provisioning.

How open-vm-tools deployment works

1. Evaluation phase: The Worklet runs a get_package_manager function that uses command -v to probe for yum, apt-get, and zypper in that priority order. It then queries the selected manager for the open-vm-tools package – yum list installed grepped for open-vm-tools on Red Hat family, apt list --installed grepped for open-vm-tools on Debian and Ubuntu, and zypper search -i open-vm-tools on openSUSE and SLES. If the package is installed, the Worklet exits 0 (compliant). If the package is absent, the endpoint is flagged non-compliant and remediation is scheduled.

2. Remediation phase: Remediation calls the same package-manager detection helper, short-circuits to exit 0 if the package is already installed (yum list installed, dpkg-query -W, or zypper se -i depending on the manager), then runs yum install -y open-vm-tools, apt-get install -y open-vm-tools, or zypper install -y open-vm-tools depending on the platform. The package's post-install scriptlet runs systemctl enable open-vm-tools so the vmtoolsd service starts on every subsequent boot. The Worklet exits 0 when the package install command returns success and non-zero with a status message on stdout when the install fails or the package manager cannot be identified.

open-vm-tools deployment requirements

• Linux endpoint running on VMware vSphere, vCloud, ESXi, Workstation, or Fusion – bare-metal hosts and non-VMware hypervisors should be excluded from the policy

• Supported package manager available on the endpoint: yum (RHEL, CentOS, Rocky, Alma, Fedora – yum is a dnf wrapper on RHEL 8 and later), apt-get (Debian, Ubuntu), or zypper (openSUSE, SLES). Endpoints with only dnf and no yum compatibility symlink are not detected by the current script.

• Root or sudo privileges for the Automox agent (the default agent context already meets this)

• Network reachability from the endpoint to the distribution's package repository (apt sources, yum/dnf repos, or zypper repos)

• systemd present on the endpoint so the package's post-install scriptlet can register vmtoolsd as an enabled service

• FixNow compatible: the Worklet can run on demand against a single endpoint or device group from the Automox console without waiting for the next scheduled policy window

Expected state after open-vm-tools deployment

After remediation, the open-vm-tools package is installed and queryable through the local package manager. dpkg -s open-vm-tools returns Status: install ok installed on Debian and Ubuntu; rpm -q open-vm-tools returns the versioned package name on RHEL, Rocky, Alma, Fedora, openSUSE, and SLES. The vmtoolsd binary lives at /usr/bin/vmtoolsd and reports its version through vmtoolsd --version.

systemctl status open-vm-tools shows the unit as active (running) and enabled, with the loaded unit file at /usr/lib/systemd/system/open-vm-tools.service or /lib/systemd/system/open-vm-tools.service depending on the distribution. The vmware-toolbox-cmd utility reports the running state to the hypervisor (vmware-toolbox-cmd timesync status, vmware-toolbox-cmd stat balloon). vCenter flips the guest's tools status from 'Not running' or 'Not installed' to 'Running (Current).' Subsequent Automox policy evaluations report the endpoint as compliant without applying remediation again.

Validate end-to-end by initiating a low-impact vMotion of the guest to another host in the cluster. The migration should complete without warnings about missing tools. For audit evidence, capture the output of vmtoolsd --version, systemctl status open-vm-tools, and the package-manager query alongside the Automox policy run identifier. The package remains in place across kernel upgrades and reboots; it is only removed if an administrator runs an explicit purge or remove, at which point the next Worklet evaluation flags the endpoint and remediation restores the package on the following run.