Warum Organisationen nicht auf Proxmox wechseln

Seit der Übernahme von VMware durch Broadcom taucht Proxmox in jedem Gespräch über Infrastruktur-Kostensenkung auf. Die Lizenzrechnung sieht verlockend aus: ein Bruchteil der VMware Enterprise Plus-Preise, Open Source, voller Funktionsumfang. Kostenbewusste CTOs fragen sich, warum sie nicht einfach wechseln sollten.

Hier ist die ehrliche Antwort: nicht als Drop-in-Ersatz.

Proxmox tauscht Hersteller-Leitplanken gegen volle Kontrolle. Dieser Tausch hat reale Kosten: in Fachwissen, Tooling und operativer Reife. Organisationen, die Proxmox als direkten Austausch betrachten, haben typischerweise Schwierigkeiten. Organisationen, die es als Plattformwechsel angehen, mit entweder interner Expertise oder einem Managed Partner, haben Erfolg.

Nach drei Jahren Proxmox in Produktion mit über 1000 VMs bei Natron zeigen wir, was die meisten Evaluationen falsch einschätzen.

Proxmox hat keine Leitplanken und genau das ist der Punkt (und das Problem)

VMware nimmt Sie an die Hand. Es gibt eine Hardware Compatibility List. Es gibt validierte Referenzarchitekturen. VMware warnt Sie, blockiert Sie oder verweigert schlicht den Dienst, wenn Ihr Setup die Anforderungen nicht erfüllt. Für viele Unternehmen kann genau das ein zweischneidiges Schwert sein.

Proxmox lässt Sie alles tun. Jede Hardware, jede Konfiguration, jede Topologie. Zwei-Node-Cluster ohne Quorum Device? Kein Problem. Consumer-SSDs als Ceph Journals? Nur zu. Cluster mit mehr VMs überladen, als er verkraften kann? Bitte sehr. Proxmox wird Sie nicht aufhalten. Es geht davon aus, dass Sie wissen, was Sie tun.

Das ist ein bedeutender Kompromiss.

Die Freiheit, eigene Hardware, eigenes Netzwerkdesign und eigenes Storage-Layout zu wählen, bedeutet: Sie können genau die Infrastruktur bauen, die Sie brauchen, optimiert für Ihre Workloads und Ihr Budget. Kein Hersteller, der Ihnen sagt, dass Ihre einwandfreien Server nicht auf der freigegebenen Liste stehen. Keine erzwungenen Hardware-Refresh-Zyklen, weil sich eine Kompatibilitätsmatrix geändert hat.

Aber es bedeutet auch: Proxmox geht davon aus, dass Sie wissen, was Sie tun. Es gibt keinen Wizard, der Ihre Architektur validiert. Keine Pre-Flight-Prüfung, die Ihnen sagt, dass Ihr Ceph-Netzwerk unterdimensioniert ist oder Ihr HA Fencing mit dieser Hardware nicht funktionieren wird. Sie sind die Leitplanke.

Genau hier kommen viele VMware-Migrationen ins Stocken. Teams, die eine Plattform gewohnt sind, die sie in gute Entscheidungen lenkt, haben plötzlich totale Freiheit und totale Verantwortung. Sie brauchen fundiertes Wissen in Linux, Networking, Storage und Hardware. Sie müssen verstehen, warum ein Design funktioniert, nicht nur einem Referenzhandbuch des Herstellers folgen.

Das ist keine Kritik. Es ist der Hauptgrund, warum Organisationen den Schritt nicht wagen. Wenn Ihr Team starke Linux- und Infrastruktur-Kompetenzen hat (oder einen Managed Proxmox Partner, der diese mitbringt), ist die Freiheit eine Superkraft.

HA klingt einfach. Ist es nicht.

Proxmox hat integrierte High Availability. Häkchen setzen, VM einer HA-Gruppe zuweisen, fertig. Wenn ein Node ausfällt, startet die VM auf einem anderen Node neu.

In der Theorie.

In der Praxis braucht Corosync zuverlässige, latenzarme Verbindungen zwischen den Nodes. Wenn diese Verbindungen instabil werden, entstehen Split-Brain-Szenarien, und Split-Brain in einem Hypervisor-Cluster ist die Art von Problem, die Ihren Tag ruiniert.

Was wir auf die harte Tour gelernt haben:

• Redundante Corosync Links. Corosync ist der Herzschlag Ihres Clusters. Ein einziger Link, der im falschen Moment instabil wird, kann einen Split-Brain auslösen. Redundanz ist keine Option, sondern Pflicht.
• Failover-Tests müssen durchgeführt werden. Konfiguriertes HA ist nicht validiertes HA. Ziehen Sie ein Stromkabel, simulieren Sie eine Netzwerkpartition, schalten Sie einen Node aus. Wenn Sie es nicht getestet haben, wissen Sie nicht, ob es funktioniert.
• Kapazitätsplanung der Ressourcen. Wenn ein Node ausfällt, starten seine VMs auf den verbleibenden Nodes neu. Wenn diese bereits bei 80% Auslastung laufen, haben Sie keinen HA-Cluster: Sie haben einen Cluster, der zweimal ausfällt.

HA ist essenziell. Aber behandeln Sie es als etwas, das Sie planen, nicht als etwas, das Sie aktivieren.

Monitoring ist kein Nice-to-have: Es ist das Produkt

Die integrierte Proxmox-Oberfläche zeigt Ihnen das Nötigste: CPU-Graphen, Speicherverbrauch, ein Task-Log. Das reicht, um zu wissen, dass etwas kaputt ist. Es sagt Ihnen nichts darüber, warum, nichts darüber, was als Nächstes ausfallen wird, und nichts darüber, ob Ihr Cluster gesund ist oder nur ruhig.

In der Produktion ist die eigentliche Arbeit nicht die Installation eines Monitoring-Stacks. Es geht darum herauszufinden, was Sie wirklich überwachen müssen. Proxmox gibt Ihnen keine fertige Antwort. Sie müssen selbst erarbeiten, welche Signale relevant sind: Hält Ihr Storage-Netzwerk mit, oder drosselt es die VM-Performance im Stillen? Sind Ihre OSD-Disks gesund oder degradieren sie unbemerkt? Ist Ihr HA Fencing unter realen Ausfallbedingungen zuverlässig oder nur unter den Bedingungen, die Sie getestet haben?

Das braucht Zeit und Vorfälle. Sie lernen, was Sie überwachen müssen, indem Sie auf Probleme stossen, die Sie nicht kommen sahen. Jeder Produktionsvorfall lehrt Sie etwas, das zu einem Alert oder einem Dashboard werden sollte. In drei Jahren haben wir dieses Wissen aufgebaut. Wir wissen, welche Metriken Ausfälle vorhersagen, bevor sie eintreten, und welche Alerts nur Rauschen sind.

Das ist eine der grösseren Lücken bei einer VMware-Migration. VMware kommt mit Jahrzehnten an Tooling, Integrationen und zertifizierten Beratern, die Ihr Problem schon einmal gesehen haben. Proxmox kommt mit einer grossartigen Plattform und einem leeren Blatt. Sie müssen die Observability-Schicht selbst aufbauen, und es braucht echte Produktionserfahrung, um sie gut aufzubauen.