VMware → Proxmox

The VMware-to-Proxmox business case is usually about one line item, and it closes fast. The migration plan that follows covers storage, networking, the VM conversion tooling and the cutover weekend. What it almost never covers is the monitoring — because on VMware, monitoring was not a thing you did, it was a thing vCenter had.

That is the trap. vCenter alarms, Aria Operations dashboards, VMware Tools guest telemetry and vSAN health were a bundled, opinionated monitoring product that came with the licence. Proxmox VE is an excellent hypervisor with a built-in status page and an API. Everything between those two — the alerting, the capacity view, the guest visibility, the thirty dashboards the ops team lived in — has to be rebuilt, and the migration plan should say so.

This post is the mapping: what each VMware capability corresponds to on Proxmox, what has no equivalent, and what to build. The how — sources, receivers, the collector config — is in Proxmox monitoring with OpenTelemetry; this is the piece that goes in the migration plan before that.

The mapping

VMware had	Proxmox has	Gap
vCenter alarms — hundreds of predefined, per-object, with actions	Node/guest status in the UI; no alarm engine	Alerting has to be built outside Proxmox, on metrics you collect
Aria Operations — capacity planning, forecasting, rightsizing	Nothing bundled	Build the capacity view in your metrics backend; forecasting is yours to model
vSphere performance counters per VM	PVE API (per-guest CPU, memory, disk, net)	Comparable data, but via an exporter or line-protocol push, not a counter browser
VMware Tools — guest OS view from the host	qemu-guest-agent — basic guest info	Guest-internal metrics need an agent inside the guest
vSAN health — integrated storage monitoring	Ceph mgr Prometheus module, ZFS via node metrics	Good coverage, but it is a separate source, not part of the hypervisor view
DRS — load balancing with its own telemetry	HA and manual/scripted migration; no DRS	No equivalent; the signal (host imbalance) still needs monitoring
vCenter events — audit trail of who did what	PVE task log + journald	Present, but a file source you must collect and retain deliberately

The pattern in the right-hand column is consistent: the data is almost all available on Proxmox. The product that assembled it into alarms, dashboards and forecasts is not.

What that means for the plan

Three workstreams that should be in the migration plan and usually are not:

• Alerting has to be rebuilt from scratch. The vCenter alarm library was the ops team’s institutional memory: which thresholds mattered, on which objects, with which escalation. That knowledge has to be re-expressed as alert rules in whatever you point the collected metrics at. Export the alarm definitions before decommissioning vCenter; they are the requirements document.
• Guest visibility changes model. On VMware the host saw inside the guest via Tools. On Proxmox, host-side metrics tell you what the hypervisor sees, and anything internal — filesystem usage, application logs, CPU steal — needs a collector in the guest. That is an agent rollout across every VM, and it belongs in the plan as its own line.
• The event trail becomes your responsibility. vCenter kept its own event history. Proxmox writes task outcomes and cluster events to files on each node. If an auditor asks who migrated which VM when, the answer exists only if you collected and retained those files — see the journald and task-log sources in the Proxmox post.

Where the migration is an upgrade

It is not all loss, and the plan should say that too:

• You choose the backend. vCenter’s monitoring was vCenter’s. Metrics from Proxmox go to whatever you run — Prometheus and Grafana on-prem, or a cloud backend for the parts with no sensitive content. That is a routing decision, not a platform commitment.
• One collection layer for hypervisor and guests. The same OpenTelemetry Collector that runs on each Proxmox node runs inside each guest, with one config model and one fleet view. VMware’s split between Tools, vCenter and whatever agent ran in the guest goes away.
• The data stays where you put it. Teams leaving VMware for cost reasons often also left it for control reasons. A monitoring layer you own on infrastructure you own keeps that intact — the argument in digital sovereignty for observability data.

Sequencing

1. Export the vCenter alarm definitions and the Aria dashboards you actually use. Do this first; once vCenter is gone, so is the requirements list.
2. Stand up collection on the Proxmox side before migrating the first production VM. Node metrics, the PVE API, Ceph if you run it — the Proxmox post has the config.
3. Roll a collector into guests as they migrate. Each converted VM gets its agent as part of the conversion runbook, not as a follow-up project.
4. Rebuild the alerts that fired in the last twelve months. Not all of them — the ones with a history. The rest were noise on VMware too.
5. Decommission vCenter last, after the Proxmox alerts have been live long enough to catch a real incident.

The honest summary

The hypervisor migration is well understood and well tooled. The monitoring migration is neither, because on VMware it was never a separate system — it was a feature. Budget it as a workstream with its own owner, expect to rebuild alerting from requirements rather than port it, and treat guest agents as part of every VM conversion. Done that way, you end up with a monitoring layer you own rather than one you licensed, which was the point of leaving.