Proxmox Datacenter Manager 2026: der Praxis-Stand nach einem Jahr

Als Proxmox Server Solutions im Sommer 2024 die erste Alpha des Proxmox Datacenter Manager — kurz PDM — veröffentlicht hat, war die Reaktion in der Community gemischt. Endlich ein zentrales Werkzeug für mehrere Cluster, hieß es. Aber auch: viel zu spät, viel zu dünn, und ohnehin nur eine Reaktion auf den Broadcom-Schock, der vCenter-Kunden reihenweise auf Alternativen umschauen ließ. Ein Jahr später — PDM ist inzwischen über mehrere Beta-Zyklen gereift und wird bei uns produktiv eingesetzt — ist es Zeit für eine nüchterne Zwischenbilanz. Was kann das Werkzeug wirklich? Wo klafft die Lücke zu vCenter noch? Und für welche Kunden ist der Einsatz jetzt schon sinnvoll?

Dieser Beitrag ist bewusst kein Feature-Feuerwerk. Wir zeigen, was PDM in unserer täglichen Arbeit mit KMU-Clustern in Bayern löst, welche Erwartungen realistisch sind und wo weiterhin ein Skript, ein zweites Werkzeug oder ein direkter Login in den einzelnen Cluster fällig wird.

Warum es den Proxmox Datacenter Manager überhaupt gibt

Ein Proxmox-Cluster ist von Haus aus für bis zu einigen Dutzend Nodes gedacht, mit einer gemeinsamen Konfigurationsdatenbank — pmxcfs — und Corosync-Quorum. Solange man in einem Rechenzentrum bleibt, mit einem Team, einer Berechtigungsstruktur und einem Netz, ist die Web-GUI eines beliebigen Nodes das Kontrollzentrum. Das funktioniert seit Jahren zuverlässig.

Sobald aber mehrere getrennte Cluster im Spiel sind — zwei Standorte, ein Produktivcluster und ein DR-Cluster, ein Kundencluster und der eigene Verwaltungscluster — gibt es keinen gemeinsamen Blick. Jeder Cluster hat seine eigene GUI, seine eigenen User, seine eigenen API-Token. Wer eine VM von A nach B verschieben will, arbeitet mit qm remote-migrate auf der Kommandozeile, so wie wir das in unserem Beitrag zur Live-Migration zwischen Clustern beschrieben haben. Praktisch, aber nichts für Kollegen ohne Shell-Erfahrung.

Genau diese Lücke soll PDM schließen. Ein zusätzlicher Node — oder eine VM — mit einer eigenen Web-Oberfläche, der die einzelnen Cluster remote über die bekannte API-Schnittstelle anspricht und deren Zustände, Ressourcen und Aktionen in einer gemeinsamen Ansicht bündelt.

Der PDM Update Praxis-Stand — was heute stabil läuft

Wir betreiben PDM in mehreren Kundenumgebungen inzwischen produktiv, immer als eigenständige Debian-VM auf einem der Verwaltungscluster, mit dediziertem HTTPS-Zertifikat und eigenem Backup. Der Ressourcenbedarf ist überschaubar: zwei vCPUs, 4 GB RAM und 32 GB Disk reichen für die Verwaltung eines halben Dutzends Cluster mit insgesamt einigen hundert VMs.

Multi-Cluster-Übersicht

Das erste, was PDM richtig macht, ist die Übersicht. Nach dem Anbinden mehrerer Cluster über Fingerprint und API-Token sieht man auf einem Dashboard die Anzahl der Nodes, den Zustand — grün, gelb, rot —, die aggregierte CPU- und RAM-Auslastung und offene Alarme. Für den Administrator, der früher fünf Browser-Tabs offen hatte, ist das ein spürbarer Zeitgewinn.

Die Detailansicht pro Cluster ist bewusst schlank gehalten. Es geht nicht darum, die native Cluster-GUI zu ersetzen, sondern einen Überblick zu geben und den Sprung in die jeweilige Ansicht anzubieten. Wer eine VM konfigurieren will, wird weiterhin in die Cluster-GUI durchgereicht — allerdings mit übernommenem Login, sofern SSO eingerichtet ist.

Zentrale Cross-Cluster-Migration

Das eigentliche Schwergewichts-Feature ist die zentrale Migration über die GUI. Was früher ein Kommandozeilen-Aufruf mit sorgfältig konstruierten Storage- und Bridge-Mappings war, ist jetzt ein Assistent: Quell-VM auswählen, Zielcluster auswählen, Storage- und Netzwerk-Zuordnung bestätigen, Migration starten. Der zugrundeliegende Mechanismus ist derselbe wie bei qm remote-migrate, nur eben mit einer Oberfläche davor.

In der Praxis funktioniert das gut, solange die Cluster technisch kompatibel sind: gleiche oder größere PVE-Version auf der Zielseite, kompatible Storage-Typen, ausreichend Bandbreite. Wir nutzen es für Hardware-Refresh, für die Rückwärts-Migration von der Test- in die Produktivumgebung und für Datacenter-Umzüge. Details zur Kompatibilität und den Grenzen sammeln wir in unserer laufenden Proxmox-Architektur-Serie.

Benutzer- und Team-Management mit SSO

PDM bringt eine eigene Benutzer- und Team-Verwaltung mit, die per OIDC oder LDAP an bestehende Identity Provider angebunden werden kann. Damit lassen sich zentral Rollen definieren — lesend, schreibend, migrationsberechtigt —, die dann als API-Tokens gegen die verbundenen Cluster arbeiten. Das ist zwar noch nicht so feingranular wie eine echte Delegation innerhalb der Cluster, deckt aber die typischen Anwendungsfälle im Systemhaus-Alltag ab: der Erste-Level-Support darf sehen und neu starten, der Zweite-Level darf konfigurieren, der Architekt darf migrieren.

Wer bereits ein Self-Hosted-SSO wie Authentik betreibt, kann PDM ohne Umweg anbinden. Für Umgebungen mit Active Directory funktioniert LDAP mit den üblichen Bind-User-Konventionen zuverlässig.

Zentrale API-Token- und Zertifikatsverwaltung

Ein Nebeneffekt der PDM-Einführung, den wir zu Beginn unterschätzt haben, ist das saubere Token-Handling. Statt in jedem Cluster einzeln API-Tokens für die Automatisierung anzulegen — Terraform, Ansible, Monitoring —, können wir jetzt an einer Stelle Rotationen anstoßen und den Überblick behalten, welcher Token welche Rechte hat. Das reduziert unangenehme Überraschungen bei Audits erheblich.

Was PDM heute noch nicht kann — die Lücke zu vCenter

So gut sich die Grundfunktionen anfühlen: PDM ist kein vCenter-Ersatz mit Feature-Parity. Wer aus einer VMware-Landschaft kommt, sollte die Lücken kennen, bevor er PDM als 1-zu-1-Migrationsziel bewirbt. Wir sammeln hier die Punkte, die uns in Kundenprojekten regelmäßig begegnen.

Kein echter Distributed Resource Scheduler

vCenter kennt mit DRS einen dynamischen Scheduler, der VMs automatisch zwischen Hosts umverteilt, um Last auszugleichen. Proxmox hat mit PVE 9.2 einen Dynamic Load Balancer in den HA-Stack integriert — Details dazu in unserem PVE-9.2-Release-Beitrag — aber dieser arbeitet innerhalb eines Clusters. PDM kann Ressourcen über Cluster hinweg sehen, aber nicht automatisch verschieben. Cross-Cluster-Balancing bleibt Handarbeit oder Skript.

Keine tiefe Ressourcen-RBAC

vCenter erlaubt Berechtigungen bis auf einzelne VMs, Ordner, Ressourcenpools und Netzwerksegmente. PDM arbeitet zurzeit hauptsächlich auf Cluster-Ebene. Wer feingranulare Delegation pro Kunde oder pro Mandant braucht, muss weiterhin die Cluster-eigenen ACLs pflegen oder mit Tags und Konventionen arbeiten.

Keine zentrale Backup-Steuerung

Der Proxmox Backup Server bleibt sein eigenes Ziel mit seiner eigenen GUI. PDM zeigt in der Übersicht Backup-Zustände und Alarme, kann aber keinen Backup-Job starten, keinen Restore auslösen und keine Retention ändern. Für eine vollständige Backup-Ansicht bleibt der direkte Login in den PBS oder das Monitoring.

Kein Content-Library-Äquivalent

Templates, ISOs, Snippets und Cloud-Init-Konfigurationen leben weiterhin pro Cluster. Ein zentraler Template-Katalog, wie ihn vCenter mit Content Libraries kennt, fehlt. Wer den Aufwand nicht in mehreren Clustern parallel treiben will, arbeitet aktuell mit einem gemeinsamen ISO-Storage über NFS oder S3 — eine Rolle, die zum Beispiel ein TrueNAS-System gut ausfüllt.

Kein Networking-Overlay-Management

SDN-Zonen, VNets und Firewall-Regeln werden pro Cluster definiert. PDM kann sie anzeigen, aber nicht cluster-übergreifend orchestrieren. In der Praxis heißt das: wer identische Netzwerksegmente in beiden Clustern will, pflegt sie doppelt oder deployt sie über ein IaC-Werkzeug wie Terraform.

Wann sich der PDM-Einsatz heute schon lohnt

Trotz der Lücken sehen wir klare Einsatzszenarien, in denen PDM heute schon einen echten Mehrwert bringt.

Zwei-Standort-Setups mit DR-Cluster

Kunden mit einem Produktiv- und einem DR-Cluster profitieren am stärksten. Der zentrale Blick auf beide Cluster und die einfache Migration ohne Shell-Gymnastik reduzieren die Fehlerquote bei Umzügen und Test-Failovers spürbar. Die Absicherung ergänzen wir typischerweise mit Proxmox-Replication zwischen zwei Standorten und einem PBS an dritter Stelle.

Managed-Service-Provider mit mehreren Kunden-Clustern

Wenn wir als Systemhaus mehrere getrennte Kundencluster betreuen, verkürzt PDM die Reaktionszeit im Support merklich. Statt Passwörter und URLs zu jonglieren, sieht der Erste-Level-Kollege alle Cluster in einer Ansicht und weiß sofort, wo es klemmt. Für strikte Mandantentrennung — die es bei uns natürlich weiterhin gibt — bleibt der direkte Login pro Kunde die saubere Lösung.

Migration weg von VMware

Für Kunden, die im Zuge des Broadcom-Umbaus von VMware weg wandern, ist PDM ein wichtiges Zwischenargument: das Verwaltungswerkzeug muss nicht komplett fehlen, es ist nur schmaler. Wer die vCenter-Funktionen ehrlich mappt und nur das behält, was er wirklich täglich nutzt, kommt mit PDM plus den nativen Cluster-GUIs in vielen Fällen sehr gut aus.

Betrieb, Backup und Absicherung des PDM selbst

Ein Detail, das gerne übersehen wird: PDM ist selbst ein System, das gesichert werden muss. Fällt der PDM-Node aus, fällt kein Cluster aus — die einzelnen Cluster laufen unabhängig weiter —, aber der zentrale Blick und die Migration über die GUI sind weg.

Wir behandeln den PDM-Node deshalb wie jede andere Management-VM: tägliches Backup über PBS, Konfigurationsstände in Git, dokumentierte Wiederherstellungsprozedur. Für den Hardware-Unterbau nutzen wir bewusst getrennte Ressourcen, damit ein Ausfall des Produktivclusters nicht gleichzeitig das Verwaltungswerkzeug lahmlegt.

Für den Storage-Unterbau der Verwaltungsumgebung eignet sich ein kleines, sparsames Setup — typischerweise ein TrueNAS-Mini oder eine Einstiegsvariante aus unserem TrueNAS-Konfigurator. Große M-Serie-Systeme braucht es für die reine PDM-Rolle nicht.

Aufwand für die Einführung und was wir realistisch veranschlagen

Die reine Installation von PDM ist an einem halben Tag erledigt: Debian-VM, Paket-Repository einrichten, PDM installieren, HTTPS-Zertifikat einbinden, erste Cluster registrieren. Der eigentliche Aufwand liegt danach:

• SSO-Anbindung mit sauberer Rollenmatrix
• API-Token-Konzept über alle Cluster
• Dokumentation für die Kollegen, damit die neue GUI genutzt wird und nicht die alten Bookmarks
• Monitoring des PDM-Nodes selbst

Feste EUR-Preise nennen wir hier bewusst nicht: die Kombination aus Hardware — oft läuft PDM einfach auf bestehender Infrastruktur —, Lizenzen für eine Proxmox-Subscription und Dienstleistungsaufwand ist zu individuell. Für eine realistische Einschätzung machen wir gern ein individuelles Angebot auf Basis Ihrer bestehenden Cluster und Ihrer Ziele.

Fazit — PDM 2026 ist erwachsen, aber kein vCenter

Der Proxmox Datacenter Manager ist ein Jahr nach der ersten Alpha erwachsen genug für den Produktiveinsatz. Multi-Cluster-Übersicht, zentrale Migration und SSO sind stabil und decken die häufigsten Systemhaus-Anwendungsfälle ab. Wer aus der VMware-Welt kommt, muss die Lücken kennen — DRS, tiefe RBAC, zentrales Backup, Content Library, cluster-übergreifendes SDN —, wird aber überrascht sein, wie viel tägliche Arbeit sich mit dem heutigen Funktionsumfang schon vereinfacht.

Für die nächsten Beta-Zyklen erwarten wir vor allem Fortschritte bei feingranularer RBAC und bei der Integration mit PBS. Bis dahin gilt: PDM einsetzen, wo er hilft, und die Cluster-GUI dort behalten, wo sie besser ist.

Häufige Fragen zum Proxmox Datacenter Manager

Ist der Proxmox Datacenter Manager schon für Produktivumgebungen freigegeben?

Er wird von Proxmox weiterhin als Beta geführt, ist aber in unserer Erfahrung stabil genug für den produktiven Einsatz — vorausgesetzt, PDM wird ordentlich gesichert und der Ausfall des Werkzeugs fällt nicht mit dem Ausfall der überwachten Cluster zusammen. Wir empfehlen den Einsatz mit klarem Backup-Plan und dokumentierter Wiederherstellung.

Kann PDM vCenter komplett ersetzen?

Nein, nicht in allen Funktionen. PDM deckt Multi-Cluster-Übersicht, zentrale Migration und Benutzer-Management ab. DRS-äquivalentes Scheduling über Cluster hinweg, tiefe RBAC bis auf VM-Ebene und eine Content Library fehlen. Wer diese Funktionen strikt braucht, muss die Lücken durch andere Werkzeuge oder Konventionen schließen.

Welche Hardware braucht der PDM-Node?

Wenig. Zwei vCPUs, 4 GB RAM und 32 GB Disk reichen für die Verwaltung mehrerer Cluster mit einigen hundert VMs. In der Praxis läuft PDM bei uns als schlanke Debian-VM auf einem Verwaltungscluster.

Unterstützt PDM Single Sign-On mit Active Directory oder OIDC?

Ja. PDM bindet sich per LDAP an Active Directory und per OIDC an moderne Identity Provider an. Wir kombinieren PDM häufig mit einem selbstgehosteten Authentik-Server, das funktioniert sauber und lässt sich zentral pflegen.

Löst PDM das Thema Cross-Cluster-Backup?

Nein. Der Proxmox Backup Server bleibt das eigentliche Backup-System mit eigener GUI. PDM zeigt Alarme und Zustände an, orchestriert aber keine Backup-Jobs oder Restores. Eine zentrale Backup-Verwaltung ist für PDM aktuell nicht angekündigt.

Für welche Kundengröße lohnt sich PDM heute?

Sinnvoll wird PDM ab zwei getrennten Clustern — also typischerweise Produktiv- und DR-Cluster — oder bei Managed-Service-Providern mit mehreren Kundenumgebungen. Für einen Ein-Cluster-Kunden bringt PDM heute noch keinen echten Mehrwert.