Phillux als VMware-Alternative
Für Betriebe, die nach der Broadcom-Übernahme über vSphere und ESXi neu nachdenken: virtuelle Maschinen und Container auf eigener Hardware, Cluster mit Live-Migration — und bestehende ESXi-Gäste kommen in einem Schritt herüber.
Warum gerade jetzt so viele rechnen
Seit Broadcom VMware übernommen hat, ist das Lizenzmodell ein anderes. Unbefristete Lizenzen werden nicht mehr verkauft, es gibt nur noch Abonnements. Lizenziert wird nach physischen Prozessorkernen, mit einer Mindestabnahme je CPU — wer kleine Server betreibt, zahlt damit für Kerne, die er gar nicht nutzt. Die klassischen Pakete für kleinere Betriebe sind aus der Preisliste verschwunden, und das Partnerprogramm wurde deutlich ausgedünnt.
Für große Rechenzentren mit tief integrierter VMware-Landschaft ändert das wenig an der Rechnung. Für den Betrieb mit zwei oder drei Hosts sieht es anders aus: Dort steht bei der nächsten Verlängerung oft eine Zahl, die zur Größe des Aufbaus nicht mehr passt. Genau in dieser Lage lohnt es sich, Alternativen anzusehen — und Phillux ist eine davon.
Vorweg, damit hier niemand Zeit verliert: Wenn Ihr Aufbau auf vSAN, NSX oder automatisiertem DRS steht, ist Phillux nicht der passende Ersatz. Wo die Grenzen liegen, steht weiter unten ausdrücklich.
Was im Alltag anders ist
Drei Punkte, die auffallen, wenn man von vSphere kommt.
Ein Dienst statt eines Verbunds
Kein vCenter, das als eigene Appliance betrieben, gesichert und aktualisiert werden will. Phillux läuft als ein einzelner Dienst auf Debian: eine Datei, ein Autostart. Auf einem einzelnen Host heißt sichern, diese Datei zu kopieren. Der Cluster kommt dazu, wenn ein zweiter Server dazukommt — er ist nicht die Voraussetzung, um überhaupt anzufangen.
Windows 11 ohne Firmware-Vorbereitung
Windows 11 verlangt UEFI, aktives Secure Boot und ein TPM 2.0. In Phillux sind alle drei da, sobald ein Gast als Windows angelegt wird — es gibt keinen Schritt, in dem man Firmware, EFI-Datenträger und ein virtuelles TPM einzeln zusammensetzt. Die Installation läuft unbeaufsichtigt bis zum fertigen Desktop mit Administratorkonto durch, die virtio-Treiber sind bereits eingelegt.
Mehr zu Windows-Gästen
Container gehören dazu
LXC-Container stehen unter demselben Dach neben den virtuellen Maschinen, mit Grenzen für CPU und Arbeitsspeicher je Container und einem Terminal im Browser. Was für kleine Dienste keine ganze VM braucht, läuft als Container — ohne dass dafür ein zweites Produkt betrieben und lizenziert werden muss.
Phillux und VMware vSphere gegenübergestellt
Nur nachprüfbare Eigenschaften — die Zeilen, bei denen sich die beiden tatsächlich unterscheiden.
| Thema | Phillux | VMware vSphere |
|---|---|---|
| Lizenzmodell | Abonnement, ab 190 € im Jahr nach Größe der Maschine; Enterprise je 16 Kerne | Abonnement je physischem Kern, mit Mindestabnahme je CPU |
| Unbefristete Lizenz | Wird ebenfalls nicht angeboten — eine Lizenz je Server und Jahr | Wird nicht mehr verkauft; Bestandslizenzen laufen aus |
| Verwaltung | Ein Dienst auf dem Host, Weboberfläche inbegriffen | ESXi je Host, dazu vCenter als eigene Appliance |
| Container | LXC-Container gleichberechtigt neben VMs | Über Kubernetes-Dienste in den größeren Paketen |
| Windows-11-Gast | UEFI, Secure Boot und TPM 2.0 automatisch; unbeaufsichtigte Installation | Firmware, EFI-Datenträger und vTPM werden einzeln gesetzt |
| Cluster | Ab zwei Knoten, Konfigurationsabgleich über einen führenden Knoten | HA-, DRS- und Affinitätsregeln |
| Live-Migration | Über gemeinsamen OCFS2-Clusterspeicher | vMotion über gemeinsamen Speicher, auch ohne gemeinsamen Speicher möglich |
| Verteilter Speicher | Nicht vorhanden; gemeinsamer Speicher über OCFS2 | vSAN, in den größeren Paketen enthalten |
| Netzwerkvirtualisierung | Eigene virtuelle Netze und Bridges; Firewall je Gast | NSX mit Mikrosegmentierung, in den größeren Paketen |
| Betriebssystem | Debian 13, gewöhnliche Serverhardware | ESXi als eigener Hypervisor, Hardware-Kompatibilitätsliste beachten |
| Schnittstelle | REST-API, Dokumentation aus dem Programm selbst erzeugt | APIs und PowerCLI |
| Unterstützung | Direkt vom Hersteller — von den Leuten, die den Code geschrieben haben | Über Partner und Supportverträge; Fremdlösungen für Sicherung und Monitoring |
Wofür Phillux gebaut ist
Damit niemand einen Test beginnt, der nicht passen kann: Hier steht der Zuschnitt ausdrücklich — wofür Phillux gemacht ist, und wo sein Umfang endet.
- Ein bis eine Handvoll Hosts. Auf einem Server läuft Phillux ohne Clusterverbund; ab zwei Knoten kommt die Live-Migration dazu. Für zweistellige Hostzahlen mit Hochverfügbarkeitsgruppen und mehreren Standorten ist es nicht ausgelegt.
- Gemeinsamer Speicher über OCFS2, Firewall je Gast. Verteilter Speicher über viele Knoten und Mikrosegmentierung im Sinne von NSX gehören nicht zum Umfang. Wer heute auf vSAN, NSX oder automatisiertem DRS aufbaut, gäbe beim Wechsel Funktionen auf, statt sie zu ersetzen — dafür ist Phillux nicht der Ersatz.
- Was am Gast hängt, gehört vorher geprüft. Sicherungslösungen, Monitoring und Herstellersupport für Fremdsoftware setzen mitunter eine bestimmte Plattform voraus. Diese Kette klärt man besser vor dem Test als danach.
- Auflagen entscheiden die Frage vor uns. Wo ein Prüfer oder ein Rahmenvertrag eine bestimmte Plattform vorschreibt, ist nichts zu vergleichen.
- Kommerziell lizenziert, eine Lizenz je Server und Jahr. Ab 190 € je nach Größe der Maschine, mit Lizenzvertrag.
Bleibt Ihr Aufbau in diesem Rahmen — ein bis eine Handvoll Hosts, Windows- und Linux-Gäste, ein Betrieb, der einfach sein soll —, ist Phillux für genau diese Größe gebaut.
Bestehende ESXi-Gäste übernehmen
Ein Wechsel bedeutet nicht, alles neu aufzusetzen. Phillux wird auf eine ESXi-Quelle gerichtet und holt den Gast herüber: Platten, Ausstattung und Netz in einem Schritt. Es ist derselbe Ablauf wie beim Anlegen einer neuen virtuellen Maschine, nur mit einer bestehenden Maschine als Ausgangspunkt statt einer leeren. Derselbe Weg funktioniert für Proxmox.
Ein sinnvoller Ablauf
- Einen Server mit Debian 13 aufsetzen — oder das Installationsmedium nehmen, das Debian und Phillux unbeaufsichtigt einrichtet.
- Zwei, drei unkritische Gäste aus ESXi übernehmen und im Alltag laufen lassen.
- Prüfen, was daran hängt: Sicherung, Monitoring, Fernzugriff, Lizenzen der Gastsysteme.
- Erst danach entscheiden, ob der Rest folgt — die alte Umgebung läuft in der Zwischenzeit weiter.
Der Testzeitraum läuft einen Monat, ohne Registrierung und ohne dass Funktionen zurückgehalten werden. Das reicht, um die Rechnung mit echten Maschinen statt mit Datenblättern zu machen.
Häufige Fragen zum Umstieg von VMware
Kann ich meine VMs aus VMware ESXi übernehmen?
Ersetzt Phillux vCenter?
Gibt es einen Ersatz für vSAN oder NSX?
Läuft Phillux auf meiner vorhandenen Serverhardware?
Wie wird Phillux lizenziert?
Was passiert, wenn der Server keine Internetverbindung hat?
Wie unterscheidet sich Phillux von Proxmox VE?
Weiterlesen
Die Rechnung selbst machen?
Einen Monat lang vollständig testen — ohne Registrierung, ohne dass etwas zurückgehalten wird.
Jedes Thema auf einer eigenen Seite
Vierzehn Seiten, jede aus dem geschrieben, was das Programm wirklich tut — samt der Stellen, an denen es aufhört.
