vmware_exporter: vCenter metrics for Prometheus, waiting for a new maintainer

The notice at the top of the README comes first

Before anything else, the repository states its own status in the first line of the README. The project needs a new home. Since Broadcom is no longer catering to its opensource and free base, the author has decided to move on from maintaining the project, and asks people to create a discussion if they would like to take over managing it.

That single paragraph changes how you should read everything else. The code is not broken because it was abandoned halfway, it is a working implementation whose maintainer has lost the incentive to keep it current, and the reason is structural rather than personal. Broadcom acquired VMware, the free tier of vSphere went away, and the population of people running vCenter without a commercial contract largely went with it.

The maintenance facts line up with that story. The repository is not archived and the last push was on 2026-04-13, so somebody has still touched the tree, but the last tagged release is v0.18.4 from 2022-10-11, preceded by v0.18.3 from 2022-03-25 and v0.18.2 from 2021-09-26. Nearly four years between the newest tag and the present date, with commits landing in between, is the signature of a project receiving the occasional fix without a release process.

The licence is BSD-3-Clause, so the code is yours to fork, and the README asks for a maintainer rather than a successor. For a team deciding whether to use this, that distinction is the whole evaluation.

The audience is narrow and clear: infrastructure engineers who run vCenter, who already run Prometheus, and who want virtualisation state in the same dashboard as everything else.

What it collects, and what it deliberately does not

The metric list in the README is short and specific. It gets VMware vCenter information covering basic VM and host metrics, the current number of active snapshots, datastore size and other information, and the snapshot Unix timestamp creation date.

That last one is the interesting choice. A count of snapshots is cheap, and a creation timestamp for a snapshot is the kind of thing an operator wants as a metric because it lets you alert on snapshot age. It also gives a hint about the shape of the exporter, which appears to lean on the vCenter query and stats APIs rather than walking the inventory and counting objects, because a stats-oriented collection naturally yields a timestamp and a set of numeric values per object.

Whether that is right depends on the estate. A small environment with a few hundred virtual machines will be served well. A large one is where the collection cost becomes visible, and that is why the configuration has a specs_size parameter, described as the size of the specs list for the query stats function, defaulting to 5000.

The dependencies tell you the rest. pyvmomi at 6.5 or newer is the VMware Python SDK, prometheus-client at 0.0.19 is the metrics library, twisted is the async framework underneath, pyyaml at 5.1 or newer parses the config, and service-identity is there for TLS certificate handling on the vCenter connection. pytz handles the timezone conversion that the snapshot timestamps need.

That is an old dependency set, and the pinned prometheus-client version in particular dates from before the current 0.x client releases, so the metrics output format is whatever that version produced.

The exporter has a section per vCenter, and a URL that selects it

The configuration is a YAML file with named sections, and each section is an independent vCenter connection with its own collection settings. The example configuration in the README shows three of them, a default, an esx and a limited.

The default section connects to a host called vcenter as the user user with the password password, ignores SSL set to False, sets specs_size to 5000, and enables fetch_custom_attributes, fetch_tags and fetch_alarms, with a collect_only block listing vms, vmguests, datastores, hosts and snapshots all set to True.

The esx and limited sections differ in the collection flags, and that is the mechanism for scoping. The collect_only block decides which subsystems the exporter connects to at all, and the README is explicit that you can update the subsystem under collect_only in the config section, for example under default, or by using the environment variables. The stated effect of turning off vms and leaving the rest is that it would only connect datastores and hosts.

Selecting which section to use is a URL operation. Switching sections can be done by adding ?section=limited to the URL.

That design is a good fit for an estate with a management vCenter and a set of standalone ESXi hosts, which is a common shape in smaller environments and in labs. The alternative, running several exporter processes with different configs, is what the section mechanism is there to avoid.

The trade is that the URL parameter is the selector, and there is no description of any authentication in front of the metrics endpoint in the visible documentation. See the security section of this review for what that means.

Running it in a container, and the credential handling that comes with it

The container is the preferred route, and the README says so. The docker run line passes the credentials as environment variables and publishes port 9272:

docker run -it --rm  -p 9272:9272 -e VSPHERE_USER=${VSPHERE_USERNAME} -e VSPHERE_PASSWORD=${VSPHERE_PASSWORD} -e VSPHERE_HOST=${VSPHERE_HOST} -e VSPHERE_IGNORE_SSL=True -e VSPHERE_SPECS_SIZE=2000 --name vmware_exporter pryorda/vmware_exporter

The podman variant with an env file is documented separately, along with a warning that matters more than it looks. When using containers combined with the --env-file flag, please use capital letters to set booleans, for example VSPHERE_IGNORE_SSL=TRUE rather than True.

That is a real footgun, because the environment variable table lists VSPHERE_IGNORE_SSL with a default of False and the docker command above sets it to True, while the compose file in the repository also uses the string True. A boolean parser that does not treat the two spellings the same will quietly behave differently between the two invocation styles, and the failure mode is a TLS verification that is on when you expected it off or the reverse.

The Dockerfile is a small multi-stage build on python:3.7-alpine, which is another dated choice, and it installs gcc, python3-dev, musl-dev, libffi-dev, openssl and openssl-dev, plus rust and cargo, before pip installing the requirements and removing the build dependencies again. It exposes 9272 and sets the entrypoint to the vmware_exporter console script.

The requirement set is Python 3.6 or higher, and the non-container route is pip install vmware_exporter or python setup.py install, then run the exporter with the -c flag pointing at your config, then browse to the metrics endpoint.

The metrics endpoint has no documented authentication

This is the part of the design that deserves the closest reading, and it is a consequence of the configuration model rather than an oversight in the code.

The exporter takes a vCenter username and password, either from a config file or from environment variables, and it exposes them as metric labels and values. It also has VSPHERE_IGNORE_SSL, which by default is False, meaning it verifies the vCenter certificate, and a get_param precedence column for VSPHERE_HOST, which means the host can be supplied as a URL parameter on the metrics request.

The consequence is that whoever can reach the exporter can point it at a vCenter of their choosing and make it authenticate with the credentials it holds, and read the metrics of whatever it returns. In a shared environment, on a network segment without segmentation, or with a Prometheus that scrapes by hostname through a service discovery that resolves to arbitrary addresses, that is a credential relay.

The documentation does not describe any authentication on the exporter itself, any TLS on the metrics endpoint, or any allowlist of permitted hosts. The only hint of a security posture is the get_param precedence on VSPHERE_HOST, which reads as a feature rather than a control, since it exists so a single exporter can serve several vCenters.

None of this makes the exporter unusable. It makes it a component that belongs behind a network boundary, with the credentials supplied as environment variables rather than written into a config file, and with the metrics endpoint not reachable from anywhere untrusted. A deployment that satisfies those conditions gets a useful tool. A deployment that exposes port 9272 to a broad network gets a vCenter credential oracle, and the difference is entirely in the deployment, not in the code.

Where vmware_exporter is the wrong choice

The first case is a team that needs the vCenter data to be the source of truth rather than a mirror of it. A Prometheus exporter is a scrape-time pull. If vCenter is slow or unavailable, the metrics go stale and the dashboards show gaps, and no historical query can be run against vCenter through this path. A team that wants to ask historical questions about virtual machine state wants a time series database fed by this exporter, and that is a different design decision.

The second case is a large estate where the collection cost is real. The collect_only switches exist precisely because querying every object type against a big vCenter is expensive, and the specs_size parameter bounds the stats query. A deployment that has to turn off most of the collection to keep up is not getting much, and the workarounds, running several exporters or shrinking the estate, are operational burden the tool does not remove.

The third case is anyone who needs per-tenant or per-licence accounting. The exporter reports what vCenter exposes, and vSphere's own licensing and the entitlements that came with Broadcom's changes are exactly the thing this project cannot answer. A team that has to answer how many virtual machines a customer is entitled to needs the licence data, and this is not where it lives.

The alternative worth comparing is not another exporter but a different collection strategy. A vCenter or ESXi agent that runs on the hosts and pushes metrics, rather than an exporter that logs into the management API and pulls, avoids putting a vCenter administrator credential in a Prometheus scrape target and scales per host rather than per management server. The difference in approach is the trust boundary: a pull exporter holds a privileged credential, a push agent holds a local one on each host. For an estate where the management server is heavily federated and credential rotation is painful, that difference decides it.

Editorial conclusion

vmware_exporter fits a team that already runs vCenter and Prometheus and wants virtual machine, host, datastore and snapshot counts as time series, especially if they can tolerate running a container that holds vCenter credentials in its environment. It is the wrong choice for a team that needs per-tenant licensing enforcement, for anyone who cannot accept VSPHERE_IGNORE_SSL, and for a long-lived deployment that needs a maintained upstream, because the repository now carries a notice asking for a new maintainer. Before adopting it, read the notice at the top of the README first, and decide whether you would rather maintain the code yourself than depend on it, since the last push was on 2026-04-13 and the last tagged release is v0.18.4 from 2022-10-11.

Frequently asked questions

Official sources

1. Issues
2. License: BSD-3-Clause
3. pryorda/vmware_exporter on GitHub
4. README
5. Releases