Von VMware zu Proxmox migrieren: Praxisplan für virtuelle Server und Cluster

Wenn die Verlängerung von VMware-Lizenzen ansteht, ist die Frage nach einer Alternative plötzlich kein Architekturthema mehr für das nächste Jahr. Dann muss das IT-Team kurzfristig klären, welche virtuellen Server kritisch sind, ob die vorhandene Hardware passt und wie ein Wechsel ohne unnötige Ausfallzeiten gelingt. Proxmox VE ist für viele Unternehmen eine ernsthafte Option, weil die Plattform Virtualisierung, Container, Cluster-Funktionen, Backup-Integration und eine Weboberfläche in einem System verbindet. Trotzdem ist eine Migration kein simples Kopieren von virtuellen Festplatten. Sie verändert Abläufe, Betriebskonzepte und oft auch die Storage-Architektur.

Veränderte VMware-Lizenzmodelle und die daraus entstandene Unsicherheit sind ein aktueller Anlass, Virtualisierungsplattformen neu zu bewerten. Entscheidend sollte aber nicht allein der Lizenzpreis sein. Prüfe, ob Proxmox VE zu deinen Anforderungen an Verfügbarkeit, Backup, Netzwerksegmentierung, Monitoring, Automatisierung und Betriebskompetenz passt.

Infografik zu Von VMware zu Proxmox migrieren: Praxisplan für virtuelle Server und Cluster (KI-generiert).

Den Migrationsumfang realistisch bestimmen

Der Begriff „von VMware zu Proxmox migrieren“ kann sehr Unterschiedliches bedeuten. Manche Teams möchten zunächst einzelne Testsysteme umziehen. Andere planen, einen gesamten vSphere-Cluster mit mehreren Hosts, zentralem Storage und geschäftskritischen Diensten abzulösen. Diese Vorhaben brauchen unterschiedliche Vorgehensweisen.

Beginne deshalb mit einer vollständigen Bestandsaufnahme. Verlass dich dabei nicht nur auf die vCenter-Inventarliste. Ergänze technische und betriebliche Informationen, die bei einem Import nicht automatisch mitwandern.

Erfasse mindestens:

• Virtuelle Maschinen mit Betriebssystem, Version, CPU, Arbeitsspeicher und Plattenkapazität
• Kritikalität, Verantwortliche und zulässige Wartungsfenster
• Abhängigkeiten zwischen Anwendungen, Datenbanken, Active Directory, DNS und Dateidiensten
• Netzwerkzuordnung, VLANs, IP-Adressen, Firewall-Regeln und Load Balancer
• Verwendete VMware-Funktionen wie Snapshots, vMotion, HA, DRS oder virtuelle Distributed Switches
• Storage-Anbindung, etwa iSCSI, NFS, Fibre Channel oder lokaler Datenspeicher
• Backup-Jobs, Aufbewahrungszeiten, Wiederherstellungsziele und Restore-Tests
• Besonderheiten wie USB-Durchreichung, GPU-Nutzung, Dongles oder spezielle virtuelle Hardware

Ordne jede VM einer Migrationsgruppe zu. Eine sinnvolle Reihenfolge ist: Testsysteme, interne unkritische Dienste, Fachanwendungen, Infrastrukturserver und zuletzt besonders kritische Systeme. Ein Domain Controller oder die zentrale Datenbank sollte nicht als erstes Pilotobjekt dienen.

Für die Planung komplexerer Windows-Server-Landschaften hilft auch unser Beitrag „Windows Server 2016 auf Windows Server 2025 migrieren: Praxisplan vor dem Support-Ende“. Denn Virtualisierungswechsel und Betriebssystemmodernisierung sollten nur dann zusammenfallen, wenn dein Team beide Risiken bewusst beherrscht.

Kompatibilität von Hardware, Storage und Betriebssystemen prüfen

Proxmox VE basiert auf Debian Linux und nutzt für virtuelle Maschinen KVM sowie für Container LXC. Bevor du Workloads importierst, prüfst du zuerst die Zielplattform. Besonders wichtig sind Prozessorvirtualisierung, ausreichend Arbeitsspeicher, kompatible Netzwerkkarten und eine belastbare Storage-Anbindung.

Bei bestehenden VMware-Hosts lohnt sich eine Prüfung, ob sie weiterverwendet werden können. Technisch geeignete Hardware ist jedoch nicht automatisch betrieblich sinnvoll. Ein älterer Host kann beispielsweise zwar Proxmox VE ausführen, aber für aktuelle Storage-Anforderungen, Reserven oder einen sicheren Clusterbetrieb zu knapp dimensioniert sein.

Für die Storage-Planung musst du eine Grundsatzentscheidung treffen:

Szenario	Typischer Ansatz	Worauf du achten solltest
Einzelner Host	Lokaler ZFS- oder LVM-basierter Storage	Kein automatischer Schutz bei Host-Ausfall
Mehrere Hosts mit vorhandenem SAN oder NAS	Gemeinsamer Storage über unterstützte Protokolle	Redundante Pfade, Performance und Fehlerverhalten testen
Neu aufgebauter Cluster	Hyperkonvergentes Storage, etwa Ceph	Planung, Kapazität, Netzwerk und Betriebswissen früh klären

Ceph kann für hochverfügbare Cluster sinnvoll sein, erhöht aber die Anforderungen an Netzwerk, Hardware und Betrieb erheblich. Es ist keine Pflicht für Proxmox-Cluster. Wenn bereits ein zuverlässiger zentraler Storage vorhanden ist, kann dieser für den Einstieg der passendere Weg sein.

Bei virtuellen Maschinen prüfst du außerdem die Gastbetriebssysteme. Linux-Systeme kommen häufig ohne größere Anpassung zurecht. Bei Windows-VMs sind VirtIO-Treiber besonders wichtig, damit Storage und Netzwerk performant und zuverlässig arbeiten. Plane die Treiberinstallation vor dem Wechsel ein oder stelle sicher, dass du beim ersten Start über die virtuelle Konsole eingreifen kannst.

Netzwerk früh planen statt beim Cutover improvisieren

VMware-Umgebungen enthalten oft über Jahre gewachsene Portgruppen, VLANs und Regeln. In Proxmox VE werden Netzwerke anders modelliert, typischerweise mit Linux Bridges, VLAN-Konfiguration und bei Bedarf Bonding mehrerer physischer Netzwerkkarten. Übertrage diese Struktur nicht blind, sondern dokumentiere die gewünschte Zielarchitektur.

Trenne mindestens Management, Migration, Storage und produktive VM-Netze, wenn deine Infrastruktur und Sicherheitsvorgaben das erfordern. Achte auf konsistente VLAN-IDs über Switches, Hosts und Bridges hinweg. Bei Storage über ein separates Netzwerk müssen auch MTU-Einstellungen und Redundanz überprüft werden.

Ein häufiger Fehler: Die VM startet nach dem Import technisch korrekt, ist aber nicht erreichbar. Gründe können eine fehlende VLAN-Zuordnung, eine veränderte virtuelle Netzwerkkarte, falsche Firewall-Regeln oder eine unerwartete Gastkonfiguration sein.

Plane deshalb für jede Pilot-VM einen verbindlichen Netztest:

• Erhält oder behält die VM die vorgesehene IP-Konfiguration?
• Funktioniert die Namensauflösung in beide Richtungen?
• Sind benötigte Ports aus den relevanten Netzen erreichbar?
• Stimmen Routing, Firewall-Regeln und Segmentierung?
• Erreichen Monitoring, Backup und Verwaltungszugänge das System?

Bei schwer nachvollziehbaren Verbindungsproblemen ist eine Paketanalyse oft schneller als langes Rätselraten. In unserem Ratgeber „Wireshark lernen: Netzwerkverkehr analysieren“ zeigen wir, wie du Netzwerkverkehr methodisch untersuchst.

Einen Pilotbetrieb mit echten Anforderungen aufsetzen

Ein Pilotbetrieb ist keine Demo-Installation. Er muss zeigen, ob dein Team Proxmox VE unter realistischen Bedingungen betreiben kann. Wähle dafür zwei bis fünf VMs mit überschaubarer Kritikalität, aber unterschiedlichen technischen Anforderungen. Sinnvoll sind beispielsweise ein Linux-Anwendungsserver, ein Windows-Server, eine kleinere Datenbankinstanz und ein System mit mehreren virtuellen Festplatten.

Lege vorab Abnahmekriterien fest. Dazu gehören nicht nur „VM läuft“, sondern auch Performance, Netzwerk, Backup, Restore, Monitoring, Patchen und dokumentierte Betriebsabläufe. Teste ebenso den Ausfall eines Hosts, sofern du bereits einen Cluster aufgebaut hast. Hochverfügbarkeit bedeutet nicht, dass jede Anwendung ohne Unterbrechung weiterläuft. Sie bedeutet, dass die Plattform eine VM nach einem Host-Ausfall auf einem anderen geeigneten Knoten neu starten kann. Die tatsächliche Unterbrechung hängt von Anwendung, Storage und Fehlerfall ab.

Ein Proxmox-Cluster benötigt eine belastbare Quorum-Planung. Bei einer ungeraden Zahl von Cluster-Knoten ist die Mehrheitsbildung in vielen Fällen einfacher umzusetzen. Kleinere Umgebungen können mit einem zusätzlichen Quorum-Gerät arbeiten. Welche Variante passt, hängt von deiner Infrastruktur ab. Wichtig ist: Plane nie nur den Normalbetrieb, sondern auch den Ausfall eines Hosts, einer Netzwerkverbindung oder eines Storage-Pfads.

Backup und Wiederherstellung vor dem ersten Produktivumzug absichern

Ein erfolgreich importierter Server ist noch keine abgesicherte Migration. Du brauchst ein funktionierendes Backup-Konzept auf der Zielplattform und einen nachweislich getesteten Wiederherstellungsprozess.

Kläre, ob du vorhandene Backup-Werkzeuge weiter einsetzen kannst oder ob du ein neues Verfahren etablierst. Entscheidend sind konsistente Sicherungen, klare Aufbewahrungsregeln, ausreichende Backup-Kapazität und ein getrenntes Zielsystem. Ein Backup auf demselben Host schützt nicht vor dessen vollständigem Ausfall.

Teste mindestens diese Szenarien im Pilotbetrieb:

• Wiederherstellung einer vollständigen VM
• Wiederherstellung einzelner Dateien, falls dein Verfahren das unterstützt
• Start einer wiederhergestellten VM in einem isolierten Netzwerk
• Wiederanlauf einer Anwendung mit Datenbankbezug
• Dokumentierte Wiederherstellungszeit unter realistischen Bedingungen

Snapshots sind dabei kein Ersatz für Backups. Sie können für kurze Änderungen oder Updates hilfreich sein, sollten aber nicht über lange Zeit bestehen bleiben und gehören nicht in ein belastbares Wiederanlaufkonzept.

Den Import technisch sauber vorbereiten

Für den Transfer von VMware-VMs gibt es mehrere Wege. Welcher geeignet ist, hängt unter anderem von VM-Größe, Wartungsfenster, Storage und eingesetzten Tools ab. Häufig werden virtuelle Festplatten im VMDK-Format exportiert und in ein Proxmox-kompatibles Format importiert. Danach legst du die virtuelle Maschine mit passender CPU-, Speicher-, Firmware- und Netzwerk-Konfiguration an.

Achte besonders auf diese Punkte:

• Firmware-Modus: BIOS und UEFI müssen zur bisherigen Installation passen.
• Boot-Reihenfolge: Die importierte Systemplatte muss als Startmedium konfiguriert sein.
• Disk-Controller: Für Windows kann der Wechsel auf VirtIO eine vorbereitete Treiberbasis verlangen.
• Netzwerkkarte: Nach dem Wechsel kann das Gastbetriebssystem einen neuen Adapter erkennen.
• MAC-Adressen: Plane Auswirkungen auf DHCP-Reservierungen, Lizenzbindungen und Firewall-Regeln ein.
• Snapshots: Konsolidiere alte VMware-Snapshots vor Export und Import.
• Zeitdienst: Prüfe nach dem Start Zeitsynchronisierung und Domänenanbindung.

Automatisierung spart bei vielen VMs Zeit, ersetzt aber keine Abnahme. Wenn du wiederkehrende Aufgaben standardisieren möchtest, ist „PowerShell lernen: vom Befehl zum Automatisieren“ ein guter Einstieg für Windows-nahe Abläufe.

Cutover mit Rückfalloption durchführen

Der kontrollierte Cutover beginnt erst, wenn der Pilotbetrieb bestanden ist, Backups getestet wurden und alle Beteiligten ihre Aufgaben kennen. Definiere ein konkretes Wartungsfenster, eine Kommunikationsliste und eindeutige Abbruchkriterien.

Eine praxistaugliche Cutover-Checkliste umfasst:

• Aktueller Backup-Stand der Quell-VM ist geprüft
• Anwendung wurde geordnet beendet
• Letzte Datenreplikation oder finaler Export ist abgeschlossen
• Ziel-VM wurde importiert und korrekt konfiguriert
• Netzwerk, DNS, Zertifikate und Firewall-Regeln sind geprüft
• Fachliche Abnahme durch die zuständige Stelle ist erfolgt
• Monitoring und Backup auf dem Zielsystem laufen
• Die VMware-Original-VM bleibt zunächst ausgeschaltet erhalten
• Rückfallentscheidung und Verantwortlichkeiten sind dokumentiert

Lösche die Quell-VM nicht unmittelbar nach dem Umzug. Eine definierte Beobachtungsphase schafft Sicherheit, sofern du Speicher und Betriebsregeln dafür einplanst. Vermeide aber parallelen Produktivbetrieb derselben Serveridentität, insbesondere bei Systemen mit festen IP-Adressen oder Verzeichnisdiensten.

Betriebswissen im Team verankern

Mit dem Plattformwechsel ändern sich auch tägliche Handgriffe: VM bereitstellen, Storage prüfen, Updates einspielen, Clusterzustand überwachen, Backups zurückspielen und Fehler eingrenzen. Plane diese Kompetenzen als Teil des Projekts ein, nicht erst nach dem Cutover.

Bei uns verbinden wir technische Grundlagen mit konkreten Übungen aus dem Administrationsalltag. Passende Seminare und Termine findest du bei uns auf cmt.de. Für die organisatorische Seite größerer Qualifizierungsprojekte bietet dir außerdem unser Beitrag „Weiterbildung fürs IT-Team planen: so geht’s“ praktische Orientierung.

Eine VMware-zu-Proxmox-Migration ist dann erfolgreich, wenn nicht nur die ersten VMs starten. Sie ist erfolgreich, wenn dein Team die neue Umgebung sicher überwacht, wiederherstellt, erweitert und im Störungsfall beherrscht.