VMware-Ablösung: wie das bestehende SAN mit umzieht

/01Der Anlass: Warum die Ablösung jetzt ansteht

Am 11. Dezember 2023 hat Broadcom den Verkauf unbefristeter VMware-Lizenzen sowie die Verlängerung bestehender Support-and-Subscription-Verträge eingestellt. Der offizielle Blogbeitrag der VMware Cloud Foundation fasst die Konsequenz so zusammen: Viele VMware-Softwarelösungen sind „not available for purchase as standalone point solutions" mehr — der Schwerpunkt liegt seither auf den Bündeln VMware Cloud Foundation (VCF) und vSphere Foundation (VVF). Welche Einzeleditionen es daneben gibt, hat Broadcom seitdem mehrfach geändert: gestrichen, zurückgeholt, wieder umgebaut. Ehrlich: Planen Sie nicht mit dem Editionsstand aus einem Artikel, auch nicht aus diesem, sondern mit dem Angebot, das Ihr Händler Ihnen zur nächsten Verlängerung schriftlich macht. Der Anlass für die Prüfung bleibt derselbe — die Dauerlizenz ist weg, und jede Verlängerung ist eine neue Preisverhandlung.

Bestehende Lizenzen wurden dadurch nicht entzogen, wer eine besitzt, darf sie weiter nutzen. Aber jede Erneuerung, jede Erweiterung und jeder Support-Vertrag läuft seither über das neue Modell. Für einen Mittelständler mit auslaufendem Support oder anstehender Hardware-Erneuerung ist das der konkrete Anlass, die Ablösung jetzt zu planen, statt sie vor sich herzuschieben — unabhängig davon, wie die eigene Einschätzung zum Preisvergleich ausfällt.

Der Blogbeitrag der VMware Cloud Foundation listet produktgenau auf, welche Editionen zu welchem Zeitpunkt aus dem Verkauf genommen wurden, statt nur eine pauschale Ankündigung zu machen. Vor der eigenen Zeitplanung lohnt sich deshalb ein Blick in die eigenen Vertragsunterlagen und in diese Liste, nicht die Übernahme einer allgemeinen Fristannahme aus einem Forenbeitrag oder Wiederverkäufer-Flyer — Supportverträge einzelner Editionen laufen zu unterschiedlichen Zeitpunkten aus, und nur der eigene Vertrag zählt für die eigene Terminplanung.

/02Das SAN bleibt, nur der Hypervisor wechselt

Die gute Nachricht zuerst: Ein SAN ist kein VMware-Bestandteil. Es ist ein per Fibre-Channel oder iSCSI angebundenes Storage-Array, das heute VMFS-formatierte LUNs an ESXi-Hosts ausgibt — und morgen genauso gut LVM-formatierte LUNs an Proxmox-Knoten ausgeben kann. Die Hardware, das Firmware-Update-Regime, die Multipath-Verkabelung und in vielen Fällen auch der Supportvertrag mit dem Array-Hersteller bleiben unverändert bestehen. Was wechselt, ist ausschließlich die Schicht, die auf dem LUN ein Dateisystem für VM-Disks anlegt: statt VMFS übernimmt das künftig Shared LVM unter Proxmox.

Das ist kein Nebenaspekt, sondern der Kern des wirtschaftlichen Arguments für diesen Migrationsweg: Ein Array, das vor zwei oder drei Jahren beschafft wurde und noch Jahre Restnutzungsdauer hat, muss bei der Ablösung von VMware nicht zusätzlich ausgetauscht werden. Die Ablösungskosten beschränken sich auf Lizenz, Migrationsaufwand und gegebenenfalls Schulung — nicht auf ein komplett neues Storage-Projekt.

Auch der Cluster selbst muss dafür nicht neu gedacht werden. Ein Proxmox-Cluster mit HA-Absicherung auf Shared-LVM-Storage funktioniert nach denselben Grundprinzipien wie ein VMware-Cluster auf demselben SAN: Quorum zwischen den Knoten, gemeinsamer Zugriff auf dieselben LUNs, automatisches Neustarten von VMs auf einem verbleibenden Knoten bei Hostausfall. Wer diese Mechanik unter VMware bereits im Einsatz hatte, findet unter Proxmox dieselbe Funktionslogik wieder, nur mit anderer Konfigurationssyntax.

/03Der Weg von VMFS zu Shared LVM

Technisch betrachtet sind VMFS und Shared LVM zwei unterschiedliche Cluster-Dateisysteme für denselben Zweck: mehreren Hypervisor-Knoten gleichzeitig sicheren Zugriff auf dieselben LUNs geben. Proxmox bindet ein SAN-LUN als LVM-Storage ein und markiert es als geteilt, damit laut Dokumentation „the backend implements proper cluster-wide locking if the storage is marked as shared in the configuration" — das ist die LVM-Entsprechung dessen, was VMFS mit seinem eigenen Locking-Mechanismus bereits leistet.

# /etc/pve/storage.cfg — SAN-LUN als Shared LVM einbinden
lvm: san01
    vgname shared-san
    shared 1
    content images,rootdir

# Vorhandenes LUN pruefen und Volume Group anlegen
pvesm scan lvm
vgcreate shared-san /dev/mapper/mpatha
pvesm add lvm san01 --vgname shared-san --shared 1

Vor der Volume-Group-Anlage muss Multipath die mehreren Pfade zum selben LUN zu einem einzigen Blockgerät bündeln — sonst sieht Proxmox dasselbe LUN mehrfach und verwechselt Pfade mit eigenständigen Datenträgern:

# /etc/multipath.conf — Pfade zum SAN-LUN buendeln
defaults {
    find_multipaths yes
    user_friendly_names yes
}
multipaths {
    multipath {
        wwid    3600a098038303333795d4a5869675835
        alias   san01-lun0
    }
}

# Nach Aenderung: Dienst neu laden, Status pruefen
systemctl reload multipathd
multipath -ll

Die WWID steht im Management-Werkzeug des Array-Herstellers oder lässt sich über multipath -ll an einem bereits physisch verbundenen, noch nicht konfigurierten Pfad auslesen. Erst wenn alle Pfade in der Ausgabe als active ready running erscheinen, ist das LUN bereit für die Volume-Group-Anlage aus dem vorherigen Schritt — ein Pfad im Zustand failed oder faulty ist an dieser Stelle ein Abbruchkriterium, kein Detail für später.

Die eigentlichen VM-Disks müssen dabei nicht Bit für Bit kopiert werden, wenn sie weiterhin auf demselben physischen Array bleiben sollen — sie werden aus dem VMFS-Datastore ausgelesen und als neue LVM-Volumes auf dasselbe oder ein neues LUN geschrieben, je nachdem, ob das Array für den Parallelbetrieb beider Dateisysteme genug freien Platz hat. In der Praxis ist deshalb meist ein zweites, vorübergehendes LUN oder zumindest ausreichend freier Speicherplatz auf dem Array nötig, damit alte und neue VM-Disks während der Migrationsphase parallel existieren können.

/04Der ESXi-Import-Assistent im Detail

Seit Proxmox VE 8.2 vom 24. April 2024 bringt Proxmox dafür ein eigenes Werkzeug mit. Die offizielle Ankündigung beschreibt es so: ein integrierter Importer, „presented as storage plugin for native integration into the API and web-based user interface", der VM-Importe „as a whole, with most of the original configuration settings mapped to Proxmox VE's configuration model" erlaubt — sowohl von einzelnen ESXi-Hosts als auch über vCenter. Laut Proxmox-Dokumentation wurde der Import „from ESXi version 6.5 up to version 8.0" getestet.

Der Ablauf in der Oberfläche folgt immer demselben Muster:

1. Einen ESXi-Import-Storage unter Datacenter → Storage → Add anlegen und mit den Zugangsdaten des ESXi-Hosts verbinden.
2. Die sichtbaren VMs im Importpanel prüfen — nur VMs auf vom Assistenten unterstützten Datastores erscheinen dort.
3. Eine VM auswählen, Import starten, dabei Zielstorage für die Disks und Netzwerk-Bridge festlegen.
4. Über den Reiter „Advanced" bei Bedarf ISO, NIC-Modell oder einzelne Disks von der Übernahme ausschließen.
5. Die resultierende Konfiguration im Reiter „Resulting Config" gegenprüfen, bevor der eigentliche Transfer beginnt.
6. Die Quell-VM auf dem ESXi-Host herunterfahren und den Import auslösen.
7. Nach dem Import die VM booten und die üblichen Nacharbeiten erledigen: VirtIO-Treiber statt VMware-Tools einspielen, Netzwerkadapter neu zuordnen, Bootreihenfolge prüfen.

Für Handarbeit außerhalb der Oberfläche steht derselbe Mechanismus als Kommandozeilenbefehl bereit:

# Einzelne Disk aus einem ESXi-Export importieren
qm disk import 140 vm-140-disk.vmdk san01 --format qcow2

# Alternative Formate: raw oder vmdk statt qcow2
qm disk import 140 vm-140-disk.vmdk san01 --format raw

Die Wahl des Zielformats ist keine Nebensache. Laut Proxmox-Dokumentation stehen für den Import die drei Formate raw, vmdk und QCOW2 zur Verfügung. Raw liefert die bessere Rohleistung, unterstützt auf Shared LVM aber grundsätzlich keine Snapshots — wer also auf die ohnehin eingeschränkte Snapshot-Fähigkeit von Shared LVM nicht ganz verzichten will, importiert nach qcow2, nicht nach raw. Für Disks, die Thin Provisioning sinnvoll nutzen sollen, ist qcow2 ebenfalls die passendere Wahl, weil raw auf Shared LVM immer als thick-provisioniertes Volume angelegt wird und sofort die volle Kapazität belegt.

Ein paar Einschränkungen sind der Dokumentation ausdrücklich zu entnehmen: vSAN-Datastores nimmt der Assistent nicht an, Datenträgerpfade mit Sonderzeichen wie einem Plus können fehlschlagen, vorhandene Snapshots auf der Quell-VM verlangsamen den Import spürbar, verschlüsselte Disks müssen vor dem Import entschlüsselt werden, und ein Import direkt über vCenter läuft laut Dokumentation langsamer als der direkte Weg über den einzelnen ESXi-Host.

/05Was beim SAN selbst zu prüfen ist, bevor es losgeht

Drei Dinge gehören vor dem ersten Import auf den Prüfstand, nicht danach. Erstens Multipath: Jeder Pfad vom Proxmox-Knoten zum Array muss sauber eingerichtet und aktiv sein, bevor ein LUN produktiv genutzt wird — ein wackelnder Pfad fällt unter VMFS oft erst bei Lastspitzen auf, unter LVM kann er die clusterweite Sperrlogik stören. Zweitens freier Speicherplatz: Solange alte VMFS-Datastores und neue LVM-Volumes parallel existieren, braucht das Array vorübergehend mehr freien Platz als im eingeschwungenen Zielzustand. Drittens die Firmware- und Treiberkompatibilität: Ein Array, dessen Treiber für den bisherigen ESXi-Host qualifiziert war, braucht nicht zwingend denselben Qualifikationsstand für den Linux-Kernel unter Proxmox — ein kurzer Blick in die Kompatibilitätsliste des Herstellers spart im Zweifel ein Wochenende Fehlersuche.

/06Die richtige Reihenfolge: Pilot, Welle, Rest

Ein harter Cutover an einem einzigen Wochenende ist bei einer SAN-gestützten Migration selten nötig und meistens auch nicht die klügste Wahl. Bewährt hat sich eine dreistufige Reihenfolge: Zuerst eine einzelne, unkritische Pilot-VM importieren und über mindestens einen vollständigen Arbeitszyklus — inklusive Backup, Patch-Fenster und, wo relevant, Live-Migration — beobachten. Danach eine erste Welle aus VMs, deren Ausfall verkraftbar wäre, migrieren und das Verhalten unter echter Last prüfen. Erst danach folgt der Rest der Umgebung, idealerweise nach Anwendungsgruppen gestaffelt, nicht nach Alphabet.

Diese Reihenfolge kostet mehr Kalenderzeit als ein einziges großes Wartungsfenster, aber sie begrenzt den Schaden eines unentdeckten Problems auf eine kleine Zahl von VMs statt auf die gesamte Umgebung. Für ein SAN, das ohnehin weiterläuft, ist das kein zusätzliches Risiko — das Array selbst ändert sich während der gesamten Migration nicht, nur die Hypervisor-Zuordnung der einzelnen LUNs und Disks verschiebt sich schrittweise.

Was bei der Pilot-VM konkret zu prüfen ist, sollte vorher feststehen, nicht erst während des Tests entschieden werden: bootet das System sauber, meldet sich das Betriebssystem im Netz mit der erwarteten Bridge, laufen die eingebundenen Anwendungsdienste ohne Fehler an, und liefert ein kurzer Schreib- und Lesetest auf der importierten Disk eine Leistung, die zur bisherigen VMFS-Erfahrung passt. Erst wenn diese vier Punkte für die Pilot-VM bestätigt sind, ist der nächste Schritt — die erste größere Welle — an der Reihe. Eine Checkliste, die vorher auf Papier steht, verhindert, dass ein Team im Eifer des Gefechts einen der Punkte überspringt, weil „es ja eilig ist".

Welche VM in welche Welle gehört, entscheidet sich an drei Fragen, nicht am Alphabet oder an der VM-ID: Wie kritisch ist der Dienst für den laufenden Geschäftsbetrieb, wie gut lässt sich ein Ausfallfenster für ihn überhaupt noch planen, und wie ähnlich ist seine Konfiguration — Betriebssystem, Treiber, Netzanbindung — zur bereits erfolgreich migrierten Pilot-VM. Ein Testsystem oder ein internes Tool mit ähnlichem Betriebssystem wie die Pilot-VM gehört typischerweise in die erste Welle; ein Datenbankserver mit eigener Lizenzbindung oder ein System mit ungewöhnlicher Hardware-Passthrough-Konfiguration gehört eher in eine spätere, besser vorbereitete Welle. Wer diese Zuordnung vorab auf einer einzigen Seite dokumentiert, kann sie bei Rückfragen aus der Fachabteilung in Minuten statt in einer erneuten, zeitraubenden Analyse beantworten — gerade dann, wenn die Fachabteilung mitten im Tagesgeschäft nachfragt und keine Zeit für eine lange Erklärung hat.

/07Der Rückfallplan, falls etwas nicht rundläuft

Ein Rückfallplan ist keine Formsache, sondern Teil der Migrationsplanung selbst. Solange die Quell-VM auf dem ESXi-Host vor dem Import lediglich heruntergefahren, nicht gelöscht wird, bleibt sie als Rücksprungpunkt erhalten — der Import-Assistent liest die Daten, verändert aber die ursprüngliche VMFS-Kopie nicht.

Erst wenn die importierte VM unter Proxmox produktiv läuft und über mindestens einen vollständigen Betriebszyklus bestätigt ist, sollte die alte ESXi-VM entfernt und der zugehörige VMFS-Speicherplatz freigegeben werden.

Für den Fall, dass während der Migrationsphase der VMware-Support ausläuft, bevor die letzte VM migriert ist, lohnt sich eine bewusste Priorisierung: Kritische, noch nicht migrierte Systeme zuerst, unkritische Restbestände zuletzt. Ein zusätzliches Disaster-Recovery-Backup der noch nicht migrierten VMs vor dem eigentlichen Importversuch — unabhängig vom ohnehin laufenden Produktivbackup — ist der günstigste Rückfallpunkt, den es in dieser Phase gibt.

/08Wo es hakt

• vSAN-Umgebungen fallen aus dem Raster: Der Import-Assistent nimmt laut Dokumentation keine vSAN-Datastores an — wer auf hyperkonvergentem VMware-Storage statt auf einem externen Array liegt, braucht einen anderen, aufwendigeren Migrationsweg.
• Snapshots auf der Quell-VM bremsen aus: Laut Dokumentation verlangsamen vorhandene ESXi-Snapshots den Import spürbar — sie sollten vor dem Import konsolidiert werden, nicht während.
• vCenter-Importe sind langsamer als Direktimporte: Wer viele VMs über vCenter statt direkt über den jeweiligen ESXi-Host importiert, nimmt laut Dokumentation einen Geschwindigkeitsnachteil in Kauf.
• Verschlüsselte Disks brauchen einen Zwischenschritt: Sie müssen vor dem Import entschlüsselt werden, was zusätzliche Zeit und unter Umständen zusätzlichen Speicherplatz kostet.
• Große Disks verlängern den Transfer spürbar: Der Import kopiert die komplette Disk über das Netz zwischen ESXi-Host und Proxmox-Knoten — bei mehreren hundert Gigabyte je VM ist die Netzbandbreite zwischen beiden der limitierende Faktor, nicht die Importsoftware selbst.

/09Wann sich die Migration jetzt lohnt — und wann abwarten die bessere Wahl ist

Die Migration jetzt anzugehen lohnt sich, wenn der bestehende VMware-Support in absehbarer Zeit ausläuft, das Array noch Restnutzungsdauer hat und ein SAN-Austausch ohnehin nicht geplant ist, oder wenn ein ohnehin anstehendes Wartungsfenster für einen strukturierten Pilotlauf genutzt werden kann. Abwarten kann die bessere Wahl sein, wenn der bestehende Supportvertrag noch länger läuft, parallel größere andere Projekte laufen, die keine zusätzliche Komplexität vertragen, oder wenn ohnehin in naher Zukunft ein neues Array ansteht — dann lohnt sich eher eine kombinierte Planung aus Storage- und Hypervisor-Wechsel in einem Zug.

Managed durch uns heißt bei dieser Migration konkret: Wir übernehmen Monitoring von SAN, Multipath und Proxmox-Cluster während und nach der Migration, planen Patch-Fenster statt Überraschungsupdates, stehen bei kritischen Vorfällen in Rufbereitschaft zur Verfügung, und betreiben die Umgebung aus dem Rechenzentrum Coburg mit Ausweichstandort Neustadt, ISO/IEC 27001:2024-zertifiziert. Seit 2010 begleiten wir Mittelständler durch genau solche Migrationen — die Reihenfolge und der Rückfallplan aus diesem Artikel sind keine Theorie, sondern unsere übliche Vorgehensweise.

/10Häufige Fragen