VMware vSphere zu Proxmox VE
VMware-Exit nach Proxmox: Migration planen und umsetzen
Ihre virtuellen Maschinen wandern in Wellen auf Proxmox, jede mit Pilot, Abnahmetest und festgelegtem Rückfallweg. Kein Knopfdruck, sondern ein Projekt, das wir mit Ihnen planen und umsetzen.
- Importwege je VM-Klasse, im Pilot getestet
- Umschaltung in Wellen mit Rückfallweg
- Übergabe an Ihr Team oder in den Betrieb
01Ausgangslage
Warum der VMware-Ausstieg ein Projekt mit Entscheidungen ist
SKAFFON begleitet Unternehmen beim Umzug virtueller Maschinen von VMware vSphere nach Proxmox VE: von der Bestandsaufnahme über Zielarchitektur und Pilot bis zur gestaffelten Umschaltung, Abnahme und Übergabe in den Betrieb. Die Seite richtet sich an IT-Leitung und Infrastrukturverantwortliche, die einen Ausstieg prüfen oder beschlossen haben und einen belastbaren Projektplan brauchen.
Typische Auslöser sind Lizenz- und Vertragsänderungen bei der bestehenden Plattform, Kostendruck, der Wunsch nach Open Source oder Anforderungen an Herstellerunabhängigkeit. Ob Proxmox das richtige Ziel ist, klärt zuerst der Vergleich der Alternativen: siehe Souveräne Cloud und Cloud-Plattformen. Proxmox ist eine von mehreren Möglichkeiten.
02Überblick
Sechs Stationen vom Inventar bis zur Abnahme
Jede Station liefert ein Artefakt, das Sie prüfen und freigeben. Läuft eine Welle schlecht, geht es zurück zum Mapping, nicht in den Blindflug.
03Runbook
Runbook in sieben Schritten
Die Gliederung, nach der wir ein VMware-Exit-Projekt aufsetzen. Reihenfolge und Tiefe richten sich nach Ihrer Umgebung.
- 01
Inventar und Abhängigkeiten
Ergebnis: VM-ListeAlle VMs mit CPU, RAM, Datenträgern, Netzwerken, Snapshots, Betriebssystem, Anwendung, Verantwortlichen, Wartungsfenster und Abhängigkeiten. Automatisierte Erfassung liefert die Rohdaten; die Einordnung (migrieren, ersetzen, abschalten, nicht migrierbar) entscheiden Menschen mit Fachbereichen.
- 02
Netzwerk- und Storage-Mapping
Ergebnis: Mapping-TabellePortgruppen und VLANs auf Bridges und SDN-Zonen abbilden, Datastores auf Zielspeicher. Besonderheiten wie vSAN-Datenträger, Verschlüsselung oder Raw Device Mappings klären wir gesondert.
- 03
Dimensionierung des Zielclusters
Ergebnis: Sizing-DokumentRechenkapazität inklusive Reserve für den Ausfall eines Knotens. Bei Ceph mindestens drei Knoten, dediziertes Netz von mindestens 10 Gbit/s, HBA statt RAID-Controller und Speicher für die Rekonstruktion nach Ausfällen (Ceph-Hinweise von Proxmox).
- 04
Pilot
Ergebnis: PilotberichtEine Handvoll repräsentativer, unkritischer VMs läuft über die vorgesehenen Importwege. Gemessen werden Dauer, Ausfallzeit, Treiberprobleme sowie Backup und Restore.
- 05
Umschaltung in Wellen
Ergebnis: Cutover-PlanGruppen von VMs mit gemeinsamen Abhängigkeiten. Je Welle gibt es ein Wartungsfenster, einen Abnahmetest und einen definierten Rückfallweg.
- 06
Rückfall
Rollback pro WelleSolange die Quell-VM unverändert vorliegt und nicht gestartet wurde, ist der Rückweg das Wiederanschalten der Quelle. Nach produktivem Schreiben auf dem Ziel müssten Daten zurückgeführt werden; deshalb legt der Cutover-Plan je VM-Klasse fest, bis wann zurückgerollt werden kann.
- 07
Abnahme und Übergabe
Ergebnis: AbnahmeprotokollFunktionstests der Anwendungen, Backup-Wiederherstellung, Monitoring, Dokumentation, Einweisung. Der Betrieb kann bei Ihnen bleiben oder an uns gehen: Managed Services. Setzt Ihr Backup auf eine andere Lösung als Proxmox Backup Server, prüfen wir die Kompatibilität mit Ihrer Proxmox-Version vor der Entscheidung anhand der Herstellerdokumentation, ebenso Veeam, falls es im Einsatz ist.
04Architektur
Was aus Ihrer vSphere-Landschaft auf Proxmox wird
Es gibt kein direktes Gegenstück zu jedem vSphere-Feature. Vor der Migration prüfen wir pro Funktion, ob sie in Proxmox eine Entsprechung hat, ersetzt werden muss oder entfällt. Dazu gehören Ressourcenpools, verteilte Switches, Lastverteilung, Snapshots, Backup-Integration und Automatisierung.
- Quelle: VMware vSphere mit ESXi-Hosts, optional vCenter, Datastores (VMFS, NFS, vSAN), Distributed Switches, Backup-Lösung.
- Ziel: Proxmox-VE-Cluster mit KVM, Hochverfügbarkeit, Storage (lokal, ZFS, externer Speicher oder Ceph), Netzwerk mit VLANs und Bridges.
- Backup: Proxmox Backup Server oder eine andere freigegebene Backup-Lösung.
05Technik
Vier Importwege und was jeder kostet
Proxmox bietet mehrere Wege, die laut Migrationsanleitung für unterschiedliche Fälle taugen (Migrate to Proxmox VE). Wir planen den Weg je VM-Klasse und testen ihn im Pilot, statt einen Weg pauschal zu versprechen.
| Weg | Voraussetzung und Ablauf | Dokumentierte Einschränkung |
|---|---|---|
| ESXi-Import-Assistent | Proxmox VE 8 oder neuer. ESXi-Host als Importquelle einbinden, VM auswählen, importieren. Laut Dokumentation getestet mit ESXi 6.5 bis 8.0. | Über vCenter statt direkt über den ESXi-Host sinkt die Geschwindigkeit laut Dokumentation erheblich. |
| Live-Import | Die VM startet bereits während der Datenübernahme im Hintergrund. | Die Quell-VM bleibt aus, es bleibt also eine Ausfallzeit. Zu Beginn ist die I/O langsamer; bei einem Fehlschlag gehen alle seit dem Start geschriebenen Daten verloren. |
| OVF/OVA-Import | qm importovf nach Export mit ovftool. | Siehe Grenzen der Datenträger unten. |
| Disk-Import | qm disk import für VMDK-Dateien. | Siehe Grenzen der Datenträger unten. |
Die Grenzen der Datenträger gelten für den Import-Assistenten; Details im nächsten Abschnitt.
06Bekannte Grenzen
Wo der Import-Assistent an Grenzen stößt
Diese Punkte sind in der Proxmox-Dokumentation beschrieben. Wir finden sie im Inventar, bevor sie im Wartungsfenster auffallen.
-
vSAN-Datenträger
Datenträger auf VMware vSAN lassen sich nicht importieren.
-
Verschlüsselte Datenträger
Verschlüsselte VM-Datenträger, etwa per Storage Policy, lassen sich ebenfalls nicht importieren.
-
VMs mit Snapshots
Der Import ist deutlich langsamer. Wir konsolidieren Snapshots vorher, soweit fachlich möglich.
-
vTPM-Status
Der vTPM-Status lässt sich derzeit nicht übernehmen.
-
Massenimporte
Die Dokumentation empfiehlt, nur etwa vier Datenträger gleichzeitig zu übertragen.
Quell-VM und Ziel-VM laufen nie gleichzeitig
Laufen beide gleichzeitig, können Datenträger beschädigt werden. Der Cutover-Plan legt deshalb für jede VM fest, wann die Quelle ausgeschaltet bleibt und bis wann sie als Rückfallweg unverändert vorliegt.
07Vor dem Umzug
Gastsysteme vor dem Import vorbereiten
Diese Schritte erledigen wir je VM-Klasse im Pilot und danach in den Wellen. Windows startet nach dem Import in der Regel nur von IDE oder SATA, bis VirtIO-Treiber eingerichtet sind.
- Gast-Tools des Quellsystems entfernen
- Netzwerkkonfiguration sichern
- MAC-abhängige DHCP-Reservierungen anpassen
- Boot-Modus (BIOS oder UEFI) passend wählen
- VirtIO-Treiber installieren
08Aufwand
Warum wir den Aufwand aus dem Pilot ableiten, nicht aus einer VM-Pauschale
Eine Pauschale je VM taugt nicht als Grundlage, weil Datenmenge, Datenträgerart, Betriebssystem, Ausfallfenster und Anwendungsabhängigkeiten den Aufwand stärker bestimmen als die bloße Zahl der Maschinen. Deshalb messen wir ihn in Ihrer Umgebung:
- Bestandsaufnahme (Assessment). Inventar, Abhängigkeiten und VM-Klassen. Ergebnis ist eine erste Einordnung mit offenen Annahmen, noch keine Zusage.
- Pilot. Repräsentative, unkritische VMs aus den wichtigsten Klassen laufen über die vorgesehenen Importwege.
- Hochrechnung aus dem Pilot. Aus den gemessenen Werten je VM-Klasse berechnen wir Aufwand und Dauer der Wellen. Klassen, die der Pilot nicht abdeckt, weisen wir als Unsicherheit aus.
- Wellenplanung. Gruppen mit gemeinsamen Abhängigkeiten, Wartungsfenstern und Rückfallweg; das Angebot für die Umsetzung baut darauf auf. Die Umschaltung selbst folgt dem Runbook oben.
- Begleitung nach der Umschaltung. Erhöhte Aufmerksamkeit für Auffälligkeiten bei Leistung, Treibern, Backup und Monitoring. Umfang und Dauer legen wir im Angebot fest.
- Weichen die Werte in den Wellen vom Pilot ab, passen wir Planung und Schätzung mit Ihnen an, statt die Abweichung zu verdecken.
09Angebot
Acht Treiber, aus denen Ihr Angebot entsteht
Der Aufwand richtet sich nach diesen Treibern; das Angebot entsteht nach der Bestandsaufnahme und legt Umfang, Annahmen, Abgrenzungen, Mitwirkungspflichten und Preismodell fest.
| Treiber | Warum er zählt |
|---|---|
| Anzahl und Heterogenität der VMs | Jede Klasse (Betriebssystem, Boot-Modus, Treiber) braucht ein getestetes Vorgehen |
| Datenmenge und Netzanbindung | Bestimmt Importdauer und Länge der Ausfallfenster |
| Datenträgerart (vSAN, Verschlüsselung, Snapshots, RDM) | Teilweise nicht direkt importierbar oder deutlich langsamer |
| Zulässige Ausfallzeit je Anwendung | Entscheidet über Live-Import, Disk-Wiederverwendung oder Wartungsfenster |
| Zielstorage (Ceph neu aufbauen oder vorhandenen Speicher anbinden) | Neuaufbau erfordert Beschaffung, Netzwerk und Tests |
| Netzwerkkomplexität (VLANs, verteilte Switches, Firewalls) | Mapping und Tests wachsen mit der Zahl der Segmente |
| Backup, Monitoring, Automatisierung | Müssen für die neue Plattform angebunden oder ersetzt werden |
| Anforderungen an Hochverfügbarkeit und Dokumentation | Mehr Ausfalltests, mehr Übergabeartefakte |
10Risiken
Fünf Risiken, die wir vor der ersten Welle klären
- Anwendungen mit Herstellerfreigabe nur für VMware: Support für Proxmox beim Softwarehersteller klären.
- Lizenzbindung an Hardware oder Hypervisor-ID: kann Neuaktivierung erfordern.
- Treiberprobleme bei Windows nach der Umstellung auf VirtIO.
- Zu knappe Kapazität im Zielcluster: Der Ausfall eines Knotens belastet die übrigen.
- Laufende Vertragsfristen bei der bisherigen Plattform bestimmen das Zeitfenster. Das ist Ihre Entscheidung und gehört in den Projektplan.
11Sicherheit
Zugriff auf ESXi, vCenter und Proxmox: benannt, begrenzt, befristet
Der Zugriff erfolgt über benannte Konten mit minimalen Rechten und wird nach Projektende entzogen. Verbindungen zwischen Quell- und Zielumgebung laufen verschlüsselt und nur im vereinbarten Netzbereich. Identität, Monitoring und Backup binden wir an Ihre bestehenden Systeme an.
12
Passt dieses Vorgehen zu Ihrem VMware-Exit?
Das passt
- Sie prüfen einen Ausstieg aus VMware oder haben ihn beschlossen und brauchen einen belastbaren Projektplan.
- Sie akzeptieren Wartungsfenster je Anwendung statt eines Versprechens von Ausfallfreiheit.
Das passt nicht
- Sie wollen eine automatische Migration ohne Planung oder Tests.
- Ihre Anwendungen sind vom Hersteller nur auf VMware freigegeben, und es gibt keine Ausnahme.
- Sie möchten eine reine Beratung zur Wahl der Zielplattform ohne Umsetzung: dann beginnen Sie bei der Cloud-Beratung.
- Das Ziel ist kein Proxmox, sondern Kubernetes oder eine Cloud: siehe Cloud-Migration und Kubernetes-Beratung.
13
Häufige Fragen
Gibt es eine Migration ohne Ausfallzeit?
Der Live-Import startet die VM während der Datenübernahme, aber die Quell-VM ist dafür abgeschaltet; eine Ausfallzeit bleibt, und bei einem Fehlschlag gehen Daten seit Beginn verloren. Wir versprechen keine Ausfallfreiheit, sondern planen Fenster je Anwendung.
Muss die Quelle vCenter sein?
Nein. Direkter Import vom ESXi-Host ist laut Dokumentation deutlich schneller.
Was ist mit Snapshots?
Sie bremsen den Import deutlich. Wir konsolidieren sie vorher, soweit fachlich möglich, und planen die Datenmenge in der Wellenplanung ein.
14
Plattform, Betrieb und Alternativen
-
Proxmox Support
Dauerhafter Plattformbetrieb nach der Migration.
-
Managed Services
Betrieb der neuen Plattform durch SKAFFON.
-
IT-Lösungen
Überblick aller Lösungen.
Schicken Sie uns die Eckdaten Ihrer VMware-Umgebung
Anzahl der VMs, Datenträgerarten, Ausfallfenster und Zielplattform genügen für den Einstieg.