Proxmox-Cluster mit Fibre-Channel-SAN — VMware & Hyper-V migrieren ohne Shared-Storage-Kompromiss

Nicht der Hypervisor ist das Problem — das SAN ist die Frage

Seit der Broadcom-Übernahme von VMware ist die Migration weg von vSphere für viele Mittelständler keine Glaubensfrage mehr, sondern eine betriebswirtschaftliche. Die technische Entscheidung für Proxmox VE als VMware-Alternative ist meist schnell getroffen. Was die Projekte ins Stocken bringt, ist fast immer derselbe Satz aus der Infrastruktur-Runde: „Schön, aber wir haben ein Fibre-Channel-SAN mit VMFS. Was passiert damit?"

Diese Sorge ist berechtigt — und in der Praxis lösbar. Ein gut dimensioniertes FC-SAN ist eine Investition über fünf bis acht Jahre; niemand wirft es weg, weil der Hypervisor wechselt. Die gute Nachricht: Proxmox VE betreibt Ihr bestehendes SAN weiter, mit Live Migration und Hochverfügbarkeit. Die ehrliche Nachricht: Der Weg dorthin ist technisch anders als unter VMware, und an einer Stelle — den Snapshots — müssen Sie eine bewusste Architekturentscheidung treffen. Genau darum geht es in diesem Artikel.

• SAN bleibt, Live Migration bleibt
• Multipath + Shared LVM (thick)
• ESXi-Import-Wizard ab PVE 8.2
• Snapshots: bewusste Entscheidung
• VMware-Lizenz entfällt komplett
• HA mit ≥3 Knoten + Fencing

Warum jetzt: Die Broadcom-Lizenzlage 2026

Der Auslöser für die Migrationswelle ist bekannt, lohnt aber die nüchterne Zusammenfassung — weil sie die wirtschaftliche Grundlage der Entscheidung liefert:

• Keine Perpetual-Lizenzen mehr. Broadcom verkauft seit 2024 keine unbefristeten VMware-Lizenzen; seit April 2025 sind auch keine Verlängerungen der Support-Verträge für Perpetual-Lizenzen mehr erhältlich. Es gilt das Abomodell.
• Konsolidierte Bundles. Das Portfolio besteht aus vier Stufen: VMware Cloud Foundation (VCF), vSphere Foundation (VVF), vSphere Standard und vSphere Enterprise Plus. Funktionen, die früher einzeln lizenzierbar waren, stecken nun in Paketen.
• Mindestabnahmen und Kern-Lizenzierung. Im April 2025 kündigte Broadcom eine Mindestabnahme von 72 Kernen pro Bestellung an — nach massivem Kundenprotest teils zurückgenommen, die Stoßrichtung größerer Mindestvolumina blieb.
• Preissprünge. Berichtete Steigerungen reichen je nach Vorvertrag und Rabattlage von rund 150 % bis weit über 1.000 %; erste VCF-Angebote lagen häufig beim Zwei- bis Fünffachen der bisherigen Perpetual-plus-Support-Kosten.
• Auslaufende Fristen. Der allgemeine Support für vSphere 7 endete am 2. Oktober 2025; bestehende Perpetual-Support-Verträge laufen spätestens bis Oktober 2027 aus. Danach bleibt nur: zu Neukonditionen abonnieren — oder migrieren.

Für ein typisches KMU mit zwei bis vier Hosts kann das den Unterschied zwischen einem niedrigen vierstelligen Wartungsbetrag und einer fünfstelligen Jahres-Subscription bedeuten. Eine ausführliche Gegenüberstellung der Optionen finden Sie in unserem Beitrag VMware-Alternativen 2026.

VMFS gibt es bei Proxmox nicht — und das ist okay

Der wichtigste konzeptionelle Unterschied vorab, weil daran die meisten Missverständnisse hängen: Proxmox hat kein direktes Gegenstück zu VMFS.

VMware legt mit VMFS ein clusterfähiges Dateisystem direkt auf das LUN. Mehrere ESXi-Hosts schreiben gleichzeitig hinein; VMFS regelt die Sperren auf Dateisystemebene. Das ist elegant, aber proprietär.

Proxmox geht den Linux-Weg: Auf dem gemeinsamen LUN liegt eine LVM-Volume-Group, und jede VM-Disk ist ein eigenes Logical Volume (Block-Device, kein File). Die Koordination — welcher Knoten welche VM und damit welches LV besitzt — übernimmt nicht ein Cluster-Dateisystem, sondern die Proxmox-Cluster-Datenbank (pmxcfs, repliziert über Corosync). Zu jedem Zeitpunkt aktiviert nur genau ein Knoten ein bestimmtes Logical Volume. Das verhindert Doppelzugriffe ganz ohne Cluster-Dateisystem.

Das Resultat ist funktional gleichwertig zu VMFS auf FC: gemeinsamer Block-Speicher, den alle Knoten sehen, mit Live Migration und HA. Nur die Mechanik darunter ist eine andere — und sie bringt die eine Einschränkung mit, die wir weiter unten ehrlich behandeln: native Snapshots.

Schritt 1: Multipath — das SAN-LUN sauber einbinden

Bevor LVM ins Spiel kommt, muss jedes LUN über alle redundanten FC-Pfade als ein Gerät erscheinen. Das ist die Aufgabe von multipathd. In einem ordentlichen SAN-Setup hat jeder Knoten zwei HBA-Ports an zwei getrennten Fabrics (A/B); ohne Multipath sähe Linux dasselbe LUN doppelt — ein Rezept für Datenkorruption.

Voraussetzung im Fabric: ein Zoning, das alle Proxmox-Knoten mit dem SAN-Target verbindet, und eine LUN-Maskierung, die dasselbe LUN an alle Hosts ausreicht. Das geschieht auf SAN- und Switch-Seite, identisch für jeden Knoten.

# Pakete (das -boot-Paket bindet Multipath früh in die initramfs ein)
apt install multipath-tools multipath-tools-boot

# WWID des LUN ermitteln
/lib/udev/scsi_id -g -u -d /dev/sdc

# Multipath-Status: ein LUN, mehrere Pfade
multipath -ll

Eine minimale, gut funktionierende /etc/multipath.conf sieht so aus — die blacklist schließt lokale Platten aus, die wwids werden gezielt freigegeben:

defaults {
    user_friendly_names yes
    find_multipaths     yes
}
blacklist {
    devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"
}
# Hersteller-Profile bringt multipath-tools meist schon mit;
# bei Bedarf device { vendor/product/path_grouping_policy } ergänzen.

Ergebnis: Das LUN erscheint als /dev/mapper/mpath0 (oder ein WWID-Alias) — und nur dieses Device fassen wir ab jetzt an, nie die /dev/sdX direkt.

Schritt 2: Shared LVM anlegen — thick, niemals thin

Jetzt kommt der gemeinsame Speicher. Auf genau einem Knoten wird das Physical Volume und die Volume Group erzeugt; die anderen Knoten sehen die VG automatisch, weil sie auf dasselbe LUN schauen.

pvcreate /dev/mapper/mpath0
vgcreate shared-san /dev/mapper/mpath0

Anschließend wird der Storage in Proxmox bekannt gemacht — entweder per GUI (Rechenzentrum → Storage → Hinzufügen → LVM) oder direkt in /etc/pve/storage.cfg. Entscheidend ist das Flag shared 1: Es teilt dem Cluster mit, dass dieses LVM auf allen Knoten denselben Inhalt zeigt.

lvm: shared-san
    vgname shared-san
    shared 1
    content images,rootdir

Thick provisioniertes Shared LVM bedeutet: Jede VM-Disk belegt ihren vollen Platz sofort. Das kostet etwas Speichereffizienz, gibt aber maximale Stabilität und ist der bewährte Standardweg für FC-SANs unter Proxmox.

Schritt 3: Cluster, Live Migration und Hochverfügbarkeit

Mit gemeinsamem Speicher ist der Rest fast geschenkt — weil die Daten bereits überall liegen.

Live Migration: schneller als ohne SAN

Weil die VM-Disk als Logical Volume auf dem geteilten LUN liegt, muss bei einer Live Migration nur der RAM-Zustand über das Netzwerk wandern — die Platte bleibt, wo sie ist. Eine VM mit 100 GB Disk und 8 GB RAM migriert in Sekunden statt Minuten. Das ist exakt das Verhalten, das vMotion-Nutzer gewohnt sind.

Quorum: warum drei Knoten

Ein Proxmox-Cluster braucht für sichere Entscheidungen ein Quorum. Mit zwei Knoten gibt es bei Netzwerktrennung keine Mehrheit (Split-Brain-Gefahr). Lösung: mindestens drei Knoten — oder zwei Knoten plus ein QDevice (ein kleiner Tie-Breaker, etwa ein Raspberry Pi oder eine VM außerhalb des Clusters).

HA-Stack und Fencing

Der Proxmox-HA-Manager startet VMs automatisch auf einem gesunden Knoten neu, wenn ein Host ausfällt. Damit das sicher ist, muss ein abgestürzter Knoten zuverlässig „eingezäunt" werden (Fencing), bevor seine VMs woanders starten — sonst griffen zwei Knoten auf dasselbe LV zu. Proxmox nutzt dafür einen Hardware-Watchdog: Verliert ein Knoten das Quorum, setzt der Watchdog ihn nach wenigen Sekunden hart zurück. Erst danach übernimmt die HA-Gruppe.

Der wunde Punkt: Snapshots auf Shared SAN

Hier ist die ehrliche Stelle. Klassisches thick-provisioniertes Shared LVM kann von Haus aus keine VM-Snapshots — anders als VMFS, wo Snapshots selbstverständlich sind. Das war jahrelang das stärkste Argument der VMware-Verteidiger. 2026 ist die Lage differenzierter. Es gibt drei tragfähige Wege:

Weg A — Snapshots auf SAN-Ebene (Hardware-Snapshots)

Praktisch jedes Enterprise-SAN (Dell PowerStore/Unity, HPE 3PAR/Primera/Alletra, NetApp, Pure) kann LUN- oder Volume-Snapshots selbst — performant, hardwarebeschleunigt, oft mit Replikation gekoppelt. Für viele Bestandskunden ist das der pragmatischste Weg: Die Snapshot-Logik bleibt dort, wo sie schon immer lief, und das Array macht, wofür es gekauft wurde. Nachteil: Snapshots sind dann LUN-granular, nicht pro VM aus der Proxmox-GUI heraus.

Weg B — QCOW2-Snapshot-Ketten auf thick LVM (Proxmox VE 9)

Mit Proxmox VE 9 (2025) kam die direkte Antwort auf genau diese Lücke: Snapshots als QCOW2-Volume-Ketten auf thick LVM. Vereinfacht legt Proxmox dabei pro Snapshot ein neues, voll dimensioniertes Logical Volume an, platziert darauf ein QCOW2-Overlay und nutzt das vorherige Image als Backing-File — eine lineare Kette von Schichten. Damit werden Snapshots und Rollback auch auf rohen FC-LUNs möglich.

Die Einordnung dazu, klar gesagt:

• Die Funktion ist als Technologie-Vorschau einzustufen — für unternehmenskritische Produktion (noch) mit Vorsicht zu genießen.
• QCOW2 auf Block-Storage kostet Performance: je nach Disk-Größe und Zugriffsmuster sind spürbare Einbußen gegenüber rohen Volumes zu erwarten, mit jedem zusätzlichen Snapshot in der Kette wächst der Overhead.
• Es muss für Basis- und Snapshot-Image jeweils voller Platz reserviert werden — die Speichereffizienz leidet.
• Proxmox VE 9.1 (November 2025) hat mit der Ablage des TPM-Zustands im QCOW2-Format eine frühere Einschränkung für Windows-VMs mit virtuellem TPM adressiert.

Weg C — Proxmox Backup Server als Point-in-Time-Sicherung

In vielen Fällen wird der „Snapshot" eigentlich als schnelle Rücksprungmarke vor Updates oder als Sicherung gebraucht. Genau das leistet der Proxmox Backup Server (PBS): inkrementelle, deduplizierte Sicherungen mit minutengenauer Wiederherstellung und „Live Restore". Für viele KMU-Workloads ersetzt ein straff getakteter PBS-Plan den klassischen VMFS-Snapshot vollständig — und schützt zusätzlich vor dem, wogegen ein Snapshot nichts ausrichtet: Ransomware und Hardware-Verlust.

Storage-Optionen im direkten Vergleich

Die Botschaft der Tabelle: In den drei Eigenschaften, die den Cluster-Betrieb ausmachen — Live Migration, HA, SAN-Weiterverwendung — ist Proxmox auf Augenhöhe. Der einzige echte Kompromiss betrifft native Snapshots, und der ist über SAN-Hardware oder PBS sauber auflösbar.

Migration von VMware ESXi

Seit Proxmox VE 8.2 (2024) gibt es einen integrierten ESXi-Import-Wizard, der die Migration drastisch vereinfacht. Statt Disks manuell zu exportieren, binden Sie den ESXi-Host als Storage-Quelle ein und importieren VMs samt Konfiguration weitgehend automatisch.

• ESXi-Host als Storage einbinden In Proxmox unter Rechenzentrum → Storage → Hinzufügen → ESXi die Verbindungsdaten des ESXi- bzw. vCenter-Hosts hinterlegen. Alle VMs des Hosts werden sichtbar.
• VM auswählen und importieren Der Wizard übernimmt CPU, RAM, Disks und Netzwerkkonfiguration ins Proxmox-Modell. Disks landen direkt auf dem Ziel-Storage — Ihrem neuen Shared-LVM-SAN.
• VirtIO-Treiber bereitstellen Vor oder nach dem Import die VirtIO-Treiber einspielen (Windows) bzw. sicherstellen, dass das Linux-Gast-Image VirtIO kennt — für maximale I/O-Performance auf KVM.
• Boot-Modus prüfen UEFI vs. BIOS und SecureBoot-Einstellungen angleichen, damit der Gast nach dem Wechsel sauber bootet.
• Testen, dann umschalten VM isoliert testen, Dienste prüfen, erst dann den Produktiv-Cut-over. Die Ausfallzeit pro VM beschränkt sich auf den finalen Sync.

Getestet ist der Import von ESXi 6.5 bis 8.0. Für Disks, die bereits exportiert vorliegen, bleibt der universelle Weg über qm importdisk bzw. OVF/OVA jederzeit nutzbar. Wie ein solches Projekt in der Praxis aussieht, zeigt unsere Case Study: Maschinenbauer spart 85 % mit Proxmox.

Migration von Hyper-V

Für Microsoft Hyper-V gibt es keinen automatischen Wizard — der Weg führt über die virtuellen Festplatten. Das ist gut beherrschbar, erfordert aber mehr Handarbeit pro VM.

• Gast vorbereiten In der laufenden Windows-VM die Hyper-V-Integrationsdienste deinstallieren und die VirtIO-Treiber bereitstellen, damit der Gast nach dem Wechsel die KVM-Geräte erkennt. Bei Linux-Gästen analog die Hyper-V-Module entfernen.
• VHDX exportieren Die VM in Hyper-V herunterfahren und die VHDX-Datei(en) bereitstellen.
• Disk konvertieren oder importieren Per qemu-img convert -f vhdx -O raw disk.vhdx disk.raw in ein Rohformat wandeln — oder direkt mit qm importdisk <vmid> disk.vhdx shared-san in den Shared-SAN-Storage ziehen.
• VM-Hülle in Proxmox anlegen Eine neue VM mit passender CPU-/RAM-Ausstattung erstellen, die importierte Disk anhängen, Boot-Reihenfolge und Maschinentyp (q35, UEFI) setzen.
• Booten, Treiber finalisieren Beim ersten Start ggf. VirtIO-Storage als IDE/SATA übergangsweise anbinden, Treiber installieren, dann auf VirtIO umstellen — der bewährte Zwei-Schritt für Windows.

Stolperfallen-Checkliste vor dem Go-Live

• Thin auf Shared = Stopp. Auf gemeinsamem LUN niemals LVM-thin. Im Zweifel die Storage-Definition prüfen.
• Multipath vor LVM. Erst muss multipath -ll ein sauberes, vollständiges Pfadbild zeigen — dann erst pvcreate. Nie auf /dev/sdX arbeiten.
• initramfs aktualisieren nach jeder WWID-Änderung, sonst Boot-Race.
• Quorum sicherstellen: drei Knoten oder zwei plus QDevice. Zwei nackte Knoten sind kein HA-Cluster.
• Fencing testen, nicht annehmen. Watchdog aktiv? Knoten hart trennen und Failover beobachten — im Wartungsfenster, nicht im Ernstfall.
• Snapshot-Strategie festlegen, bevor die erste Produktiv-VM läuft: SAN-Hardware, PBS oder QCOW2-Kette — bewusst entscheiden.
• VirtIO überall. Ohne VirtIO-Treiber bleibt die I/O-Leistung weit unter dem, was das SAN hergibt.
• Backup vor Cut-over. Erst sichern (PBS oder vorhandenes Tool), dann migrieren — die Altumgebung bleibt bis zum bestandenen Test der Notausgang.

Typische Probleme & Lösungen

Die folgenden Fehlerbilder begegnen uns in FC-SAN-Migrationen am häufigsten — fast alle gehen auf dieselben drei Wurzeln zurück: Multipath nicht sauber vor LVM eingerichtet, der Storage nicht korrekt als shared markiert, oder fehlende VirtIO-Treiber im Gast. Erst die Diagnose-Befehle, dann die Symptom-Tabelle.

# Pfade & Multipath-Status
multipath -ll                 # sauberes Pfadbild? aktiv/aktiv?
journalctl -u multipathd -e

# LVM-Sicht auf das LUN
pvs ; vgs ; lvs            # PV auf /dev/mapper/mpathX?
pvscan --cache              # Metadaten-Cache auffrischen

# Cluster & HA
pvecm status                # Quorum vorhanden?
ha-manager status

Glossar

Fazit: Das SAN bleibt, die Lizenz geht

Die Frage, mit der dieser Artikel begann — „Was wird aus meinem Fibre-Channel-SAN?" — hat eine klare Antwort: Es bleibt im Einsatz. Proxmox VE bindet es per Multipath ein, legt ein Shared LVM darüber und liefert Live Migration und Hochverfügbarkeit, die funktional dem entsprechen, was vSphere Enterprise Plus bot — ohne die Funktion zu lizenzieren.

Der einzige Punkt, an dem Sie aktiv eine Architekturentscheidung treffen müssen, sind Snapshots. Mit SAN-Hardware-Snapshots und dem Proxmox Backup Server ist diese Lücke heute sauber geschlossen; die nativen QCOW2-Snapshot-Ketten in PVE 9 schließen sie mittelfristig auch direkt im Hypervisor. Wer das von Anfang an mitplant, migriert ohne funktionalen Rückschritt — und ersetzt eine fünfstellige Jahres-Subscription durch eine quelloffene Plattform auf der Hardware, die bereits im Rack steht.

Der kritische Erfolgsfaktor ist nicht das Tooling, sondern die Planung der Storage-Schicht und ein sauber getesteter Cut-over. Genau hier begleiten wir Mittelständler von der Bestandsaufnahme des SAN bis zur letzten migrierten VM.

Häufige Fragen (FAQ)