VMware → Proxmox

Der Business Case für den Wechsel von VMware zu Proxmox dreht sich meist um einen einzigen Posten und schliesst schnell. Der Migrationsplan, der folgt, deckt Storage, Netzwerk, die Werkzeuge für die VM-Konvertierung und das Cutover-Wochenende ab. Was er fast nie abdeckt, ist das Monitoring — denn auf VMware war Monitoring nichts, was man tat; es war etwas, das vCenter hatte.

Das ist die Falle. vCenter-Alarme, Aria-Operations-Dashboards, Gast-Telemetrie über VMware Tools und vSAN-Health waren ein gebündeltes, meinungsstarkes Monitoring-Produkt, das mit der Lizenz kam. Proxmox VE ist ein ausgezeichneter Hypervisor mit einer eingebauten Statusseite und einer API. Alles dazwischen — das Alerting, die Kapazitätssicht, die Gast-Sichtbarkeit, die dreissig Dashboards, in denen das Ops-Team lebte — muss neu gebaut werden, und der Migrationsplan sollte das sagen.

Dieser Beitrag ist die Zuordnung: Welche VMware-Fähigkeit entspricht was auf Proxmox, was hat kein Gegenstück, und was ist zu bauen. Das Wie — Quellen, Receiver, die Collector-Konfiguration — steht in Proxmox-Monitoring mit OpenTelemetry; dies ist das Stück, das davor in den Migrationsplan gehört.

Die Zuordnung

VMware hatte	Proxmox hat	Lücke
vCenter-Alarme — hunderte vordefiniert, pro Objekt, mit Aktionen	Node-/Guest-Status im UI; keine Alarm-Engine	Alerting muss ausserhalb von Proxmox gebaut werden, auf Metriken, die Sie erfassen
Aria Operations — Kapazitätsplanung, Prognosen, Rightsizing	Nichts gebündelt	Kapazitätssicht im Metrik-Backend bauen; Prognosen modellieren Sie selbst
vSphere-Performance-Counter pro VM	PVE-API (CPU, Arbeitsspeicher, Disk, Netz pro Guest)	Vergleichbare Daten, aber über Exporter oder Line-Protocol-Push, nicht über einen Counter-Browser
VMware Tools — Gast-OS-Sicht vom Host aus	qemu-guest-agent — grundlegende Gast-Infos	Gast-interne Metriken brauchen einen Agenten im Guest
vSAN-Health — integriertes Storage-Monitoring	Ceph-mgr-Prometheus-Modul, ZFS über Node-Metriken	Gute Abdeckung, aber eine separate Quelle, kein Teil der Hypervisor-Sicht
DRS — Lastverteilung mit eigener Telemetrie	HA und manuelle/skriptgesteuerte Migration; kein DRS	Kein Gegenstück; das Signal (Host-Ungleichgewicht) braucht trotzdem Monitoring
vCenter-Events — Audit-Trail, wer was getan hat	PVE-Task-Log + journald	Vorhanden, aber eine Dateiquelle, die Sie bewusst erfassen und aufbewahren müssen

Das Muster in der rechten Spalte ist durchgängig: Die Daten sind auf Proxmox fast alle vorhanden. Das Produkt, das sie zu Alarmen, Dashboards und Prognosen zusammengesetzt hat, ist es nicht.

Was das für den Plan bedeutet

Drei Arbeitsstränge, die in den Migrationsplan gehören und es meist nicht sind:

• Das Alerting muss von Grund auf neu gebaut werden. Die vCenter-Alarmbibliothek war das institutionelle Gedächtnis des Ops-Teams: welche Schwellenwerte zählten, auf welchen Objekten, mit welcher Eskalation. Dieses Wissen muss als Alert-Regeln neu ausgedrückt werden, in dem, worauf Sie die erfassten Metriken richten. Exportieren Sie die Alarmdefinitionen, bevor Sie vCenter abbauen; sie sind das Anforderungsdokument.
• Die Gast-Sichtbarkeit wechselt das Modell. Auf VMware sah der Host über Tools in den Guest hinein. Auf Proxmox sagen Ihnen host-seitige Metriken, was der Hypervisor sieht; alles Interne — Dateisystembelegung, Anwendungslogs, CPU-Steal — braucht einen Collector im Guest. Das ist ein Agent-Rollout über jede VM und gehört als eigene Zeile in den Plan.
• Der Ereignis-Trail wird Ihre Verantwortung. vCenter führte seine eigene Ereignishistorie. Proxmox schreibt Task-Ergebnisse und Cluster-Ereignisse in Dateien auf jedem Node. Fragt ein Prüfer, wer wann welche VM migriert hat, existiert die Antwort nur, wenn Sie diese Dateien erfasst und aufbewahrt haben — siehe die journald- und Task-Log-Quellen im Proxmox-Beitrag.

Wo die Migration ein Fortschritt ist

Es ist nicht nur Verlust, und auch das sollte der Plan sagen:

• Sie wählen das Backend. vCenters Monitoring gehörte vCenter. Metriken aus Proxmox gehen an das, was Sie betreiben — Prometheus und Grafana on-prem, oder ein Cloud-Backend für die Teile ohne sensiblen Inhalt. Das ist eine Routing-Entscheidung, keine Plattformbindung.
• Eine Erfassungsschicht für Hypervisor und Guests. Derselbe OpenTelemetry Collector, der auf jedem Proxmox-Node läuft, läuft in jedem Guest — mit einem Konfigurationsmodell und einer Flottenansicht. VMwares Aufteilung zwischen Tools, vCenter und dem Agenten, der im Guest lief, entfällt.
• Die Daten bleiben, wo Sie sie hinlegen. Teams, die VMware aus Kostengründen verlassen, haben es oft auch aus Kontrollgründen verlassen. Eine Monitoring-Schicht, die Ihnen gehört, auf Infrastruktur, die Ihnen gehört, bewahrt das — das Argument in digitaler Souveränität für Observability-Daten.

Reihenfolge

1. Exportieren Sie die vCenter-Alarmdefinitionen und die Aria-Dashboards, die Sie tatsächlich nutzen. Zuerst; ist vCenter weg, ist es die Anforderungsliste auch.
2. Bauen Sie die Erfassung auf der Proxmox-Seite auf, bevor die erste Produktions-VM migriert. Node-Metriken, die PVE-API, Ceph, falls Sie es betreiben — die Config steht im Proxmox-Beitrag.
3. Rollen Sie einen Collector in die Guests aus, während sie migrieren. Jede konvertierte VM bekommt ihren Agenten als Teil des Konvertierungs-Runbooks, nicht als Folgeprojekt.
4. Bauen Sie die Alerts neu, die in den letzten zwölf Monaten gefeuert haben. Nicht alle — die mit Historie. Der Rest war auf VMware auch Rauschen.
5. Bauen Sie vCenter zuletzt ab, nachdem die Proxmox-Alerts lange genug live waren, um einen echten Vorfall zu fangen.

Die ehrliche Zusammenfassung

Die Hypervisor-Migration ist gut verstanden und gut mit Werkzeugen versorgt. Die Monitoring-Migration ist beides nicht, weil sie auf VMware nie ein eigenes System war — sondern ein Feature. Budgetieren Sie sie als Arbeitsstrang mit eigenem Eigentümer, rechnen Sie damit, das Alerting aus Anforderungen neu zu bauen statt es zu portieren, und behandeln Sie Gast-Agenten als Teil jeder VM-Konvertierung. So gemacht, enden Sie mit einer Monitoring-Schicht, die Ihnen gehört statt lizenziert ist — und das war der Grund wegzugehen.