VMware vSphere MonitoringWithout Touching a Single Guest

One Glouton agent, on one Linux or Windows machine, talks to your vSphere API with a read-only account and discovers the whole estate: clusters, ESXi hosts, virtual machines and datastores. Nothing is installed inside the VMs — which is usually the reason a VMware team says no to monitoring in the first place.

vCenter or standalone ESXi • Read-only vSphere account • Discovered objects billed from 3,99 €/month each

4
Object Types Discovered
0
Agents in Guests
13 months
Metrics Retention

Overview

The Objection Is Never the Metrics

Nobody argues about whether ESXi hosts should be monitored. The argument is about what it costs to get there: a package on three hundred guests, an exception in the golden image, a change request per VM, and a fleet where half the machines are appliances you are not allowed to touch anyway.

Bleemeo reads vSphere the way vSphere expects to be read. You install one Glouton agent on any Linux or Windows machine that can reach vCenter, give it a read-only vSphere account, and it walks the inventory: every cluster, every host, every VM, every datastore. New objects appear within minutes of being created, because discovery runs continuously rather than on a nightly sync.

Where you want in-guest detail — per-process CPU, discovered services, logs — you install the agent in that VM, and it lands in the same account and the same dashboards. It is an addition, not a prerequisite.

Coverage

What Gets Discovered

Four object types, walked from the vCenter inventory. Standalone ESXi hosts work the same way, minus the cluster. Clusters, hosts and VMs are each a billed resource; datastores are not.

Clusters

Aggregated CPU and memory across every host in the cluster, so you can see pressure at the level you actually plan capacity at.

  • CPU used across the cluster
  • Memory used, as a percentage
  • Recomputed as hosts join or leave

ESXi hosts

Eleven metrics per host, including the two counters that matter for consolidation ratio and are easy to lose track of: how many VMs are running and how many are not.

  • CPU, memory total and used
  • Swap in and swap out
  • Disk read and write throughput
  • Network sent and received
  • Running and stopped VM counts

Virtual machines

Nine metrics per VM without an agent inside it — including CPU latency, which is how you tell a slow VM from an oversubscribed host.

  • CPU used and CPU latency
  • Memory used and swap
  • Disk read and write throughput
  • Network sent and received
  • Filesystem usage

Datastores

Capacity and I/O per datastore, so a filling datastore becomes a date in the weekly report rather than a surprise at snapshot time.

  • Disk used and total
  • Read and write throughput
  • Feeds the capacity forecast

Setup

Three Steps, One Machine

The agent can run anywhere that reaches vCenter — a management VM, a jump host, a container. Several vCenters and ESXi hosts can be listed side by side.

1

Create a read-only vSphere account

The account needs read access to the objects you want to monitor: datacenter, cluster, hosts, VMs, datastores. Read-only is enough, and it is the whole permission story — there is nothing to grant beyond it.

2

Install one Glouton agent

On any Linux or Windows machine that can reach the vSphere API. One command on Linux, an installer on Windows. This machine is a collector, not a target: it does not have to sit inside the cluster.

3

Add the connection to its config

A few lines in a drop-in file listing the vCenter or ESXi URL and the account. Add more entries for more vCenters. Discovery starts immediately and the dashboards fill as the inventory is walked.

Migration

Moving Off VMware? You Will Run Both for a While

Licensing changes have put a lot of teams on a path to Proxmox, Nutanix or plain KVM. Those migrations take six to eighteen months, and for all of that time you are running two hypervisors, two consoles and one on-call rotation that has to cover both.

Bleemeo spans the two sides without changing tools halfway through. vSphere is read through its API, and a Proxmox VE host is a Debian machine, so the same agent that monitors your Linux fleet monitors the new hypervisor — same account, same dashboards, same alert rules, same weekly report. Migrating hypervisors is disruptive enough without also migrating your monitoring.

Both sides, one dashboard

An application spread across ESXi VMs and Proxmox guests during a migration can sit behind a single application tag, so the health view does not fragment along the migration boundary.

Proxmox VE and Backup Server

Both are Debian-based, so the agent installs from our APT repository with one command — Proxmox VE 7, 8 and 9, and every Proxmox Backup Server version. You get host CPU, memory, disk, network and filesystems, plus the services running on it.

Guests keep their own detail

On the VMware side, guest detail is optional because the API provides it. On the Proxmox side, per-guest metrics come from installing the agent in the guests you care about — the same agent, so nothing new to learn.

The comparison stays honest

Before and after a migration you are looking at the same metric names on the same charts with the same retention, which is what makes "is the new platform actually better?" a question you can answer with data.

Comparison

vCenter Alone vs vCenter Through Bleemeo

FeaturevCenter aloneBleemeo
vSphere inventory metrics
Complete, first-party
Read from the vSphere API, same source
Agents inside guests
Not needed
Not needed
Non-VMware infrastructure
Out of scope
Bare metal, cloud, containers, Kubernetes
History
Rolled up aggressively past a few days
13 months at full resolution
Alerting
vCenter alarms, per object
Pre-built defaults, Slack, PagerDuty, SMS
Capacity forecasting
Manual, or a separate product
A date for each datastore and disk
During a hypervisor migration
Covers the side you are leaving
Covers both sides at once
Access required
Administrator, in practice
A read-only vSphere account

Frequently Asked Questions

vSphere monitoring with Bleemeo, in practice

Do I need to install an agent inside my virtual machines?

No. One Glouton agent, on one machine that can reach vCenter, is enough to discover and monitor every cluster, host, VM and datastore. Installing the agent inside a guest is optional and gives you what only the guest knows: per-process CPU and memory, discovered services like MySQL or Nginx, and logs.

What vSphere permissions does Bleemeo need?

Read-only permissions on the objects you want to monitor — datacenter, cluster, hosts, VMs, datastores. That is the entire requirement. The agent reads the inventory and the performance counters; it cannot power on, migrate, reconfigure or delete anything.

Does it work without vCenter?

Yes. Glouton connects to a standalone ESXi host the same way it connects to vCenter. You lose the cluster object, since there is no cluster, and everything else works. You can also list several vCenters and several standalone hosts in the same configuration.

How quickly are new VMs picked up?

Within minutes. Discovery runs continuously rather than as a nightly sync, so a VM created this morning is on a dashboard this morning — which matters when the fleet churns.

What is CPU latency and why does it matter?

It is the share of time a VM was ready to run but waiting for physical CPU. A VM can show modest CPU usage and still be slow because the host is oversubscribed, and CPU latency is what tells the two apart. Bleemeo collects it per VM, so "the app is slow" stops being an argument between the app team and the platform team.

We are migrating from VMware to Proxmox. Does that work?

Yes, and it is a good reason to move monitoring first. vSphere is read through its API; a Proxmox VE host is Debian, so the same agent installs from our APT repository — Proxmox VE 7, 8 and 9, and Proxmox Backup Server. During the migration both sides report into one account with the same dashboards and alerts, so you are not changing monitoring while changing hypervisors.

How is vSphere monitoring billed?

Each discovered cluster, host and virtual machine is a monitored resource, priced like any other: 4,99 € per month on Professional and 3,99 € on Starter. Datastores are not billed.

On a large estate that adds up, so the agent has a switch for it: set skip_monitor_vms and Glouton monitors clusters, hosts and datastores only. You keep host-level counts of running and stopped VMs, and you stop paying per guest. See pricing for the full table.

Which plans include VMware monitoring?

vSphere monitoring is available on the Starter and Professional plans. See pricing for the details.

Monitor vSphere Without Negotiating With Three Hundred Guests

One agent, one read-only account, and your whole estate on a dashboard in an afternoon. Fifteen days, no credit card.