The open-vm-tools package (specifically the open-vm-tools.service) is a suite of utilities installed in Ubuntu guests to improve performance and manageability when running on VMware hypervisors (like ESXi, vSphere, or VMware Workstation). It facilitates clock synchronization, graceful shutdowns, and heartbeat reporting to the hypervisor. However, if you are migrating an Ubuntu Server image from a VMware environment to a different hypervisor (like Proxmox/KVM, Hyper-V, or AWS EC2), leaving open-vm-tools running causes unnecessary background polling, clutters syslog with connection errors, and wastes system resources as the daemon desperately searches for a VMware backend that no longer exists.
This guide explains how to completely disable the open-vm-tools daemon in Ubuntu Server.
Stop and Disable the VMware Tools Daemon
To ensure the server stops attempting to communicate with a non-existent hypervisor, we must halt the daemon and explicitly mask it via systemd.
- Log into your Ubuntu Server via SSH or local console using an account with
sudoprivileges. - First, stop the active service to terminate its polling loop immediately:
sudo systemctl stop open-vm-tools.service - Next, disable the service so it does not initialize during the next system boot:
sudo systemctl disable open-vm-tools.service - To guarantee that no other dependent service or cloud-init script can accidentally wake the daemon, mask the service unit entirely:
sudo systemctl mask open-vm-tools.service
Verify the Deactivation
By masking the service, you have effectively severed the VMware integration tools from the operating system without needing to invoke apt-get remove, which is useful if you maintain a golden image that bounces between different cloud providers.
To verify the lockdown is successful, run the following command to check the status of the unit:
systemctl status open-vm-tools.serviceThe output will clearly state that the service is masked (symlinked to /dev/null) and the Active state will read inactive (dead). Your Ubuntu Server will no longer generate unnecessary VMCI (Virtual Machine Communication Interface) polling errors, leaving your logs clean and your CPU cycles dedicated to your actual workloads.