Proxmox oder ESXi im Homelab

Einen Hypervisor zu wählen ist, als suche man einen Vermieter für seine virtuellen Maschinen aus. Manche sind großzügig, manche ändern die Bedingungen, und bei allen gilt: Eine eigene Kopie der Schlüssel solltest du behalten.

Kurz gesagt

Beide taugen für ein Homelab. ESXi hat eine kostenlose Ausgabe, aber nur bis Version 8.0 Update 3e, mit harten Grenzen und ohne Hersteller-Support, und dein Server steht womöglich nicht mehr auf der Hardwareliste. Proxmox VE ist quelloffen, ohne Bezahlung voll nutzbar und bringt Backup-Werkzeuge mit. Egal, wofür du dich entscheidest: Ein Snapshot ist kein Backup, und einen Umzug probierst du zuerst mit einer Wegwerf-VM aus.

So funktioniert’s

1. Die Aufgabe des Hypervisors. Ein Hypervisor teilt einen physischen Rechner in mehrere virtuelle auf. Die Grundlagen haben wir im Guide „Virtualisierung und Hypervisor“ (unter „Passt dazu“ verlinkt) erklärt und wiederholen sie hier nicht. Dieser Artikel setzt dort an: Welches Produkt läuft, wie sicherst du die VMs, und wie wechselst du von einem zum anderen?
2. ESXi-Lizenz, Stand 18. Okt. 2026. Broadcom hat mit ESXi 8.0 Update 3e einen kostenlosen Hypervisor zurückgebracht (Release Notes vom 10. Apr. 2025). Laut Broadcoms Wissensdatenbank erlaubt die freie Lizenz bis zu zwei physische CPUs und acht virtuelle CPUs pro VM. Sie lässt sich nicht über vCenter verwalten, hat kein vMotion, kein DRS, kein HA und keine Sicherung über die Backup-Schnittstelle des Herstellers, und sie kommt ohne Support. Für den Download brauchst du ein kostenloses Konto im Broadcom Support Portal. Broadcoms FAQ zu Version 9.0 sagt, dass mit 9.0 keine freie ESX-Version erscheint, freie Versionen bis 8.0 Update 3 aber herunterladbar bleiben. Wir haben keine Quelle gefunden, die das widerlegt, und Broadcoms Build-Liste zeigt 9.1-Veröffentlichungen bis zum 12. Okt. 2026. Laut Broadcom endet der allgemeine Support für ESXi 8.x am 11. Okt. 2027. Die freie Ausgabe ist also eine Lizenz, kein Versprechen auf langfristige Updates. Ein Widerspruch ist wissenswert: Der Wissensdatenbank-Artikel nennt die Software produktionsreif, die Release Notes beschreiben das freie Angebot dagegen als für den Nicht-Produktiv-Einsatz gedacht. Im Homelab spielt das selten eine Rolle. Verdient dein Lab Geld, lies die Bedingungen selbst oder frag eine Fachperson.
3. Proxmox-VE-Lizenz. Aktuell ist die Reihe Proxmox VE 9.2, erschienen am 21. Mai 2026 und auf Debian 13 aufgebaut. Das Admin-Handbuch mit Datum 24. Sep. 2026 trägt die Version 9.2.13. Der Quellcode steht unter der GNU AGPLv3, und das Projekt erklärt, alle Funktionen seien kostenlos nutzbar. Ein Abonnement bringt Zugang zum Enterprise-Repository, das für den Produktivbetrieb empfohlen wird, und in den bezahlten Stufen Hersteller-Support. Jeder Cluster-Knoten braucht ein eigenes Abonnement. Eine frische Installation zeigt auf das Enterprise-Repository, deshalb scheitern Updates ohne Schlüssel, bis du auf das No-Subscription-Repository umstellst. Die Dokumentation nennt dieses geeignet für Tests und den Nicht-Produktiv-Einsatz. Preise nennen wir nicht, weil wir keine datierte Preisseite abgerufen haben.
4. Backup, zwei Welten. Proxmox VE hat ein eingebautes Werkzeug, vzdump, das vollständige Backups von VMs und Containern schreibt, auch während sie laufen. Der optionale Proxmox Backup Server (PBS) geht weiter. Er zerlegt Daten in Blöcke, speichert jeden Block nur einmal (Deduplizierung), schickt nach dem ersten Lauf nur Änderungen und prüft die Integrität mit SHA-256-Prüfsummen. Backups lassen sich schon auf dem Client mit AES-256-GCM verschlüsseln, bevor sie den Host verlassen. Auch PBS steht unter der AGPLv3. Bewahre deinen Verschlüsselungsschlüssel nicht im Backup selbst auf: Die Dokumentation beschreibt genau dafür einen Master-Schlüssel und eine ausgedruckte Kopie. Unter ESXi nutzen Backup-Werkzeuge meist die Backup-Schnittstelle des Herstellers, und die freie Lizenz enthält sie nicht. Es bleiben einfachere Wege: VMs exportieren, die VM-Dateien bei ausgeschalteter VM kopieren oder einen Backup-Agenten im Gast laufen lassen. Das funktioniert, ist aber langsamer und mehr Handarbeit. Das ist ein echtes Argument für Proxmox im Lab, aber kein entscheidendes.
5. Ein Snapshot ist kein Backup. Ein Snapshot hält Änderungen an einer Platte fest und liegt auf demselben Speicher wie die Platte. Fällt dieser Speicher aus, sind beide weg. Broadcoms Hinweise sagen: Snapshots nicht als Backup nutzen, einen einzelnen Snapshot höchstens 72 Stunden behalten und nur zwei oder drei verketten. Dieselbe Logik gilt unter Proxmox: Ein Snapshot auf demselben Pool schützt dich vor einem misslungenen Update, nicht vor einer toten Platte. Ein Backup ist eine getrennte Kopie auf getrenntem Speicher, die du mindestens einmal zurückgespielt hast.
6. Umzug von ESXi zu Proxmox. Proxmox VE hat einen Import-Assistenten. Du fügst den ESXi-Host als Speicher vom Typ „ESXi“ hinzu, wählst eine VM und importierst sie. Das Wiki nennt Grenzen. Das Werkzeug wurde zum Zeitpunkt der Doku mit ESXi 6.5 bis 8.0 getestet, ESXi 9 deckt diese Aussage also nicht ab. VMs auf vSAN, verschlüsselte Platten und der Zustand des virtuellen TPM lassen sich nicht übernehmen, und Snapshots bremsen den Import. Die Quell-VM muss vorher heruntergefahren sein. Eine Live-Import-Option startet die VM früher, während Daten noch kopiert werden. Ob der Assistent gegen einen Host mit freier Lizenz funktioniert, deren Verwaltungs-Schnittstelle Broadcom bestenfalls als schreibgeschützt beschreibt, konnten wir nicht prüfen. Teste es also. Passt der Assistent nicht, bleiben die manuellen Wege: ein OVF-Export mit ovftool plus qm importovf oder qm disk import für VMDK-Dateien. Windows-Gäste brauchen VirtIO-Treiber, oder du hängst die Platte zunächst als IDE oder SATA an.
7. Hardware-Kompatibilität. Das erwischt Homelab-Betreiber oft. In der abgerufenen HPE-Matrix erscheint die DL360 für ESXi 8.0 und 9.x ab Gen10, einen Gen9-Eintrag haben wir nicht gefunden. Broadcoms CPU-Seite führt die Xeon-E5-2600-v4-Reihe, die in Gen9-Servern stecken kann, für 9.x als eingestellt: Der Installer bricht ab. Ein älterer Server läuft womöglich inoffiziell mit ESXi 7 oder 8, kann aber nicht auf Hersteller-Support zählen. Proxmox VE verlangt eine 64-Bit-CPU mit Intel VT oder AMD-V. Es rät außerdem davon ab, ZFS und Ceph auf einem Hardware-RAID-Controller zu betreiben, was bei alten Servern mit RAID-Karte wichtig ist.
8. Entscheidungshilfe. Nimm ESXi, wenn du genau die Werkzeuge des Herstellers brauchst, deine Hardware auf der Liste steht und du die Grenzen der freien Ausgabe akzeptierst. Nimm Proxmox VE, wenn dein Server älter ist, du eingebautes Backup und eine offene Lizenz willst und mit einem Linux-basierten System leben kannst. Bist du unsicher, installier das andere Produkt ein Wochenende lang auf einem Ersatzrechner. Kein Produkt gewinnt in jedem Lab.

Ein Homelab-Beispiel

Was wir belegen können: In unserem Homelab bei Bytearium läuft ESXi auf einem HPE DL360 Gen9, mit einer Docker-VM und einer Arbeits-VM (Stand der Angabe: 14. bis 18. Okt. 2026). ESXi-Version und Lizenzart haben wir nicht erfasst. Mehr behaupten wir nicht. Das hier ist kein Umzugsbericht: Nichts unten beschreibt Arbeit, die wir erledigt haben.

Ein allgemeiner Ablauf: Bei diesem Aufbau ist der erste Schritt, herauszufinden, was installiert ist. In der ESXi-Shell geben vmware -vl und esxcli system version get die Version aus, und die Lizenzseite des Hosts zeigt, ob es die freie Ausgabe ist. Zweiter Schritt: Prüfe die oben genannten Kompatibilitätsseiten für dein genaues Modell und deine CPU. Dritter Schritt: Liste die VMs mit vim-cmd vmsvc/getallvms auf und such vergessene Snapshots mit vim-cmd vmsvc/snapshot.get <vmid>. Vierter Schritt ist das Backup, das du noch nicht hast, und es gehört auf die ESXi-Seite, vor jeden Import. Fahr die VM herunter und kopiere sie auf Speicher außerhalb des Hosts, über einen der Wege aus Abschnitt 4. Der eine ist ein Export mit VMwares OVF Tool; dessen Handbuch zeigt die Form ovftool vi://<benutzer>@<host>/<pfad zur VM> /mnt/backup/<vm>.ovf. Der andere ist eine Kopie der VM-Dateien aus dem Datastore, während die VM aus ist. Ob der Export gegen einen Host mit freier Lizenz funktioniert, konnten wir nicht prüfen; klappt er nicht, nimm die Dateikopie. Prüfe, ob die Kopie vollständig ist, und räume erst danach alte Snapshots auf. Diese Kopie und die unveränderte Quell-VM sind dein Rückweg. Fünfter Schritt ist ein Test-Import der unwichtigsten VM, mit dem Assistenten oder mit qm importovf 100 Server.ovf local-zfs. Der sechste Schritt passiert auf der Proxmox-Seite, nach dem Import. Die Dokumentation zeigt diese Form eines Backup-Befehls: vzdump 777 --mode snapshot --dumpdir /mnt/backup, wobei 777 die Gast-ID ist, und qmrestore mit dem Archiv und einer neuen ID wie 601 spielt es als neue VM zurück. Das prüft das Ziel: Es zeigt, dass sich die importierte VM sichern und wiederherstellen lässt. Das ESXi-Backup aus Schritt vier ersetzt es nicht. Erst wenn die importierte VM bootet, Netzwerk hat und diese Wiederherstellung übersteht, fasst du die zweite an, und erst dann entfernst du die Quell-VM aus ESXi.

Prüfliste

• Prüfe, welche ESXi-Version und welche Lizenz dein Host nutzt, bevor du einen Vergleich liest.
• Prüfe die Kompatibilitätsseiten der Hersteller für dein genaues Servermodell und deine CPU, nicht nur für die Produktlinie.
• Prüfe, ob die Grenzen des freien ESXi (zwei CPUs, acht vCPUs pro VM, kein vCenter, keine Backup-Schnittstelle) zu deinem Vorhaben passen.
• Entscheide, welches Proxmox-Repository du nutzt, und notiere, dass das No-Subscription-Repository für den Nicht-Produktiv-Einsatz gedacht ist.
• Sichere die Quell-VM unter ESXi vor dem Import auf getrennten Speicher (OVF-Export oder Dateikopie bei ausgeschalteter VM), und räume alte Snapshots erst auf, wenn diese Kopie vollständig ist.
• Bewahre den Backup-Schlüssel außerhalb des Backups auf und spiele eine VM aus dem Backup zurück, um zu beweisen, dass es funktioniert.
• Entferne die VMware Tools und notiere vor dem Umzug die Netzwerkeinstellungen und den BIOS- oder UEFI-Modus des Gasts.
• Migriere zuerst eine Wegwerf-VM und lass die Quell-VM aus, solange die Kopie läuft.
• Sichere die neue VM nach dem Import mit vzdump und spiele sie testweise unter einer neuen ID zurück; behalte die Quell-VM unter ESXi, bis dieser Test bestanden ist.
• Prüfe danach Netzwerkadapter, Treiber (VirtIO bei Windows), Boot-Reihenfolge und den Gast-Agenten.