Zwei-Knoten-Cluster, Fibre Channel und ein Sprung ins Ungewisse: Einblick in eine VMware-zu-Proxmox-Migration

Ein IT-Team, das 10 Cluster und 21 Hosts über globale Standorte hinweg betreibt, migriert seine gesamte VMware-Infrastruktur zu Proxmox – und navigiert dabei durch architektonische Zwänge und Storage-Komplexitäten, die in keiner Herstellerdokumentation auftauchen.

Die Infrastruktur ist nicht klein: 10 Cluster über Standorte weltweit verteilt, insgesamt 21 Hosts, Produktions-Workloads verwaltet über ein einziges vCenter. Storage variiert je nach Standort – Pure-Storage-Arrays, Dell PowerStore, Dell Unity –, teils über Fibre Channel angebunden, teils über iSCSI.

Die Umgebung ist über die Zeit gewachsen, statt einem einheitlichen architektonischen Plan zu folgen. Unterschiedliche Hardware-Budgets, Standortautonomie und aufeinanderfolgende Servergenerationen schufen das, was ein Ingenieur als „das übliche Enterprise-Flickwerk" bezeichnete.

Jetzt steht der Plan, alles zu Proxmox zu migrieren, mit Unterstützung eines Partnerunternehmens. Doch das interne Team ist neu auf der Plattform, und die Fragen häufen sich.

Zwei-Knoten-Cluster stellen Quorum-Herausforderungen dar

VMware kommt mit Zwei-Knoten-Clustern problemlos zurecht. Proxmox erfordert sorgfältigere Planung.

Proxmox nutzt Corosync für das Cluster-Quorum, und zwei Knoten allein erzeugen ein Split-Brain-Risiko. Fällt ein Knoten aus, fehlt dem verbleibenden Host das Quorum, und er kann keine Cluster-Operationen mehr durchführen.

Der aktuelle Vorschlag sieht vor, für jeden Cluster einen Raspberry Pi als Quorum-Device hinzuzufügen. Proxmox unterstützt externe Quorum-Devices, das ist technisch also valide. Mehrere Ingenieure hinterfragten den Ansatz jedoch und schlugen stattdessen eine Konsolidierung zu 3–7-Knoten-Clustern vor. Bei 21 Hosts insgesamt geht die Rechnung auf.

Das Hindernis ist die Geografie. Die Standorte sind global verteilt. Workloads müssen aus Latenzgründen lokal bleiben. Fibre-Channel-Storage erstreckt sich nicht über Kontinente hinweg, was einen einzigen konsolidierten Cluster ausschließt.

„Manchmal entwirft man nicht von Grund auf neu. Man erbt", sagte ein Ingenieur.

Storage-Konfiguration erfordert Linux-Expertise

Der komplexeste Aspekt der Migration ist nicht Compute – es ist Storage.

Pure-Storage-Arrays, Dell PowerStore, Dell Unity und in manchen Umgebungen IBM FlashSystem. Fibre Channel mit 16Gb an manchen Standorten. iSCSI mit mehreren aktiven Pfaden an anderen.

Proxmox verhält sich hier anders als VMware.

LVM-Verwaltung wird notwendig

Bei Proxmox erfordern Fibre-Channel-LUNs in der Regel LVM (Logical Volume Manager). Das bedeutet, Administratoren müssen die Befehle pvcreate, vgcreate, lvcreate, lvs und vgs verstehen.

Für Teams, die an die Abstraktionsschicht von vCenter gewöhnt sind, ist das ein Umbruch. VMware verbirgt einen Großteil des darunterliegenden Linux-Storage-Stacks. Proxmox legt ihn offen.

Ein Ingenieur, der IBM FlashSystem über 16Gb Fibre Channel betreibt, sagte, es habe „wie ein Zauber funktioniert – nachdem man weiß, wie LVM funktioniert." Diese Einschränkung ist bezeichnend.

Thin Provisioning sorgt für Verwirrung beim Monitoring

Auf Pure-Storage-Arrays sind LUNs thin-provisioniert und auf SAN-Ebene dedupliziert. Aber LVM auf der Proxmox-Seite zeigt sie als vollständig allokiert an.

Das Proxmox-Dashboard meldet 100 % Auslastung, während das SAN aufgrund von Deduplizierung und Thin Provisioning eine tatsächlich niedrige Nutzung anzeigt. Ohne dieses Verständnis der Diskrepanz wird Kapazitätsplanung schwierig und löst potenziell Fehlalarme aus.

Multipath-Konfiguration muss dem LUN-Zugriff vorausgehen

Ob iSCSI oder Fibre Channel – die Multipath-I/O-Konfiguration ist entscheidend. Ist MPIO nicht konfiguriert, bevor LUNs auf Proxmox-Knoten beansprucht werden, können doppelte LUN-IDs auftauchen.

Ingenieure empfehlen, die MPIO-Konfiguration zu skripten und auf jeden Knoten anzuwenden, bevor überhaupt LUNs angesprochen werden, und dies dann zur Standardprozedur zu machen. Jede neue LUN erfordert einen WWID-Eintrag in der MPIO-Konfiguration auf jedem Knoten.

Für Deployments mit mehreren aktiven Storage-NICs betonten die Ingenieure, Ausfallszenarien zu testen, indem ein Port heruntergefahren wird, um die I/O-Kontinuität zu verifizieren.

Migrationsansätze: Import-Tool vs. Backup-Wiederherstellung

Proxmox enthält ein Import-Tool für VMware-VMs. Es funktioniert, indem es ESXi-Storage über die ESXi-Hosts einbindet und ausgeschaltete VMs importiert.

Bei kleinen VMs funktioniert das ausreichend gut. Bei großen Produktions-Workloads berichten manche Ingenieure, dass es langsam ist.

Viele Teams setzen stattdessen auf Veeam: die VM aus VMware sichern, direkt in Proxmox wiederherstellen, einschalten, dann bei Bedarf per Storage-Migration verschieben. Dieser Ansatz ist schneller, vertraut und bietet eine Rollback-Strategie.

„Wenn man bei Produktion über globale Standorte hinweg Hand anlegt, ist Geschwindigkeit schön. Sicherheit ist besser", sagte ein Ingenieur.

VMware Tools müssen vor der Migration entfernt werden

Wird VMware Tools vor der Migration von Windows-VMs nicht deinstalliert, kann das Probleme verursachen. Der Deinstaller kann fehlschlagen, sobald die VM nicht mehr auf ESXi läuft, und ein defektes VMware Tools in der Proxmox-VM hinterlassen.

Die korrekte Reihenfolge:

1. VMware Tools deinstallieren
2. VirtIO-Treiber installieren
3. QEMU-Agent installieren
4. VM herunterfahren
5. Konvertieren
6. In Proxmox hochfahren

Nach diesem Prozess passen sich VMs in der Regel problemlos an den Hypervisor-Wechsel an. Werden Schritte übersprungen, kann eine Treiberbereinigung zu ungünstigen Zeitpunkten nötig werden.

Netzwerkkonfiguration ändert sich nach der Migration

Wenn VMs von VMware zu Proxmox wechseln, ändert sich die virtuelle NIC-Hardware. Gast-Betriebssysteme behandeln das oft als neue Hardware.

Statische IP-Konfigurationen können verschwinden. Windows vergibt möglicherweise eine neue Schnittstelle. Linux kann die Interface-Benennung ändern.

Das Problem ist vorhersehbar, aber nicht offensichtlich. Eine Planung für die Netzwerk-Neukonfiguration nach der Migration – Dokumentation, welche VMs statische Zuweisungen haben – verhindert Verwirrung, wenn VMs nach der Migration scheinbar die Netzwerkverbindung verlieren.

Proof-of-Concept-Deployment geplant

Das Team plant keine sofortige Vollmigration. Zuerst wird ein Proof-of-Concept-Cluster bereitgestellt, gefolgt von einer Staging-Umgebung und kontrollierten Migrationen.

Dieser Ansatz ist nicht nur Best Practice – er ist notwendig. Selbst mit Partner-Support und erfahrenen Ingenieuren funktioniert Proxmox anders als VMware. Es ist Linux-first und verlangt von Administratoren, mehr vom Stack selbst zu verantworten.

Cluster-Architektur bleibt in der Diskussion

Es gibt eine ungeklärte architektonische Frage: Soll die Umgebung weniger, größere Cluster nutzen, oder Cluster beibehalten, die nach SAN, Hardware-Generation und Geografie gruppiert sind?

Weniger, größere Cluster sind einfacher zu verwalten und konsistent zu aktualisieren. Aber bei global verteilten Standorten halten lokale Cluster die Workloads lokal und verhindern, dass WAN-Latenz das HA-Verhalten beeinträchtigt. Sie isolieren zudem Risiken.

Ein Ingenieur merkte an, dass große Cluster Risiken bei größeren Upgrades konzentrieren. Laufen alle 21 Hosts in einem Cluster und ein Proxmox-Upgrade stößt auf Probleme, ist jede VM betroffen. Kleinere Cluster erlauben gestaffelte Upgrades, mit Tests zuerst auf weniger kritischen Clustern.

Es gibt keine universelle Antwort. Die Wahl hängt vom Verständnis der Kompromisse ab.

Der Plattformwechsel spiegelt sich ändernde Enterprise-Prioritäten wider

Diese Migration ist mehr als ein Hypervisor-Wechsel. Es ist ein Umzug von einem kommerziellen, stark abstrahierten Ökosystem zu einer offenen, transparenten, Linux-nativen Plattform.

Administratoren sehen mehr vom System. Sie konfigurieren mehr Komponenten direkt. Sie sind näher an der Infrastruktur.

Für manche Teams ist das befreiend. Für andere unangenehm.

Aber in Umgebungen, in denen Hardwarekosten zählen, sich Lizenzmodelle verändern und Flexibilität zunehmend wichtig wird, etabliert sich Proxmox als tragfähige Enterprise-Plattform – besonders im Zusammenspiel mit Enterprise-Storage wie Pure Storage und Dell-SANs.

Wichtige technische Überlegungen

Teams, die ähnliche Migrationen planen, sollten Folgendes im Blick behalten:

• Cluster-Design-Entscheidungen, die vor der Migration getroffen werden, nicht danach
• MPIO-Konfiguration, bevor überhaupt LUNs beansprucht werden
• Wie LVM thin-provisionierten Storage darstellt
• Entfernen von VMware Tools vor der Konvertierung
• Korrekte Installation von VirtIO und QEMU-Agent
• Änderungen der Netzwerkadapter-Hardware
• Tests für Storage-Pfad-Ausfälle
• Proof-of-Concept-Deployment

Keiner dieser Punkte ist glamourös. Aber sie machen den Unterschied zwischen einer erfolgreichen Migration und einer Notfall-Fehlersuche.

Der Abschied von etablierter Infrastruktur

In Teams, die diesen Übergang vollziehen, steckt kalkuliertes Vertrauen – kein blinder Optimismus, sondern bewertetes Risiko.

Proxmox ist nicht mehr experimentell. Es betreibt Produktions-Workloads auf Enterprise-Storage in ernsthaften Deployments.

Dennoch erfordert die Migration von 10 Clustern rund um den Globus, weg von einer Plattform, die jahrelang das Rückgrat der Infrastruktur war, sorgfältige Vorbereitung.

Prüfen Sie Ihre Abläufe zweimal. Stellen Sie sicher, dass Aufsicht vorhanden ist. Dann handeln Sie.

Denn 2026, mit VMwares Lizenzänderungen, die Migrationsentscheidungen antreiben, ist das Festhalten an bestehender Infrastruktur nicht immer die risikoärmste Option.