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.
Was versagt hat, war nicht Proxmox. Was versagt hat, war eine Annahme, die uns VMware 15 Jahre lang beigebracht hat.
VMware hat Storage nicht einfach gemacht — es hat es unsichtbar gemacht
Die größte Leistung von VMware war nicht die Virtualisierung selbst. Es war die Isolierung.
VMFS, SAN-Integrationen, vSAN und Jahre an Engineering-Arbeit haben die scharfen Kanten von Storage geglättet. Locking-Verhalten, Alignment-Probleme, Cache-Druck — all das lebte hinter einer sauberen Abstraktionsschicht. 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, nicht 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.
Stattdessen gibt es Ihnen die Rohmaterialien: ZFS, Ceph, LVM, XFS. Mächtige Tools. Weniger Leitplanken. Deutlich mehr Ehrlichkeit. Wenn etwas schiefgeht, werden Sie es sehen — und spüren.
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. 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, was es bekommen kann. 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.
Wenn der Druck steigt, ist es dem Linux-OOM-Killer egal, dass Ihre SQL-VM "wichtig" ist. Er sieht nur ein System unter Stress und trifft eine Entscheidung. Aus Ihrer Sicht meist die falsche.
Ja, neuere ZFS-Versionen sind besser darin, Speicher wieder freizugeben. Ja, ARC ist inzwischen leichter reklamierbar als früher. Das ändert nichts an der Kernlektion: Wenn Sie ihn nicht bewusst deckeln, vertrauen Sie auf adaptives Verhalten genau in den Momenten, in denen Vorhersagbarkeit am wichtigsten ist.
Das ist kein Proxmox-Bug. 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. Das bedeutet, Ihre Platten reden ständig miteinander über das Netzwerk. Wenn alles gesund ist, ist das beherrschbar. Fällt eine Platte aus, wird aus diesem Geplauder ein Feuerwehrschlauch.
Auf einem 1GbE-Netzwerk wird dieser Feuerwehrschlauch zu einer Betonwand.
Der Cluster geht nicht zwingend down. 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 so aus, als wäre Proxmox auseinandergefallen.
In Wirklichkeit ist es das Netzwerk.
Die Ceph-Dokumentation ist seit Jahren unmissverständlich: 10GbE ist das Minimum. Kein Vorschlag. Die Untergrenze. Und in echten Produktionsumgebungen ist 25GbE das, was Ihnen tatsächlich Luft zum Atmen gibt, wenn etwas kaputtgeht — und etwas geht immer kaputt.
Ceph auf 1GbE zu betreiben, weil "es funktioniert", ist wie zu entdecken, 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. 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. Nicht bei der unsichtbaren Storage-Fehlanpassung, die im Stillen alles ausbremst.
VMware hat Ihnen einen Großteil dieses Schmerzes abgenommen. Proxmox nicht. Es geht davon aus, dass Sie wissen, was Sie tun. Wenn nicht, wird es Sie nicht aufhalten — es lässt Sie einfach die harte Lektion lernen.
"Kostenlos" war nie der eigentliche Preis
Hier ist der Teil, den niemand gerne laut sagt: Die VMware-Lizenzen wegzunehmen, entfernt nicht die Komplexität. Sie 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. Speicherverhalten. Netzwerksättigung. Disk-Geometrie. Failure Domains. Rebuild-Dynamik.
Dieser Tausch kann fantastisch sein. Viele Teams bringen das zum Laufen. Aber sie schaffen das nicht, indem sie so tun, als wäre Proxmox ein Drop-in-Ersatz für vSphere.
Wenn Sie Storage wollen, um die 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 können, ist anzunehmen, dass sich sonst nichts ändern muss.
Das ist kein Proxmox-Problem. Das ist ein Realitätscheck.
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, sind kein Beweis dafür, dass Proxmox nicht bereit ist. Sie sind der Beweis dafür, 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.