Warum Ihre Proxmox-Migration gescheitert ist (Hinweis: Es lag nicht an Proxmox)
Gerade findet in vielen IT-Meetings ein vertrauter Moment statt. Jemand ruft ein Spreadsheet auf, die Lizenzkosten sind rot eingekreist, Broadcom wird erwähnt, meist mit einem Seufzer. Und dann stellt jemand die Frage, die offensichtlich, fast unausweichlich klingt: "Warum wechseln wir nicht einfach komplett zu Proxmox? Das ist im Grunde kostenloses VMware."
Auf den ersten Blick ergibt das Sinn. Proxmox wirkt bereit, die Feature-Liste stimmt, viele Leute betreiben es produktiv ohne Probleme. VMware vSphere ist derweil von der Standardwahl zu einem unangenehmen Budgetgespräch geworden. Also fällt die Entscheidung, VMs werden konvertiert, Hosts werden aufgebaut, der Umstieg passiert.
Und dann fängt das Seltsame an. Datenbanken brechen unter Last zusammen, die Latenz springt ohne offensichtlichen Grund nach oben, ganze Nodes fühlen sich träge an, obwohl das Monitoring sagt, alles sei "in Ordnung". Es dauert nicht lange, bis das Fazit steht: "Proxmox ist instabil." "Open Source ist nicht enterprise-tauglich." "Wir hätten bei VMware bleiben sollen."
Nur ist das nicht das, was tatsächlich passiert ist. Versagt hat hier eine Annahme, die uns VMware 15 Jahre lang beigebracht hat.
VMware hat Storage unsichtbar gemacht
Die größte Leistung von VMware war die Isolierung, nicht die Virtualisierung selbst. VMFS, SAN-Integrationen, vSAN und Jahre an Engineering-Arbeit haben die scharfen Kanten von Storage geglättet. Locking-Verhalten, Alignment-Probleme und Cache-Druck lebten hinter einer sauberen Abstraktionsschicht, und an den meisten Tagen musste man nicht darüber nachdenken. Das war der Sinn der Sache.
Das hat Admins nicht faul gemacht, es hat die Plattform erfolgreich gemacht. Aber es bedeutete auch, dass viele Teams gelernt haben, welche Buttons man klickt, ohne zu lernen, warum die Dinge funktionieren. Man dimensionierte Hosts, man folgte Best Practices, man vertraute darauf, dass das System die Komplexität abfedert.
Proxmox spielt diese Rolle nicht. Es gibt Ihnen stattdessen die Rohmaterialien, also ZFS, Ceph, LVM und XFS: mächtige Tools mit weniger Leitplanken und deutlich mehr Ehrlichkeit. Wenn etwas schiefgeht, sehen und spüren Sie es. Allein dieser Unterschied reicht aus, um Migrationen entgleisen zu lassen, die auf dem Papier völlig in Ordnung aussehen.
ZFS und der Arbeitsspeicher, den Sie zu haben glaubten
Eine der häufigsten Geschichten nach der Migration klingt zunächst fast langweilig. Eine VM stürzt ab, es ist reichlich RAM verbaut, der Host ist nicht überlastet, nichts wirkt offensichtlich falsch, und Proxmox bekommt die Schuld. Gräbt man etwas tiefer, sitzt meist ZFS mittendrin und tut genau das, wofür es entwickelt wurde.
ZFS liebt Arbeitsspeicher. Es nutzt ARC, um freien RAM in schnellere Reads und bessere Performance zu verwandeln, und wenn Sie ihm nichts anderes sagen, nimmt es sich, was es bekommen kann, und das ist eine ganze Menge. Wenn Sie von ESXi migriert sind und Ihre Hosts genauso dimensioniert haben, fängt hier alles an, sich zu entwirren: Bei VMware gehörte dieser Speicher fast vollständig den Gästen, bei Proxmox mit ZFS konkurriert nun auch das Dateisystem darum.
Steigt der Druck, ist es dem Linux-OOM-Killer egal, dass Ihre SQL-VM "wichtig" ist. Er sieht ein System unter Stress und trifft eine Entscheidung, aus Ihrer Sicht meist die falsche.
Ja, neuere ZFS-Versionen sind besser darin, Speicher wieder freizugeben, und ARC ist inzwischen leichter reklamierbar als früher. An der Kernlektion ändert das nichts: Wenn Sie ihn nicht bewusst deckeln, vertrauen Sie auf adaptives Verhalten genau in den Momenten, in denen Vorhersagbarkeit am wichtigsten ist. Ein Proxmox-Bug ist das nicht, das ist Storage, das tut, was Storage tut.
Ceph über 1GbE: Technisch möglich, praktisch eine Katastrophe
Dann gibt es noch Ceph, oder genauer die Art, wie Leute versuchen, es zu betreiben. Ceph ist verteilter Storage, Ihre Platten reden also ständig über das Netzwerk miteinander. Wenn alles gesund ist, ist das beherrschbar. Fällt eine Platte aus, wird aus diesem Geplauder ein Feuerwehrschlauch, und auf einem 1GbE-Netzwerk wird dieser Feuerwehrschlauch zu einer Betonwand.
Der Cluster geht dabei nicht zwingend down, und genau das ist das Tückische daran. Er bleibt "oben", Health-Checks sehen vielleicht sogar okay aus, aber die Latenz explodiert, Rebuilds kriechen dahin, und jede VM fühlt sich an, als würde sie durch Schlamm waten. Von außen sieht es aus, als wäre Proxmox auseinandergefallen, während in Wirklichkeit das Netzwerk das Problem ist.
Die Ceph-Dokumentation ist seit Jahren unmissverständlich: 10GbE ist das Minimum, also die Untergrenze und kein Vorschlag. Und in echten Produktionsumgebungen gibt Ihnen erst 25GbE Luft zum Atmen, wenn etwas kaputtgeht, und etwas geht immer kaputt.
Ceph auf 1GbE zu betreiben, weil "es funktioniert", ist wie die Entdeckung, dass Ihr Auto sich technisch auch mit angezogener Handbremse fahren lässt. Sie kommen vom Fleck. Was danach passiert, wird Ihnen nur nicht gefallen.
Der Migrationsfehler, den niemand bemerkt, bis es zu spät ist
Die meisten Migrationen folgen demselben Skript: Disk konvertieren, VM importieren, booten, und wenn sie startet, gilt das als gut. So landet man bei Systemen, die sich unerklärlich langsam anfühlen.
Wenn Sie virtuelle Disks verschieben, ohne auf das Sector-Alignment zu achten, besonders beim Wechsel von veralteten 512-Byte-Layouts zu 4K-basiertem Storage, kann jeder Write zu zusätzlicher Arbeit werden. Aus einem logischen Write werden mehrere physische Operationen, die IOPS sinken, die Latenz steigt. Nichts stürzt ab, nichts wirft einen Fehler, die Performance verschlechtert sich nur leise.
Und weil sich gleichzeitig der Hypervisor geändert hat, landet die Schuld dort statt bei der unsichtbaren Storage-Fehlanpassung, die im Stillen alles ausbremst. VMware hat Ihnen einen Großteil dieses Schmerzes abgenommen, Proxmox geht davon aus, dass Sie wissen, was Sie tun. Wenn nicht, hält es Sie nicht auf, sondern lässt Sie die harte Lektion lernen.
"Kostenlos" war nie der eigentliche Preis
Hier ist der Teil, den niemand gerne laut sagt: Die VMware-Lizenzen wegzunehmen entfernt die Komplexität nicht, es verlagert sie nur. Bei VMware haben Sie Geld bezahlt, um bestimmte Probleme nicht durchdenken zu müssen. Bei Proxmox sparen Sie Geld und holen sich diese Probleme ins Haus zurück, also Speicherverhalten, Netzwerksättigung, Disk-Geometrie, Failure Domains und Rebuild-Dynamik.
Dieser Tausch kann fantastisch sein, und viele Teams bringen das zum Laufen. Sie schaffen das allerdings nicht, indem sie so tun, als wäre Proxmox ein Drop-in-Ersatz für vSphere. Wenn Sie Storage wollen, um den man sich nicht kümmern muss, kaufen Sie ein SAN. Wenn Sie Performance wollen, kaufen Sie RAM und tunen Sie ZFS. Wenn Sie hyperkonvergente Infrastruktur wollen, bauen Sie ein echtes Netzwerk und akzeptieren Sie, was das bedeutet. Was Sie nicht annehmen können, ist, dass sich sonst nichts ändern muss.
Was Proxmox wirklich verändert
VMware hat Engineers nicht schlechter gemacht, es hat bestimmte Fehler schwerer sichtbar gemacht. Proxmox entfernt dieses Polster. Das ist unangenehm, besonders wenn Migrationen überstürzt und Erwartungen unrealistisch sind. Aber die Ausfälle, die Leute sehen, belegen nicht, dass Proxmox unfertig wäre. Sie belegen, dass Abstraktion mehr verdeckt hat, als uns bewusst war.
Die Teams, die sich Zeit nehmen, die Grundlagen neu lernen und bewusst planen, werden gut zurechtkommen. Die, die hetzen, Disks konvertieren und darauf hoffen, dass die Routine sie trägt, werden weiterhin dem Falschen die Schuld geben.
Ihre Migration ist nicht gescheitert, weil Proxmox schlecht ist. Sie ist gescheitert, weil Proxmox aufgehört hat, darüber zu lügen, wie Ihre Infrastruktur tatsächlich funktioniert, und das kann ein böses Erwachen sein.