# open-vm-tools: the guest agent that makes a VM manageable

> The C codebase behind power operations, time sync, shared folders and guest customization in VMware products, how its plugin set fits together, and why the licence is split three ways.

**vmware/open-vm-tools** — Official repository of VMware open-vm-tools project

- Repository: https://github.com/vmware/open-vm-tools
- Website: http://sourceforge.net/projects/open-vm-tools/
- Stars: 2,683 · Forks: 473
- Language: C
- License: NOASSERTION
- Published: 2026-10-07 · Updated: 2026-10-07 · Language: en
- Canonical page: https://hysenlabs.com/projects/vmware-open-vm-tools

## What actually runs inside the guest

open-vm-tools is described as a set of services and modules that enable several features in VMware products for better management of, and user interaction with, guests. The wording matters, because the project is not a desktop application and not a virtualization stack. It is the guest half of the conversation a hypervisor has with the operating system running inside it.

The feature list in the README is the clearest statement of scope. Graceful power operations, meaning reboot and shutdown handled from inside the guest so applications can be given a chance to close. Execution of built-in or user configured scripts during those power operations. Running programs, commands and file system operations in the guest for automation. Authentication for guest operations, without which none of the rest would be safe to expose. Generation of a heartbeat from guest to host so a vSphere HA solution can determine availability. Clock synchronization between guest and host. Quiescing guest file systems so the host can capture a file-system-consistent snapshot, including pre-freeze and post-thaw scripts. Guest customization immediately after power on. Periodic collection of network, disk and memory usage. Resizing the graphical desktop screen. Shared folders between host and guest file systems on Workstation and Fusion. Copying and pasting text, graphics and files. Dragging and dropping files. Periodic collection of running applications, services and containers. Accessing content from GuestStore. Publishing data to Guest Data Publisher. And managing a Salt-Minion desired state specified in a guest variable.

The top-level layout is correspondingly small. The tree at the repository root holds a LICENSE file, README.md, ReleaseNotes.md and a single open-vm-tools directory that contains the code:

```text
LICENSE
README.md
ReleaseNotes.md
open-vm-tools/
```

Everything downstream of that directory is what produces the feature list above.

## The plugin list is the architecture

The README enumerates the released components, and reading that list as an architecture is more useful than reading it as a feature matrix. The PowerOps plugin performs graceful power operations and runs power scripts. The VIX plugin runs programs and commands and performs file system operations in the guest. GuestInfo periodically collects various statistics. TimeSync handles time synchronization. dndcp supports drag and drop along with text and file copy and paste. ResolutionSet adjusts guest screen resolutions automatically based on window sizes. vmbackup supports the quiesced snapshot operation. GuestStore supports GuestStore operations. The gdp plugin supports guest data publishing. AppInfo collects application information, ServiceDiscovery collects service information and ContainerInfo collects container information, each on a periodic basis. ComponentMgr handles desired state operations.

Around the plugins sit the guest authentication service, the toolbox command for disk wiping and shrinking, power script management and time synchronization, and the guest SDK libraries that provide information about a virtual machine to the guest.

What the shape tells you is that the guest side is a message bus with attachable units, and the hypervisor decides which ones to talk to. A host that does not care about GuestStore never asks for it, and a guest that lacks the plugin simply does not answer that channel. It also explains why the projects are packaged the way they are: capability follows package boundaries, so the pieces that need X libraries can be split away from the ones that do not. Solaris and FreeBSD drivers for various devices and file system access are included in the release, and multiple monitor support and shared folders client and server code are there too.

## A licence split that explains the packaging

The licence question here has more than one answer, and picking any single one is a mistake. GitHub reports the repository licence as NOASSERTION, which is the machine-readable field for exactly this situation: there is no single file that describes every component. The README states that the code is released under GPL v2 and GPL v2 compatible licences, and then breaks that down. The Linux kernel modules are released under GPL v2. Almost all of the user level components are released under LGPL v2.1. The SVGA and mouse drivers have been available under the X11 licence for quite some time. And certain third party components are released under BSD style licences, to which VMware has in some cases contributed, and which will continue to be distributed with open-vm-tools.

The README also explains the reasoning, which is the part worth carrying into your own review. GPL v2 was chosen for the kernel components to be consistent with the Linux kernel's licence. LGPL v2.1 was chosen for the user level components because some of the code is implemented as shared libraries and the authors did not want to restrict proprietary code from linking against those libraries. For consistency, the rest of the user level code was put under LGPL v2.1 as well.

So there are two facts in tension here: the repository's own metadata cannot classify the licence, and the README defines it precisely at component level. Both are accurate at their own altitude. The actionable move is to classify per component rather than per repository. If you are shipping a Linux guest image, the kernel modules travel with the kernel and the user space packages ship as ordinary LGPL shared libraries, so a standard distro compliance process covers them. If you are redistributing something that vendors an SVGA or mouse driver, look at that directory's own header instead of the repository's licence field.

## Where the Linux drivers actually live

One of the README's most practically useful notes is what is missing. Linux drivers have been upstreamed to the Linux community and are not provided in the open-vm-tools release. Kernel versions 3.10 and later include all of the Linux drivers present in open-vm-tools except the vmhgfs driver. The vmhgfs driver was required for enabling the shared folders feature, but it is superseded by vmhgfs-fuse, which does not require a kernel driver.

This reframes the shared folders story. A reader arriving expecting a kernel module to find instead a FUSE based implementation that lives in user space and arrives through normal distribution packages, which is why the driver question comes up less than it once did.

The packaging note that follows in the README explains the names you will meet. Most Linux distributions ship two or more open-vm-tools packages. The open-vm-tools package is the core package without any dependencies on X libraries, and open-vm-tools-desktop is an additional package that depends on the core package and on X libraries. The open-vm-tools-sdmp package contains a plugin for Service Discovery, which is the ServiceDiscovery component named in the architecture. There may be additional packages, and the README sends you to the documentation of the OS vendor for the full set.

There is a related boundary worth noting on the VMware side. VMware Tools will continue to be available under a commercial licence, the README recommends open-vm-tools for the Linux distributions where it is available, and VMware will not provide OSPs for operating systems where open-vm-tools is available. In practice that means a Linux guest on open-vm-tools is the supported configuration, and the commercial Tools product is aimed at the guest operating systems that open-vm-tools does not cover.

## Reading the release line for what kind of project this is

Three recent tags are enough to characterise the cadence. stable-13.1.0, published 2026-05-14, is a feature release and the one with a visible platform decision in it: it supports building with either the GNOME Toolkit version 4 or continuing to use version 3, and the configure script accepts options to restrict the build to either GTK3 or GTK4. If no restriction is applied, the latest version for which the required development packages are installed is used. That release also closes GitHub issues 707 and 763.

stable-13.0.10, published 2026-01-27, says plainly that there are no new features and that it is primarily a maintenance release addressing a fix. The one behaviour change named is in the DeployPkg plugin for guest OS customization, updated to handle a new cloud-init error code that signals a recoverable error so cloud-init can finish running. There is a parallel change in 13.0.5 where DeployPkg was updated to use systemctl reboot if available.

stable-13.0.5, published 2025-09-30, is the security entry. It resolves CVE-2025-41244, refers readers to advisory VMSA-2025-0015 for the impact on Broadcom products, and notes that a patch for earlier open-vm-tools releases is provided to the Linux community as CVE-2025-41244.patch in the repository. It too is described as primarily a maintenance release addressing a security issue.

Put together, the pattern is a stable branch receiving targeted maintenance with occasional platform work, and every release body points at the same two places for detail: ReleaseNotes.md on the tag's branch and a ChangeLog inside open-vm-tools for the granular list.

## Where to install it from, and what to check first

The README is direct about the install decision. Packages for the user space components are available with new versions of major Linux distributions and are installed as part of the OS installation in several cases, and all leading Linux vendors support open-vm-tools and bundle it with their products. Automatic installation along with the OS installation removes the need for a separate step in the guest. If it is not installed automatically, the README says you may be able to install it manually from the guest OS vendor's public repository, and it gives the reason in operational terms: installing from the Linux vendor's repository reduces virtual machine downtime because future updates are included with the OS maintenance patches and updates.

That downtime argument is the practical one. A separate open-vm-tools installation inside a guest means the hypervisor has to reconcile a tool update against a running operating system, and many environments treat that as a maintenance window. Taking the package from the distro avoids the problem entirely.

Two checks are worth doing before you trust a guest. The first is OS compatibility, which the README sends to the VMware Compatibility Guide, and the second is package identity, since the names open-vm-tools, open-vm-tools-desktop and open-vm-tools-sdmp carry different capabilities and you want to know which one is present in a given image. For a fleet, the ComponentMgr desired state handling and the DeployPkg customization path are the two components most worth confirming per distribution, since both sit on the post-power-on path that provisioning depends on. The repository itself carries 2,673 stars, 472 forks and 315 open issues, with the last push on 2026-05-14.

## Conclusion

open-vm-tools is infrastructure rather than an application. The value is that a set of small plugins covers the unglamorous operations a hypervisor cannot perform alone, from a graceful reboot to a heartbeat a cluster can trust. Two things deserve a reader's attention before installing anything. First, the licence is genuinely mixed, kernel code under GPL v2 and user space under LGPL v2.1, so a compliance review has to be per component rather than per repository. Second, the Linux drivers you may expect to find here are not in this release, since they now live in the kernel and the vmhgfs driver has been superseded by a FUSE implementation. The release line reflects that maintenance posture: two of the three recent tags are maintenance releases, and one is a security fix for CVE-2025-41244. Install from your distribution's repository so the package rides along with ordinary OS updates, and read the compatibility guide before assuming a guest combination is supported.

## FAQ

### Is open-vm-tools the same as VMware tools?

Not exactly. VMware Tools will continue to be available under a commercial licence, while open-vm-tools is the open source agent for the guest operating systems it covers. The README recommends open-vm-tools for Linux distributions where it is available, and says VMware will not provide OSPs for operating systems where open-vm-tools is available.

### What is the latest version of open-vm-tools?

The most recent tag is stable-13.1.0, published on 2026-05-14. That release is based on build 25218885 and adds the ability to build against either GNOME Toolkit version 4 or version 3, with configure options to restrict the build to one of them.

### Why does the repository report no licence at all?

Because the code is not under a single licence. The README states that Linux kernel modules are under GPL v2, almost all user level components are under LGPL v2.1, the SVGA and mouse drivers have been under the X11 licence for some time, and some third party components use BSD style licences. Classify per component rather than per repository.

### Do I still need a kernel driver for VMware shared folders?

No. The README says the vmhgfs driver was required for the shared folders feature but is superseded by vmhgfs-fuse, which does not require a kernel driver. Linux kernel versions 3.10 and later include all the other Linux drivers that were once shipped here, since they have been upstreamed.

## Sources

- [Issues](https://github.com/vmware/open-vm-tools/issues)
- [Project website](http://sourceforge.net/projects/open-vm-tools/)
- [README](https://github.com/vmware/open-vm-tools/blob/master/README.md)
- [Releases](https://github.com/vmware/open-vm-tools/releases)
- [vmware/open-vm-tools on GitHub](https://github.com/vmware/open-vm-tools)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/vmware-open-vm-tools