Proxmox im Unternehmenseinsatz: Die Fallstricke, die VMware-Admins nicht kommen sehen

Wenn VMware-Admins über den Sprung zu Proxmox sprechen, beginnt das Gespräch immer gleich: Die Broadcom-Rechnung landet im Postfach, jemand im Finanzteam gerät in Panik, und plötzlich wird der Virtualisierungs-Stack, der seit einem Jahrzehnt ruhig vor sich hin lief, zu einem dringenden Problem. Die Geschichte ist mittlerweile praktisch ein eigenes Genre.

Aber was nach diesem Moment passiert – wenn ein Team tatsächlich einen Proxmox-Proof-of-Concept aufsetzt und anfängt, seine alten ESXi-Gewohnheiten zu zerlegen –, das ist der Punkt, an dem es interessant wird. Und das ist der Punkt, an dem die Fallstricke auftauchen.

Teams, die diese Reise bereits hinter sich haben, sagen tendenziell dasselbe: Die Migration ist nicht der schwierige Teil. Die Denkweise ist es. Und je mehr jemand versucht, Proxmox wie VMware-mit-anderem-Logo zu behandeln, desto mehr wackelt es.

Es folgt eine Sammlung von Lektionen aus der Praxis, Warnungen und sanft-genervten Ratschlägen von Engineers, die den Übergang durchlebt haben – und den Überraschungen, die VMware-Veteranen immer wieder auf dem falschen Fuß erwischen.

Nicht „migrieren." Die Profis bestehen auf Neuaufbau.

Mehrere Engineers, die das in großem Maßstab gemacht haben, warnen: Sobald man anfängt, das Projekt als reine Migration zu betrachten, hat man sich bereits selbst eingeschränkt. Ein Admin brachte es unverblümt auf den Punkt: „Vergesst den Begriff Migration. Denkt in Redesign und Neuimplementierung."

Das ist nicht nur Philosophie. Die beiden Plattformen gehen Storage, Treiber, Netzwerk, CPU-Darstellung und Clustering mit gerade genug Unterschieden an, dass sich ein 1:1-Mapping zunächst natürlich anfühlt – bis es einem um die Ohren fliegt.

Deshalb reißen Teams, die versuchen, ihr altes VMware-Layout in Proxmox nachzubauen, oft einen Monat später die Hälfte ihrer Arbeit wieder ein. Diejenigen, die es als kompletten Neuaufbau behandeln und sich auf sauberes Storage-Design, Netzwerksegmentierung und Node-Planung konzentrieren, haben es tendenziell deutlich leichter.

Storage ist der Ort, an dem VMware-Gewohnheiten sterben

Ein Admin fasste es mit einem trockenen Lächeln zusammen: „VMFS hat uns verwöhnt."

Unter VMware handhabt VMFS Snapshots, Reservierungen und Cluster-Verhalten mit fast unheimlicher Reibungslosigkeit. Aber Proxmox nutzt kein VMFS – und da trifft der erste große Schock.

Teams landen meist auf einem von zwei Wegen:

1. NetApp-Betriebe bleiben bei NFS oder iSCSI

Für Umgebungen, die bereits fest mit NetApp verheiratet sind, wird NFSv3 zum einfachen Ausweg. Es ist schnell, vertraut und simpel. iSCSI funktioniert auch, besonders wenn jemand Thin Provisioning und SCSI-Reservierungen braucht. Aber es kommt mit einer Checkliste: MPIO richtig konfiguriert, Storage im eigenen VLAN, Jumbo Frames und eine saubere Trennung vom Corosync-Traffic.

Ein Engineer wies darauf hin, dass NetApp Proxmox jetzt offiziell unterstützt, was jahrelanges Händeringen à la „ist das überhaupt erlaubt?" sofort erledigt.

2. Die Ceph-Fraktion geht all-in

Andere gehen den entgegengesetzten Weg und bauen komplette interne Storage-Arrays mit Ceph. Sie beschreiben es als den Open-Source-Cousin von vSAN – nur transparenter und deutlich empfindlicher gegenüber schlampigen Hardware-Entscheidungen.

Jeder Engineer, der mit Ceph zufrieden ist, sagt dasselbe: „Identische Hardware. Punkt." Passende CPUs, RAM, NICs, HBAs im IT-Modus und Firmware im Gleichschritt gehalten.

Das Ergebnis ist ein Storage-Fabric, das skalieren und sich selbst heilen kann, aber Abkürzungen bestraft. Schlechter Arbeitsspeicher oder sterbende SSDs werden zu den einzigen echten Ausfällen, die man überhaupt noch sieht.

NUMA auf AMD Epyc: der Fallstrick, den fast niemand erwartet

VMware-Admins kennen sich meist mit dem Tuning von vNUMA auf Epyc-Hardware aus. Bei ESXi gibt es Stellschrauben, um die NUMA-Topologie offenzulegen und Grenzen anzupassen, damit Workloads sich benehmen.

Proxmox' KVM-Schicht bietet jedoch nicht dieselben Stellschrauben – zumindest nicht mit derselben Granularität. Und da werden Teams kalt erwischt.

Ein Engineer brachte es einfach auf den Punkt: Intel-Sockel verhalten sich vorhersehbar. Aber das Micro-NUMA-Layout von AMD Epyc wird von KVM auch heute noch nicht vollständig berücksichtigt. Wenn sich die vCPUs einer VM über NUMA-Grenzen erstrecken, taucht seltsame Latenz auf. Nicht katastrophal, nur nervig. Außer Sie sind Oracle – dann wird es zum Auditköder.

Der Workaround? hwloc, numactl und ein Monitoring-Tool installieren, das Pro-Thread-CPU-Verzögerungen auf jedem Node offenlegt. Nicht glamourös, aber der einzige Weg, um zu erkennen, welche Workloads NUMA-Grenzen überschreiten und sich dabei still und leise selbst in Brand setzen.

Windows-VMs verhalten sich anders — und die Lizenzierung wird chaotisch

Jeder Engineer, der Windows-Workloads migriert hat, sagt dasselbe: Erwarten Sie nicht, dass Ihre alten Hardware-IDs, GUIDs oder PCI-Subsystem-IDs überleben.

VMware präsentiert ein virtuelles Universum. KVM präsentiert ein anderes. Der Übergang setzt alles zurück, was Windows für die Lizenzierung wichtig ist. Das bedeutet, in manchen Fällen bei Microsoft anzurufen, gegen CSP-Beschränkungen zu kämpfen und sich mit Oracle-Reauth für alles unter dem großen roten Schirm herumzuschlagen.

Die meisten Admins empfehlen, jeden Lizenztyp früh zu testen – jeweils zwei Maschinen gleichzeitig –, bevor Sie eine Migrationswelle offiziell einplanen. Es ist mühsam, aber es bewahrt Sie vor dem 2-Uhr-morgens-Zusammenbruch nach dem Motto „warum ist die Payroll-VM unlizenziert?".

Windows-Treiberwechsel kommen ebenfalls mit ihrer eigenen Choreografie:

1. VMware Tools entfernen
2. Neu starten
3. VirtIO-Treiber installieren
4. Erneut neu starten
5. Den Import starten
6. Die Boot-Disk als SATA anhängen
7. Eine winzige SCSI-Disk mit VirtIO hinzufügen
8. Booten und den Red-Hat-SCSI-Controller erkennen lassen
9. Herunterfahren, die winzige Disk entfernen
10. Die echte Boot-Disk wieder als SCSI anhängen

Es klingt absurd, bis man es einmal gemacht hat – dann macht es klick. Und ja, rechnen Sie beim ersten Boot mit einem BSOD. Das System korrigiert sich beim zweiten Neustart normalerweise von selbst.

Netzwerke verhalten sich anders — und Open vSwitch wird Ihr neuer Freund

VMwares Netzwerk-Stack wird geliebt, weil er vorhersehbare Dinge auf vorhersehbare Weise tut. Proxmox' Linux-Bridge funktioniert einwandfrei, aber Engineers, die saubereres VLAN-Trunking, flexiblere Topologien oder ein ESXi-näheres Gefühl wollen, wechseln fast immer zu Open vSwitch.

Sobald sie das tun, fühle sich das VLAN-Mapping natürlicher an, und Automatisierungsschichten (Ansible, Terraform) verhielten sich konsistenter, sagen sie.

Der andere immer wiederkehrende Rat:

• Corosync in ein eigenes Netzwerk legen
• Storage-Traffic getrennt halten
• Einen Hardware-Watchdog verwenden
• Nicht alles „nur zum Testen" auf ein Interface packen und es dann vergessen

Das sind alles dieselben Ideen, die VMware-Admins schon kennen – aber das Muskelgedächtnis passt nicht immer zum Tooling.

HA- und Cluster-Verhalten erfordern Umdenken

VMware HA wurde über Jahre hinweg so poliert, dass es im Hintergrund verschwindet. Proxmox' HA-Stack funktioniert gut, verhält sich aber auf eine Linux-igere, transparentere Weise.

Diese Transparenz ist großartig – bis jemand sie ignoriert.

Ein Team merkte an, dass bei einer großen Zahl von VMs unter HA Backfill-Probleme auftreten können. Manchmal braucht HA einen Umschalter (deaktivieren → wieder aktivieren), um alten Zustand loszuwerden. Es ist selten, aber es passiert wirklich.

Ein weiteres wiederkehrendes Thema: Betreiben Sie einfach keine Zwei-Node-Cluster. Damit fordern Sie ein Split-Brain förmlich heraus. Wenn die Führungsebene absolut darauf besteht, sagen Engineers, sollte man mindestens ein QDevice hinzufügen.

Erwarten Sie mehr DIY — aber weniger echte Probleme

Das ist vielleicht der größte Kulturschock für VMware-Admins.

Mehrere Engineers, die Proxmox seit Jahren betreiben, sagen, sie hätten praktisch nie Support-Tickets eröffnet. Nicht weil sie keine Hilfe gebraucht hätten – sondern weil auf Plattformebene nichts kaputtging. Jeder Ausfall, den sie beschrieben, war Hardware: eine tote SSD, ein durchgebranntes DIMM, ein Stromproblem.

Komponente tauschen, ZFS oder Ceph neu aufbauen lassen, weitermachen.

Das heißt nicht, dass Proxmox keine Handarbeit braucht. Kernel-Updates erfordern Neustarts. Cluster-Upgrades brauchen Planung. Aber die Umgebung hat nicht dieselben „mysteriösen Ausfälle", die man mit ESXi-Host-Agenten oder vCenter-Eigenheiten verbindet.

Automatisierung hilft — aber das Ökosystem ist anders

VMware-Admins bringen oft vRealize oder PowerCLI im Blut mit. Proxmox setzt stark auf offenes Tooling:

• Ansible für Konfiguration
• Terraform für Provisionierung
• REST-API für individuelle Workflows
• Proxmox Backup Server für Backups im Snapshot-Modus und Bare-Metal-Recoveries

Ein Engineer erwähnte sogar, mit DreamFactory eine schnelle Integrationsschicht gebaut zu haben, um leichtgewichtige REST-Endpunkte für Kontingente und Inventar bereitzustellen – etwas, das ein Wochenende statt eines Budgetzyklus brauchte.

Die Stimmung ist teamübergreifend dieselbe: Proxmox gibt Ihnen die Bausteine. Wie Sie sie zusammenstecken, bleibt Ihnen überlassen.

Und dann ist da noch Oracle …

Jeder Engineer mit Oracle-Workloads sagt dasselbe: isolieren.

Oracle-Workloads auf einen dedizierten Cluster packen. Keine Migration. Kein vMotion. Keine CPU-Grenzen anfassen. Keine Überraschungen für den Auditor.

Nur eine ruhige kleine Insel mit dokumentierten Grenzen.

Der eigentliche Schock? Wie ereignislos alles wird, sobald das Design stimmt

Die lauteste Botschaft der Engineers, die den Sprung gewagt haben, ist überraschend langweilig: Sobald Storage stimmt, das Netzwerk sauber ist, NUMA verstanden wird und die Migrationspraxis sitzt, wird Proxmox … ruhig.

Nicht angeberisch. Nicht auffällig. Einfach stabil.

Updates landen. Backups laufen. Ceph heilt sich selbst. VMs machen VM-Dinge. Die Plattform verschwindet in den Hintergrund, auf dieselbe angenehme Weise, wie es ESXi einst tat – bevor die Rechnung kam.

Die eigentliche Arbeit steckt nicht in den Migrationsskripten oder den VM-Importen. Sie steckt darin, alte Annahmen abzulegen. VMware hat geprägt, wie sich Virtualisierung für die Leute anfühlen sollte. Proxmox bittet sie, ein bisschen anders zu denken.

Die Teams, die sich auf diesen Wandel einlassen? Fragen sich meist, warum sie nicht früher gegangen sind.