VMware-Broadcom-Exit: Der Enterprise-Migrationsleitfaden zu Proxmox VE und Ceph

Nachdem die kaufmännische Entscheidung gegen eine Verlängerung überteuerter VMware-Core-Abonnements gefallen ist, verlagert sich der Schwerpunkt von der Vorstandsetage in die Systemarchitektur. Während die wirtschaftlichen Hintergründe in unserer strategischen Analyse zur Broadcom-Kostenfalle für den CIO beleuchtet werden, entscheidet auf der technischen Arbeitsebene die präzise Vorbereitung über den Erfolg der Migration.

Ein Rechenzentrum mit mehreren hundert produktiven Datenbank-, ERP- und Applikationsservern lässt sich nicht per Knopfdruck auf einen neuen Hypervisor heben. Wer virtuelle Maschinen unvorbereitet aus einer gewachsenen ESXi- und vSAN-Landschaft herauslöst, riskiert nicht nur vermeidbare Ausfallzeiten beim ersten Systemstart unter KVM, sondern auch spürbare Leistungseinbußen durch falsch dimensionierte Speicher- und Netzwerkpfade.

Dieser technische Ausführungsleitfaden richtet sich an Infrastruktur-Architekten, Senior-Systemingenieure und technische Projektleiter. Er beschreibt Schritt für Schritt, wie Sie Ihre Gastsysteme auf den Hypervisor-Wechsel vorbereiten, den FUSE-gestützten Live-Import nutzen, ein hochverfügbares Ceph-BlueStore-Cluster aufbauen und bestehende NSX- sowie Backup-Strukturen sauber in Proxmox VE 8.x überführen.

Gastsystem-Vorbereitung und FUSE-Live-Import aus ESXi-Datastores

Der häufigste Grund für fehlgeschlagene Startversuche nach einem Hypervisor-Wechsel liegt in der fehlenden Treiberunterstützung innerhalb des Gastbetriebssystems. Unter VMware vSphere greifen virtuelle Maschinen standardmäßig über den paravirtualisierten PVSCSI-Controller auf ihre Festplatten und über den Adapter VMXNET3 auf das Netzwerk zu. Beide Schnittstellen müssen beim Übergang auf KVM durch native VirtIO-Komponenten abgelöst werden.

Bei Linux-Gastsystemen ab Kernel 4.x sind die benötigten KVM-Treiber (virtio_blk, virtio_scsi und virtio_net) in aller Regel bereits als Kernel-Module im Initial-RAM-Filesystem (initramfs) hinterlegt. Dennoch sollte das Betriebsteam auf älteren RHEL- oder SLES-Instanzen vorab per dracut prüfen, ob das Modul virtio_scsi beim Bootvorgang geladen wird, und parallel das Paket qemu-guest-agent installieren.

Windows-Registry-Injektion, VirtIO-SCSI-Single und QEMU-Guest-Agent

Deutlich anspruchsvoller gestaltet sich der Wechsel bei Microsoft Windows Server (2016 bis 2025). Da das Windows-Installationsmedium ab Werk keine Red-Hat-VirtIO-Treiber mitbringt, quittiert ein unvorbereiteter Windows-Server die direkte Umstellung seines Boot-Laufwerks auf VirtIO-SCSI mit einem Bluescreen vom Typ INACCESSIBLE_BOOT_DEVICE. In der Enterprise-Praxis erfolgt daher eine automatisierte Vorab-Injektion im laufenden ESXi-Betrieb.

Über ein zentrales Ansible-Playbook oder Gruppenrichtlinien wird das signierte Paket virtio-win-gt-x64.msi gemeinsam mit dem QEMU-Guest-Agenten bereits Tage vor dem Wartungsfenster still auf allen Windows-Servern installiert. Dabei werden die Speichertreiber viostor und vioscsi sowie der Netzwerktreiber NetKVM mittels pnputil in den Windows Driver Store eingetragen.

Damit der Windows-Kernel den Treiber beim ersten Start auf dem Proxmox-Host auch ohne vorherige Hardware-Erkennung lädt, setzt das Vorbereitungsskript den Startwert des Dienstes vioscsi in der Windows-Registry unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vioscsi explizit auf 0 (Boot-Start). Nach dem ersten Boot unter KVM werden die alten VMware Tools bereinigt und der Controller auf VirtIO-SCSI-Single mit aktivierten IO-Threads umgestellt.

Funktionsweise des FUSE-basierten Live-Imports über die vSphere-API

Sobald die Gastsysteme vorbereitet sind, greift der native ESXi-Import-Mechanismus von Proxmox VE 8.x auf Basis des Pakets pve-esxi-import-tools. Der Ziel-Host baut über HTTPS eine lesende API-Verbindung direkt zum ESXi-Hypervisor auf und blendet dessen VMFS-, NFS- oder vSAN-Datastores über ein FUSE-Dateisystem (Filesystem in Userspace) unter /run/pve/import/esxi/ ein.

Der entscheidende Zeitgewinn entsteht durch die Live-Import-Funktion: Sobald die Quell-VM auf dem ESXi-Host heruntergefahren und der Import angestoßen wird, übersetzt Proxmox die VMX-Metadaten in eine KVM-Konfiguration und startet die Maschine sofort auf dem neuen Knoten. Während das System bereits produktiv läuft, streamt ein Hintergrundprozess die VMDK-Blöcke kontinuierlich in das neue Ceph-RBD-Volume und priorisiert laufende Lesezugriffe in Echtzeit.

Ergänzende Architektur-Analysen und technische Entscheidungsmatrizen für Ihre IT-Planung finden Sie in unseren weiterführenden Leitartikeln zu Cloud-Exit-Strategie im Enterprise-Einsatz sowie zu OpenTofu vs Terraform im Enterprise-Einsatz.

Ceph BlueStore und 25/100-GbE-Netzwerkdesign als vSAN-Ablösung

Wer im Zuge der Migration auch VMware vSAN oder alternde Fibre-Channel-SANs ablöst, findet in der direkt in Proxmox VE integrierten Speicherplattform Ceph (Reef und Squid) das technologische Gegenstück. Ceph arbeitet als verteiltes, selbstheilendes Speichersystem, das über RADOS Block Devices (RBD) virtuelle Festplatten redundant über alle Cluster-Knoten bereitstellt.

Enterprise-NVMe-Sizing mit Power Loss Protection und CRUSH-Regeln

Um im produktiven Datenbankbetrieb dauerhaft Latenzen unter einer Millisekunde zu garantieren, sind für Ceph BlueStore ausschließlich Enterprise-NVMe-Laufwerke (U.2/U.3 oder E3.S) mit Hardware-Kondensatoren zur Power Loss Protection (PLP) und einer Haltbarkeit von 1 bis 3 DWPD einzusetzen. Jede NVMe agiert als Object Storage Daemon (OSD) inklusive integrierter RocksDB-Metadatenbank und Write-Ahead-Log (WAL).

Pro NVMe-OSD sollten in der Kapazitätsplanung mindestens zwei bis vier physische CPU-Threads sowie 8 bis 16 Gigabyte RAM (osd_memory_target) reserviert werden. Für die Ausfallsicherheit gilt ein strikter Replikationsfaktor von 3/2 (size=3, min_size=2) über die CRUSH-Map. Vertiefende Details zur Dimensionierung finden Sie im Leitfaden zur Rechenzentrums-Autarkie mit Ceph und NVMe-over-Fabrics.

„Ein Enterprise-Cluster unter Proxmox VE und Ceph verzeiht den Ausfall ganzer Server-Racks, aber niemals Nachlässigkeit beim Netzwerk- und SSD-Design: Physisch isolierte Corosync-Ringe, 25/100-GbE-Storage-Fabrics und Enterprise-NVMes mit Power Loss Protection sind das Fundament für Latenzen unter einer Millisekunde.“

Strikte Trennung von Corosync-Quorum und 25/100-GbE-Replikationsnetz

Auf der Netzwerkebene verlangt der kombinierte Betrieb von Proxmox-HA und Ceph eine kompromisslose Trennung der Datenströme. Das Kronosnet-Protokoll (knet) von Corosync, über welches das Cluster sein Quorum und das Watchdog-Fencing steuert, benötigt Latenzen unter zwei Millisekunden und wird daher über zwei physisch getrennte Netzwerkpfade (ring0 und ring1) geführt.

Für den Ceph-Datenverkehr kommen redundante 25-GbE- oder 100-GbE-Schnittstellen mit durchgängiger MTU 9000 (Jumbo Frames) zum Einsatz. Dabei wird das Ceph-Public-Network (Zugriff der KVM-Hosts auf die OSDs) vom Ceph-Cluster-Network (interne OSD-Replikation und Recovery-Backfilling) über getrennte VLANs oder dedizierte Ports entkoppelt, sodass Replikationsspitzen niemals den laufenden VM-Betrieb beeinträchtigen.

EVPN/VXLAN als NSX-Ersatz sowie PBS- und Veeam-12.2-Integration

In größeren VMware-Umgebungen bildet häufig die über VMware NSX realisierte Mikrosegmentierung eine zusätzliche Hürde beim Ausstieg. Proxmox VE begegnet dieser Anforderung mit einem nativ in Web-GUI und API integrierten Software-Defined-Networking-Stack (SDN) auf Basis von VXLAN-Overlays und BGP-EVPN über den Routing-Daemon FRRouting (FRR).

Jeder Proxmox-Knoten agiert dabei als lokaler VTEP mit identischem Anycast-Gateway, während die verteilte Proxmox-Firewall (auf Basis von Linux nftables) zustandsbehaftete Security Groups und IP-Sets direkt an das virtuelle Netzwerkinterface jeder einzelnen VM bindet. Dadurch lassen sich mandantenfähige Zero-Trust-Zonen ohne proprietäre NSX-Manager-Appliances und ohne Zusatzlizenzen abbilden.

Für die Datensicherung nutzt sowohl der Proxmox Backup Server (PBS) als auch Veeam Backup & Replication ab Version 12.2 die im Arbeitsspeicher geführten QEMU Dirty-Bitmaps. Geänderte Blöcke werden ohne belastende Dateisystem-Snapshots inkrementell gesichert, global dedupliziert und über unveränderbare WORM-Tresore (Write Once, Read Many) bzw. S3-Object-Lock revisionssicher gegen Ransomware-Angriffe geschützt.

Technischer Architektur-Vergleich: VMware VCF Stack versus Proxmox VE & Ceph

Die nachfolgende Bloomberg-Radar-Matrix stellt die technischen Subsysteme von VMware Cloud Foundation den offenen Enterprise-Komponenten von Proxmox VE 8.x und Ceph gegenüber:

Vollkostenrechnung inklusive Swing-Hardware und 100-GbE-Fabric

Eine realistische Migrationskalkulation muss neben den Software-Subscriptions auch das initiale Start-Cluster (Swing-Hardware) berücksichtigen, das die ersten Migrationswellen aufnimmt, bevor bestehende ESXi-Server freigeräumt und neu installiert werden. Wir betrachten hierzu eine Referenzumgebung mit 24 Dual-Socket-Hosts (48 Sockel, 1.536 Cores) und 250 Terabyte nutzbarem NVMe-Speicher über 60 Monate.

Unter VMware Cloud Foundation (VCF) inklusive vSAN-Kapazitätslizenzen summieren sich die Lizenzgebühren über fünf Jahre auf rund 2,65 Millionen Euro. Auf der Proxmox-Seite kalkulieren wir die Anschaffung von vier neuen Dual-Socket-Startknoten mit Enterprise-PLP-NVMes und zwei redundanten 100-GbE-Switchen (140.000 Euro^*), externes Migrations-Engineering (60.000 Euro) sowie die Proxmox-Premium-Subscription für alle 48 Sockel über fünf Jahre (252.000 Euro).

Selbst inklusive der kompletten Neuanschaffung der 100-GbE-Fabric und der vier Start-Server liegen die Fünfjahresgesamtkosten bei lediglich 452.000 Euro. Das Unternehmen realisiert eine Netto-Einsparung von 2,19 Millionen Euro und modernisiert gleichzeitig seine Hardwarebasis. Weitere Vergleichsdaten liefert unser 5-Jahres-TCO-Vergleich zwischen Rechenzentrums-Eigenbetrieb und Hyperscalern.

Die Make-or-Buy Sourcing-Weiche und technische Audit-Sicherheit

Für die operative Durchführung der Migration und den anschließenden Regelbetrieb wählen IT-Leitungen je nach interner Linux-Kompetenz und Clustergröße zwischen drei klar abgegrenzten Bereitstellungsmodellen.

Erstens (Inhouse-Eigenbetrieb): Organisationen mit eigenem Linux-Engineering automatisieren das Cluster über den OpenTofu-Provider (bpg/proxmox) sowie Ansible und sichern sich über offizielle Hersteller-Subscriptions der Proxmox Server Solutions GmbH ab. Lediglich für das initiale Ceph-CRUSH-Map- und 100-GbE-Netzwerkdesign wird punktuell ein externer Senior-Architekt zur Design-Abnahme hinzugezogen.

Zweitens (Föderierter Betrieb): Große Unternehmensgruppen und öffentliche Rechenzentren mit hunderten Knoten, die neben KVM-Virtualisierung auch mandantenfähige Self-Service-APIs und automatisierte Kubernetes-Cluster benötigen, setzen auf standardisierte Open-Source-Cloud-Architekturen. Den Referenzrahmen hierfür beschreibt unser Leitfaden zum Sovereign Cloud Stack (SCS).

Drittens (Systemhaus-Migration): Mittelständische IT-Abteilungen beauftragen ein zertifiziertes europäisches Open-Source-Systemhaus mit der schlüsselfertigen Wellen-Migration und einem 24/7-Managed-Monitoring. Vertraglich wird festgelegt, dass sämtliche Ansible-Playbooks, Dokumentationen und Root-Zugänge jederzeit im Eigentum des Auftraggebers verbleiben.

Aus Sicht der internen Revision erfüllt diese Zielarchitektur sämtliche Prüfkriterien aus BSI IT-Grundschutz (SYS.1.5), BSI C5 und DORA^** Artikel 28. Durch LUKS- und ZFS-Verschlüsselung im Ruhezustand, feingranulares RBAC mit OpenID-Connect-Anbindung sowie unveränderbare WORM-Backups ist die Plattform ab dem ersten Tag voll auditierbar.

Der 4-Phasen-Ausführungsfahrplan für das Migrations-Engineering

Um den Übergang von Hunderten virtuellen Maschinen ohne Störung der Fachabteilungen abzuwickeln, gliedert sich das Migrationsprojekt in vier technisch klar voneinander abgegrenzte Phasen mit verbindlichen Abnahmekriterien.

Phase 1 (Woche 1 bis 4): Telemetrie-Erfassung, IOPS-Profiling und Netzwerk-Plumbing

Zunächst liest das Projektteam über RVTools sämtliche VM-Konfigurationen, VLANs und Spitzen-IOPS-Werte aus dem bestehenden vCenter aus. Parallel werden auf den Top-of-Rack-Switchen die getrennten VLANs für Corosync (MTU 1500) sowie für das Ceph-Public- und Cluster-Netzwerk (MTU 9000) eingerichtet und mittels iperf3 und omping auf Paketverlustfreiheit geprüft.

Phase 2 (Woche 5 bis 8): Inbetriebnahme des Swing-Clusters und Ceph-Benchmarking

Auf mindestens vier dedizierten Startknoten wird Proxmox VE 8.x installiert, das Corosync-Quorum aufgebaut und der Ceph-BlueStore-Pool auf Enterprise-PLP-NVMes initialisiert. Vor dem ersten VM-Import unterzieht das Team den Speicher-Pool einem mehrstündigen Benchmark mittels rados bench und fio (4k Random Write mit O_DIRECT) inklusive simuliertem Host- und Laufwerksausfall.

Phase 3 (Woche 9 bis 12): Massen-Rollout der VirtIO-Pakete und Pilot-Cutover

Auf allen Windows- und Linux-Quellsystemen werden automatisiert die VirtIO-Treiber und der QEMU-Guest-Agent vorinstalliert sowie die Registry-Startwerte für vioscsi verifiziert. Anschließend überführt das Team die ersten 20 bis 30 Test- und Staging-Systeme über den FUSE-Live-Importer und validiert das Backup- und Restore-Verhalten über den Proxmox Backup Server bzw. Veeam 12.2.

Phase 4 (Monat 4 bis 9): Rollierende Wellen-Migration und Host-Konvertierung

In fest eingeplanten Wartungsfenstern werden wöchentlich 30 bis 50 produktive virtuelle Maschinen umgeschaltet, auf VirtIO-SCSI-Single umgestellt und von den alten VMware Tools bereinigt. Jeder vollständig geräumte ESXi-Host wird anschließend frisch mit Proxmox VE installiert und samt seinen NVMe-Laufwerken in das wachsende Ceph-Cluster aufgenommen, bis das letzte vCenter abgeschaltet wird.

Fünf Kontrollfragen für Infrastruktur-Architekten und IT-Leitung

1. Erfüllen alle für Ceph vorgesehenen SSDs und NVMes die Hardware-PLP-Anforderung?

Prüfen Sie anhand der Hersteller-Datenblätter jedes Laufwerks, ob physische Stützkondensatoren (Power Loss Protection) verbaut sind. Sollten in Bestandsservern noch Consumer- oder Read-Intensive-SSDs ohne PLP stecken, dürfen diese keinesfalls für produktive Ceph-BlueStore-OSDs verwendet werden, sondern müssen vorab gegen Enterprise-Mixed-Use-NVMes getauscht werden.

2. Ist das Corosync-Cluster-Netzwerk physisch vom Ceph- und Backup-Traffic getrennt?

Vergewissern Sie sich im Netzwerk-Schaltplan, dass Corosync über einen eigenen physischen Netzwerkpfad (ring0) verfügt und einen zweiten unabhängigen Pfad (ring1) als Fallback nutzt. Eine gemeinsame Nutzung derselben Netzwerkkarte ohne strikte Hardware-Trennung führt bei Ceph-Recovery-Lastspitzen unweigerlich zu Quorum-Verlusten.

3. Wurde der Windows-Treiber vioscsi vor dem Cutover auf Boot-Start (Wert 0) geprüft?

Verlassen Sie sich bei hunderten Windows-Servern niemals allein darauf, dass das VirtIO-MSI-Paket installiert wurde. Führen Sie vor jedem Wartungsfenster einen automatisierten Pre-Flight-Check per PowerShell aus, der überprüft, ob der Treiber im Driver Store liegt und der Registry-Schlüssel für den Boot-Start aktiv ist.

4. Wie werden bestehende NSX-Firewall-Regeln in Proxmox-SDN-Security-Groups übersetzt?

Falls Sie VMware NSX zur Mikrosegmentierung einsetzen, sollten die vorhandenen Regelwerke frühzeitig per API exportiert und in standardisierte Proxmox-Firewall-Security-Groups sowie IP-Sets überführt werden. Testen Sie das BGP-EVPN-Peering zwischen den Proxmox-Exit-Nodes und Ihren Core-Routern intensiv unter Last, bevor kritische DMZ-Workloads umziehen.

5. Sind unveränderbare WORM-Backups auf dem Proxmox Backup Server vor der Migration aktiv?

Gerade während einer großen Infrastruktur-Umstellung ist eine lückenlose Rückfallebene Pflicht. Stellen Sie sicher, dass der Proxmox Backup Server (oder Ihr Veeam-12.2-Repository) bereits vor der ersten produktiven Migrationswelle vollständig eingerichtet ist und jede frisch importierte Maschine sofort nach dem Start gesichert wird.

Strategisches Fazit: Technische Exzellenz als Fundament der Lizenz-Unabhängigkeit

Die technische Ablösung von VMware vSphere, vSAN und NSX durch Proxmox VE 8.x, Ceph BlueStore und BGP-EVPN ist heute kein experimentelles Vorhaben mehr, sondern ein präzise beherrschbarer Standardprozess des modernen Rechenzentrums-Engineerings. Die Kombination aus vorbereitetem VirtIO-Treiber-Rollout und FUSE-gestütztem Live-Import reduziert die Umschaltzeiten pro System auf wenige Minuten.

Organisationen, die beim Aufbau ihrer Zielumgebung keine Kompromisse bei Enterprise-PLP-NVMes und einer sauberen 25/100-GbE-Netzwerktrennung eingehen, erhalten eine Infrastruktur, die proprietären Suiten in Ausfallsicherheit, I/O-Durchsatz und Automatisierbarkeit mindestens ebenbürtig ist. Gleichzeitig befreien sie ihr IT-Budget dauerhaft aus der Core-Lizenzspirale und sichern sich volle digitale Souveränität.

Häufig gestellte Fragen (FAQ) zur technischen Migration auf Proxmox VE und Ceph