Newsletter

    Newsletter abonnieren

    Neue Infrastruktur-Guides, Vergleichsberichte und Migrationshinweise direkt ins Postfach.

    Infrastruktur-Notizen, Guides und neue Tools. Jederzeit abbestellbar.

    Zurück zum Blog
    Proxmox
    VMware
    SAN
    Storage
    Migration

    Proxmox-Cluster und SANs: Das VMware-Exit-Problem, vor dem Sie niemand gewarnt hat

    10. Januar 2026
    6 Min. Lesezeit

    VMware zu verlassen fühlt sich an, wie ein Pflaster abzureißen. Schmerzhaft, klar, aber alle sagen einem, dass es sich lohnt. Lizenzmüdigkeit, explodierende Kosten, Verträge, die sich plötzlich feindselig anfühlen — die Gründe sind bekannt. Proxmox tritt ruhig, offen und erfrischend ehrlich auf. Es verspricht Clustering, HA, Live-Migration und eine Zukunft, in der Sie nicht bei jedem Verlängerungszyklus mit einem Vertriebsmitarbeiter verhandeln müssen.

    Sollten Sie Ihr SAN für Proxmox und Ceph aufgeben?

    Also tun Sie, was naheliegend erscheint.

    Sie nehmen die Architektur, der Sie seit einem Jahrzehnt vertrauen — einen kleinen, SAN-gestützten Cluster — und stecken Proxmox hinein. Gleicher Storage, neuer Hypervisor. Einfach, oder?

    Genau da wird es seltsam.

    Denn wovor Sie niemand warnt, ist Folgendes: SAN-gestütztes Proxmox verhält sich nicht wie SAN-gestütztes VMware, selbst wenn technisch alles „funktioniert". Die Lücke liegt nicht bei der Performance. Sie liegt bei den Erwartungen.

    Und diese Lücke erwischt viele Teams auf dem falschen Fuß.

    Das Problem mit den eingefahrenen VMware-Routinen

    Die meisten VMware-Umgebungen haben Admins darauf trainiert, auf eine ganz bestimmte Weise zu denken. Shared Block Storage ist der Mittelpunkt des Universums. Snapshots sind billig. Thin Provisioning ist unsichtbar. Man überbucht Storage mit Selbstvertrauen und kümmert sich später um die Konsequenzen — meistens nie.

    VMFS schluckt die Komplexität still und leise. Das SAN erledigt seine Magie. Der Hypervisor hält sich raus.

    Wenn Leute zu Proxmox wechseln, gehen sie oft davon aus, dass dieselbe Arbeitsteilung weiterhin gilt. Das SAN übernimmt die Storage-Intelligenz. Der Hypervisor konsumiert sie nur.

    Aber Proxmox verbirgt Storage-Entscheidungen nicht vor Ihnen. Es zwingt Sie, dafür Verantwortung zu übernehmen.

    Shared LVM: Die erste Überraschung

    Die meisten SAN-basierten Proxmox-Cluster starten mit Shared LVM über iSCSI oder Fibre Channel. Das wird unterstützt, ist dokumentiert und stabil. Auf dem Papier erfüllt es die Anforderungen als VMware-Ersatz.

    Und ja, es funktioniert. Live-Migration funktioniert. HA funktioniert. Multipath funktioniert.

    Aber dann fangen die Fragen an.

    Warum sind Disks thick provisioniert?

    Warum fehlen Snapshots oder sind gefährlich?

    Warum gibt das Löschen einer VM keinen Speicherplatz zurück?

    Hier bricht die eingefahrene VMware-Routine zusammen.

    Shared LVM in Proxmox ist bewusst konservativ. Volumes wollen garantierten Speicherplatz. Snapshots sind keine leichtgewichtigen Metadaten-Tricks; sie sind waschechte Copy-on-Write-Strukturen, die sofort aufblähen können. Ein Snapshot einer 1-TB-virtuellen-Disk kann 1 TB Speicherdruck bedeuten — selbst wenn sich nichts ändert.

    Thin Provisioning auf SAN-Ebene löst das nicht magisch. Der Hypervisor sieht es nicht. Proxmox plant Storage so, als wäre er real, reserviert und endlich — denn aus seiner Sicht ist er das auch.

    Admins erwarten Flexibilität. Proxmox liefert stattdessen Vorhersagbarkeit.

    „Aber das SAN macht doch Thin Provisioning"

    Das kommt oft auf, und es stimmt technisch gesehen.

    Viele moderne SANs beherrschen Thin Provisioning, Deduplizierung und Kompression hervorragend. Sie geben Blöcke effizient frei. Sie lügen, höflich, bei der Kapazität.

    Das Problem ist Sichtbarkeit.

    Mit Shared LVM versteht Proxmox nicht, wie das SAN in Ihrem Namen die Physik austrickst. Es sieht weiterhin ein großes, fixes LUN. Wenn Sie eine Disk snapshotten, bereitet sich Proxmox auf das Worst-Case-Wachstum vor. Wenn Sie eine VM löschen, gibt das SAN möglicherweise nichts frei, sofern Discard nicht perfekt konfiguriert ist.

    Diese Diskrepanz erzeugt ein falsches Sicherheitsgefühl.

    Alles sieht gut aus … bis es das nicht mehr tut.

    Und wenn es schiefgeht, geht es schnell schief.

    NFS: Die Option, gegen die sich alle wehren (und die sie dann trotzdem nutzen)

    Irgendwann in fast jeder Migration sagt es jemand laut aus: „Was, wenn wir einfach NFS nutzen?"

    Darauf folgen meist Stille, mildes Entsetzen und ein paar Witze über die Performance.

    Aber hier ist die unbequeme Wahrheit: NFS ist oft die Art, Shared Storage auf Proxmox zu betreiben, die am wenigsten überrascht.

    Dateibasierter Storage schaltet qcow2-Disks frei. Das bedeutet Thin Provisioning, das Proxmox tatsächlich versteht. Snapshots leben innerhalb der Disk-Datei, statt ganze logische Volumes zu belegen. Speichernutzung wird sichtbar, vorhersagbar und wiederherstellbar.

    Es ist nicht so schnell wie rohes Block-Storage. Es ist nicht so elegant. Es kann Multipath nicht so wie Fibre Channel.

    Aber es verhält sich vorhersehbar.

    Und wenn Sie von VMware migrieren, zählt Verhalten mehr als Benchmarks.

    Der Snapshot-Realitätscheck

    Bei Snapshots prallen Erwartung und Realität wirklich aufeinander.

    In VMware sind Snapshots gefährlich, aber trügerisch einfach. Jeder weiß, dass sie keine Backups sind. Jeder nutzt sie trotzdem. Sie sind schnell, flexibel und meistens unproblematisch.

    In Proxmox mit Shared LVM fühlen sich Snapshots wie eine Falle an. Es gibt sie, aber sie fühlen sich nicht sicher an. Sie skalieren schlecht. Und sie können Ihre Storage-Rechnung auf eine Weise sprengen, die VMware nie offengelegt hat.

    Das erzwingt einen Kulturwandel.

    Teams behandeln VMs wieder wie Vieh. Unveränderliche Images. Externe Backups. Kurzlebige Snapshots, wenn überhaupt. Wiederherstellung durch Restore, nicht durch Zurückspulen.

    Das ist nicht schlechter. Es ist nur anders.

    Und anders ist unangenehm während einer Migration.

    „Warum nicht einfach Ceph nutzen?"

    Sobald der SAN-Schmerz einsetzt, betritt Ceph die Bühne.

    Ceph ist nativ. Integriert. Von Grund auf für Proxmox-Cluster entworfen. Es skaliert, heilt sich selbst und macht Shared Storage zum vollwertigen Bestandteil statt zur externen Abhängigkeit.

    Aber Ceph ist nicht kostenlos — weder bei der Hardware noch beim Netzwerk, und ganz sicher nicht bei der operativen Komplexität.

    Für kleine 2- bis 3-Node-Cluster wirkt Ceph oft wie Overkill. Es will RAM. Es will schnelle Disks. Es will saubere Netzwerke. Und es belohnt Disziplin, keine Abkürzungen.

    Manche Teams lieben es. Andere scheitern hart daran.

    Ceph ist nicht die Antwort auf SAN-Enttäuschung. Es ist eine völlig andere Philosophie.

    Das eigentliche Problem ist nicht der Storage

    Das ist der Teil, den niemand in Planungsmeetings laut ausspricht:

    Das eigentliche Problem sind nicht SANs. Es sind Annahmen.

    VMware hat Admins darauf trainiert, nicht mehr über Storage-Mechanik nachzudenken. Proxmox holt diese Mechanik zurück an die Oberfläche. Es schützt Sie nicht vor falscher Rechnung. Es verbirgt Risiko nicht hinter freundlichen Standardeinstellungen.

    Das fühlt sich wie ein Rückschritt an, bis Sie merken, was Sie dafür gewinnen.

    Transparenz. Kontrolle. Weniger versteckte Abgründe.

    Aber das hilft nur, wenn Sie darauf vorbereitet sind.

    Was erfolgreiche Migrationen gemeinsam haben

    Teams, die SAN-gestützte Proxmox-Migrationen zufrieden abschließen, teilen tendenziell ein paar Eigenschaften:

    Sie akzeptieren, dass sich nicht alles eins zu eins von VMware übertragen lässt.

    Sie gestalten Storage um die Stärken von Proxmox herum, nicht um VMware-Nostalgie.

    Sie behandeln Snapshots als Werkzeuge, nicht als Sicherheitsnetze.

    Sie planen Kapazität, als würde sie wirklich zählen — denn das tut sie wieder.

    Manche landen bei NFS. Manche bleiben bei Shared LVM und passen ihre Erwartungen an. Manche setzen voll auf Ceph. Ein paar mischen lokalen Storage mit Replikation und hören ganz auf, zentralisierter Perfektion hinterherzujagen.

    Keine dieser Entscheidungen ist falsch.

    Falsch ist die Annahme, Proxmox würde sich klammheimlich wie VMware verhalten, wenn man nur fest genug die Augen zusammenkneift.

    Der Exit lohnt sich — nur nicht schmerzfrei

    Proxmox ist nicht kaputt. SANs sind nicht obsolet. Und die Migration weg von VMware bedeutet nicht, die Standards zu senken.

    Es bedeutet aber, neu zu lernen, wo die Leitplanken stehen.

    Die Teams, die kämpfen, sind nicht die, denen technisches Können fehlt. Es sind die, die erwartet haben, dass die Storage-Schicht unsichtbar bleibt.

    Proxmox macht nicht unsichtbar. Es macht ehrlich.

    Und sobald Sie aufhören, dagegen anzukämpfen, ergibt der gesamte Stack plötzlich viel mehr Sinn.

    Weiterführende Ressourcen