© radututa / 123RF.com

Broadcom als neuer Herr im Hause VMware bläst seit Wochen zum Großangriff auf die Geldbeutel der Kunden. Denen kommt Proxmox als Alternative gerade recht: Es bietet vor allem mittelständischen Unternehmen den allergrößten Teil der benötigten Virtualisierungsfunktionen.

“Niemand wurde je gefeuert, weil er bei IBM gekauft hat”, so lautet ein Bonmot aus der IT-Industrie, das im Kern zutrifft und die Marktmacht von Big Blue adäquat beschreibt. Freilich lässt der Merksatz sich auch abwandeln: In Sachen Netzwerk gilt das Nämliche für Cisco oder Juniper, in Sachen Speicher für Netapp oder Dell-EMC. All diese Unternehmen haben in ihren jeweiligen Kerngebieten eine derart große Reputation angehäuft, dass Kunden beruhigt zu ihren Produkten greifen.

Auch beim Thema Virtualisierung gab es bisher einen Standardanbieter: VMware. Wer das Thema Virtualisierung schnell und gut erledigen wollte, kaufte vCenter, vSphere & Co. des Herstellers aus Palo Alto und konnte davon ausgehen, eine funktionale Lösung zu erhalten (Abbildung 1). VMware trug das Seinige bei und köderte Kunden mit attraktiven Konditionen und mancherlei kostenloser Dreingabe. Ein gutes Beispiel dafür ist ESXi, der Hypervisor im Kern von vCenter & Co., den VMware-Kunden bisher kostenlos nutzen durften.

Aus und vorbei: Seit der Chipriese Broadcom bei VMware das Zepter übernommen hat, gilt die Parole, die Kuh so gut wie möglich zu melken, solange sie noch Milch gibt. Gerade kleinere und mittelgroße VMware-Kunden erleben momentan fast täglich böse Überraschungen. Mit dem kostenlosen ESXi etwa ist es längst schon vorbei, verschiedene Partnerprogramme und Verträge für kleine Unternehmen sind bereits im Orkus verschwunden. VMware-Kunden, so darf man annehmen, wird man für dieselben Produkte wie bisher künftig deutlich umfassender zur Kasse bitten.

Gerade für KMUs kann das zum echten Problem werden: Tausende von Euro monatlich zusätzlich ohne wirtschaftlichen Mehrwert sind vielerorts einfach nicht im Budget. Der Vertreibung aus dem VMware-Paradies folgt der Lock-in-Kater: Vielerorts machen Administratoren, die bisher mit VMware gut gefahren sind, sich über das Thema Virtualisierung nun erstmals überhaupt umfassende Gedanken.

Abbildung 1: Lange galt VMware als unangefochtener Branchenprimus in Sachen Virtualisierung. Seit VMware zu Broadcom gehört, häufen sich aber die finanziellen Hiobsbotschaften, und Kunden suchen nach Alternativen wie Proxmox. Quelle: VMware

Erschwerend kommt hinzu, dass häufig die Zeit drängt, damit die gestiegenen VMware-Kosten das Unternehmen nicht in eine finanzielle Schieflage bringen. Ein Wiener Unternehmen weiß allerdings Rat: Proxmox bietet sein Proxmox VE (PVE [1]) seit vielen Jahren als VMware-Alternative an. Während mancher Enterprise-Admin die Nase rümpft, weil Proxmox nicht jede Funktion von VMware kopiert, liegt gerade für die Admins kleinerer und mittelgroßer Installationen in Proxmox eine echte Chance: Grundlegende Features wie die Hochverfügbarkeit von Instanzen oder die Anbindung externer Speicher stehen hier ebenso zur Verfügung wie beim großen Vorbild.

Außerdem basiert Proxmox vollständig auf quelloffener Software, als Hypervisor kommt Qemu im Gespann mit KVM zum Einsatz. Ein Lock-in-Effekt, der sich mit jenem bei VMware vergleichen ließe, ist hier gar nicht erst möglich. Sein technisches Paket garniert der Hersteller obendrein mit einer funktionalen grafischen Oberfläche. Darüber lassen sich in bester VMware-Manier virtuelle Instanzen anlegen, löschen und modifizieren. Grund genug, sich Proxmox genauer anzusehen: Was bietet die Lösung, worauf müssen Admins achten, und worin bestehen die großen Unterschiede zum (bald wohl einstigen) Branchenprimus?

Die Grundlagen

Wer mit Proxmox bisher noch gar keine Berührung hatte, stellt sich vermutlich die Frage, wie sich die Arbeit damit grundsätzlich anfühlt. Das ist flott erklärt: Auf der Homepage des Anbieters stehen ISO-Abbilder bereit, die sich auf einen USB-Stick kopieren und für die Installation eines Proxmox-Knotens nutzen lassen.

Unter der Haube werkelt bei Proxmox VE ein Debian GNU/Linux mit diversen zusätzlichen Paketen. Entsprechend fußt der Installer der Lösung im Kern auf der Installationsroutine von Debian, kommt aber stark vereinfacht daher. Nur die allerwichtigsten Details muss der Administrator bei der Proxmox-Installation angeben. Das umfasst die Einstellungen für das Netzwerk, das Root-Passwort sowie die Auswahl des Datenträgers, auf dem das Betriebssystem später laufen soll. Sind die Einstellungen erledigt, schreibt die Installationsroutine die jeweils aktuelle Proxmox-VE-Version routiniert auf die Platte und zeigt nach einem Neustart des Systems den Login-Prompt für root an. Alle grundlegenden Proxmox-Features stehen dann bereits zur Verfügung.

Gerade für Administratoren, die von VMware auf Proxmox umsteigen wollen, dürfte dabei das Web-UI von Proxmox mit am interessantesten sein (Abbildung 2). Es bietet durchaus viele mit vCenter aus vSphere vergleichbare Funktionen – dazu später noch mehr. Zuvor jedoch empfiehlt sich ein genauerer Blick unter die Proxmox-Haube, um dessen Funktionsumfang genauer kennenzulernen.

Abbildung 2: Dreh- und Angelpunkt der Systemadministration mit Proxmox ist dessen grafische Schnittstelle. Über sie lassen sich Instanzen erstellen, Ceph administrieren und die vorhandenen Daten verwalten. Quelle: Proxmox

In Sachen Aktualität ist die Software auf der Höhe der Zeit: Proxmox 8.1 basiert auf der aktuellen Debian-Version 12.2 “Bookworm” und bringt sogar einen aktuelleren Linux-Kernel als das Original, nämlich Linux 6.5, eine LTS-Version. Qemu 8.1.2 im Gespann mit der zum Kernel gehörenden KVM-Version, bietet in Sachen Virtualisierung alle grundlegenden Funktionen, die Administratoren brauchen. Unterstützung für Secure Boot gehört ebenso zum Lieferumfang wie das gesamte zu Debian GNU/Linux 12.2 gehörende Userland.

Schon das ist ein großer Vorteil von Proxmox: Die meisten Pakete aus dem Debian-Universum lassen sich darauf problemlos installieren, weil Proxmox VE eher eine Debian-Erweiterung als ein Debian-Derivat darstellt. Selbst wenn Proxmox VE also ein bestimmtes Tool oder eine bestimmte Funktion ab Werk nicht anbietet und unterstützt, lässt sie sich über den Umweg der Pakete für Debian “Bookworm” in der Regel leicht und unkompliziert nachrüsten. Dadurch verliert der Administrator nicht sofort den vollen Support für den Knoten, sofern er beim Hersteller kommerziellen Support erworben hat. Hier ergeben sich gerade im Vergleich mit den strengen, US-typischen Support-Regeln von VMware gewaltige Unterschiede: Dort wäre ein solches Vorgehen praktisch undenkbar.

Umfassender ZFS-Support

Zusätzlich zu den Standardkomponenten, die Proxmox VE aus Debian übernimmt, und der Proxmox-UI wirbt Proxmox mit einigen praktischen Zusatz-Features für sich. Eines betrifft die umfassende Integration des Dateisystems ZFS, also von OpenZFS. OpenZFS ist in der Linux-Community seit vielen Jahren eine Art Zankapfel: Es steht zwar unter den Bedingungen der CDDL, die gilt aber als zum Teil inkompatibel mit der GNU GPLv2, der der Linux-Kernel unterliegt. Linus Torvalds selbst lehnt es eben deshalb bis heute ab, OpenZFS in den offiziellen Linux-Kernel aufzunehmen, und das, obwohl ZFS als sehr stabiles Dateisystem mit vielen praktischen Funktionen wie integriertem Volume-Management und guter Performance gilt.

Bei Proxmox hat man weniger Berührungsängste: ZFS ist seit vielen Jahren fixer Bestandteil von Proxmox VE und gilt dort als “nativ unterstützter Speicher”. So nennt der Wiener Hersteller Speichermethoden, die in alle zentralen Proxmox-Komponenten und insbesondere in das Proxmox-UI integriert sind. Das bedeutet ganz konkret, dass sich Speicherlaufwerke etwa problemlos mit ZFS formatieren und verwalten lassen, und zwar direkt in Proxmox und direkt in der grafischen Oberfläche.

Volume-Handling ist gerade bei Virtualisierungslösungen schließlich eine sehr nützliche Funktion: Wer eine SSD mit 8 TByte in einem Compute-Knoten hat, wird sie nur selten einer einzelnen VM vollständig zur Verfügung stellen wollen. Stattdessen besteht der Wunsch, das große Laufwerk in kleinere logische Volumes zu zerlegen und diese als Root Disk für einzelne virtuelle Instanzen zu verwenden. Andere Virtualisierer setzen dafür auf den Logical Volume Manager LVM. Proxmox hat sich stattdessen dafür entschieden, ZFS in Proxmox VE zu integrieren und den dort enthaltenen Volume-Manager zu verwenden.

Allerdings spielt das für jene Proxmox-Kunden, die ihr System komplett über die grafische Oberfläche administrieren, sowieso kaum eine Rolle: Sie sehen relativ wenig vom technischen Teil, der im Hintergrund passiert. Versiertere Administratoren, die möglicherweise schon ZFS-Erfahrung haben, werden die ZFS-Integration aber zu schätzen wissen: Dank ihr stehen in Proxmox auch gespiegelte Volumes und Snapshots auf der Dateisystemebene zur Verfügung.

Die Gretchenfrage

Überhaupt, so merkt man bei der Arbeit mit Proxmox schnell, spielt bei Proxmox das Thema Storage eine enorme Rolle. Kein Wunder: In Virtualisierungsumgebungen ist der genutzte Speicher für die Inhalte der virtuellen Instanzen von zentraler Bedeutung, gerade auch in Sachen Performance. Ein lahmer Speicher sorgt schon von vornherein dafür, dass in Sachen Geschwindigkeit und Latenz bei den laufenden VMs kein Blumentopf zu gewinnen ist. Entsprechend umfassend präsentiert sich auch der Storage-Support in Proxmox.

Der allerdings ist eng mit dem Einsatzszenario verknüpft, das der Administrator mit Proxmox implementieren möchte. Auf der Hand liegt, dass die Storage-Optionen für jene Nutzer, die nur einen Proxmox-Knoten benötigen, übersichtlich bleiben. Hier stecken die Laufwerke für den Speicher der VMs direkt im Knoten; lokal konfiguriert Proxmox sie per ZFS und fertig. Solche Single-Host-Setups sind im Hinblick auf ihre Administration von überschaubarer Komplexität.

Sie haben andererseits den eklatanten Nachteil, dass der einzelne Proxmox-Host ohne Frage einen Single Point of Failure (SPoF) darstellt. Stirbt im betroffenen System das Netzwerk, das RAM, die Stromversorgung oder die Netzwerkkarte, gehen sämtliche virtuellen Instanzen offline. Selbst in Kleinstunternehmen stellt das in den meisten Fällen ein Problem dar, denn Business Continuity, die Fähigkeit also, den eigenen Laden am Laufen zu halten, spielt auch hier mittlerweile eine wichtige Rolle – oft sogar eine größere als in Konzernen.

Fällt in Großunternehmen einmal ein kritisches System aus, findet sich sicher irgendwo Ersatzhardware, zudem steht nicht gleich die Existenz der Firma auf dem Spiel, wenn ein kritischer Dienst einmal ein paar Stunden nicht funktioniert. Kleinstunternehmen und KMUs dagegen haben keinen Hardwarefundus, und mehrtägige Downtimes können dort durchaus großen finanziellen Schaden anrichten. Die Single-Node-Variante von Proxmox dürfte sich in den allermeisten Fällen also auf den Einsatz als Test- oder Staging-System beschränken.

Für alle Szenarien, in denen implizite Hochverfügbarkeit ein wichtiger Faktor ist, stellt Proxmox zwei Alternativen zur Verfügung. Die Proxmox-Dienste selbst lassen sich problemlos im Cluster betreiben (Abbildung 3), man kann einem bestehenden Proxmox-Knoten also ohne Einschränkungen zusätzliche Proxmox-Installationen hinzufügen. Die Konfiguration von Diensten wie Pacemaker übernimmt Proxmox dabei im Hintergrund selbstständig. Das umfasst auch das Deployment von Corosync, das sich um die Kommunikation der Cluster-Dienste kümmert.

Abbildung 3: Selbst Clustering stellt Proxmox nicht vor Herausforderungen. Sollen für Instanzen aber Failover-Setups entstehen, ist ein Netzwerkspeicher wie Ceph nötig, den Proxmox auf Wunsch nahtlos ausrollt. Quelle: Patrick Kennedy

Der neuralgische Punkt in diesem Setup ist dann allerdings der Speicher. Proxmox bietet dafür zwei Ansätze: Der erste fußt auf ZFS und nutzt dessen Replikationsfunktionen. Dabei kopiert ZFS die Inhalte eines Laufwerks periodisch auf einen zweiten Knoten. Weil ZFS Replikation nur zwischen zwei Hosts implementieren kann, beschränkt diese Vorgehensweise den Administrator implizit auf einen typischen HA-Cluster mit Failover-Szenarien von einem auf den anderen Knoten.

Das muss nicht zwingend ein Problem sein. Viele Unternehmen wollen sich mit der Komplexität von Clustern mit mehr als zwei Knoten ohnehin nicht befassen und entscheiden sich stattdessen für mehrere Cluster-Pärchen, die parallel zueinander laufen. Den Zuschnitt virtueller Instanzen auf Proxmox-Knoten muss der Administrator dann aber selbst festlegen, eine dynamische Migration zwischen beliebigen Knoten ist nicht möglich. Genau das ist meist aber auch keine Anforderung.

Wer volle Flexibilität benötigt, greift zum dritten Speicherszenario, das Proxmox mitbringt, und landet damit beim verteilten Objektspeicher RADOS, einem Bestandteil von Ceph.

Eingebautes Ceph

Tatsächlich bringt Proxmox einen vollständigen Setup-Mechanismus für Ceph ab Werk mit (Abbildung 4). Per Mausklick direkt aus dem Proxmox-UI heraus lässt sich ein kompletter RADOS-Cluster inklusive des RBD-Frontends ausrollen. Der dient danach als Backend-Speicher für virtuelle Instanzen in Proxmox. Der Clou: Wer auf Proxmox setzt, benötigt keines der anderen Ceph-Management-Frontends. Alle zentralen Einstellungen lassen sich stattdessen direkt aus Proxmox heraus vornehmen, inklusive Reparaturarbeiten. Wer möchte, kann sich aber selbstverständlich trotzdem auf einem der Knoten mit Ceph-Infrastruktur einloggen und dort die Kommandozeilenbefehle von Ceph nutzen, etwa »ceph« selbst.

Abbildung 4: Proxmox integriert in seinem UI ein komplettes Setup-Werkzeug für Ceph. Wer einen Vielknoten-Cluster mit nahtloser VM-Migration bauen möchte, gelangt so ans Ziel. Praktisch imitiert Proxmox mit Ceph … Quelle: Proxmox

Über die Vor- und Nachteile von Ceph hat das Linux-Magazin bei etlichen Gelegenheiten ausführlich berichtet. Fakt ist: Ceph ist nicht trivial, und Administratoren sollten zumindest ungefähr wissen, was sie tun, bevor sie die Lösung einsetzen. Wenn grundlegendes Ceph-Wissen vorhanden ist, spricht grundsätzlich aber nichts gegen seine Nutzung. In einem Punkt gibt es zwischen der Zwei-Knoten-Lösung mit ZFS und der Ceph-Variante aber signifikante Unterschiede, nämlich im Hinblick auf die Speicherlatenz. Wer Anwendungen betreibt, die auf niedrigste Latenzen angewiesen sind, fährt mit der ZFS-Variante vermutlich besser. Denn durch seinen CRUSH-Algorithmus gilt Ceph seit jeher als latenzlastig, und das kann verschiedenen Anwendungen wie Datenbanken schnell zum Verhängnis werden.

Für den durchschnittlichen Betrieb normaler Anwendungen sollten sich aber beide Ansätze grundsätzlich eignen. Proxmox ist hier durchaus Beeindruckendes gelungen: Durch die komplette Integration von Ceph und ZFS bietet die Lösung tatsächlich mehr Speicheroptionen als VMware und eignet sich praktisch als vollständige Alternative zu VMwares SDS-Lösung vSAN (Abbildung 5). Obendrein erlaubt Proxmox dank der nahtlosen Integration der beiden Speichertechniken den Bau passender Proxmox-Umgebungen für beinahe jede gewünschte Zielgröße. Über mangelnde Flexibilität können künftige Proxmox-Admins sich insofern sicher nicht beschweren.

Abbildung 5: … die Konkurrenz: vSAN ist ein zentraler Bestandteil von vSphere und dessen Lösung für Software Defined Storage. Ohne vCenter und ESXi ergibt die vSAN-Nutzung aber keinen Sinn. vSAN-Nutzer brauchen bei der Migration also eine Alternative, die Proxmox im Gepäck hat. Quelle: VMware

Die Nase rümpfen dürften allerdings Administratoren, die bereits bestehenden Speicher per iSCSI oder NFS anbinden wollen. Grundsätzlich unterstützt Proxmox das zwar. Das Debian unter der Haube bringt schließlich alle Werkzeuge mit, die nötig sind, um zum Beispiel iSCSI-LUNs lokal anzubinden. Von der Integration von iSCSI und dergleichen in das Proxmox-UI hat man sich allerdings bereits vor einiger Zeit verabschiedet. Dasselbe gilt für den moderneren iSCSI-Nachfolger NVME-oF. Zentrale Funktionen der Proxmox-UI wie das Handling von Snapshots lassen sich für iSCSI- und NVME-oF-Volumes mithin nicht verwenden. Über die Kommandozeile gibt es zwar einen Weg zum Ziel. Der ist aber nicht praktisch und auch nicht besonders anwenderfreundlich.

Ein zentraler Aspekt, der stets für VMware sprach, war schließlich die Tatsache, dass sich mit VMware Virtualisierung auch ohne tiefgreifende Kenntnisse der Linux-Systemadministration erreichen ließ. Wer nun also mit dem Gedanken spielt, auf Proxmox umzusteigen, wird nicht nur deshalb automatisch zum Linux-Profi. Wer in Sachen Linux und Kommandozeile nicht ganz sattelfest ist, tut insofern gut daran, sich auf eine der integrierten Speicherlösungen in Proxmox zu verlassen und etwa eine Hyperconverged Infrastructure (HCI) von Anfang an mit Ceph zu bauen. Gerade Administratoren, die ein neues Virtualisierungs-Setup als Zielplattform für eine Migration weg von VMware planen, sollten auf diesen Aspekt achten.

Ganz gleich übrigens, ob man sich für ein Single-Node-Proxmox, eine Variante mit zwei Knoten oder ein Setup auf Basis von Ceph mit mindestens drei Knoten entscheidet: Die Hardware für Speicherlaufwerke sollte von Anfang an zu diesen Anforderungen passen. Ein 1-Knoten-Setup sollte mindestens zwei Speicherlaufwerke identischer Größe haben, auf denen ZFS anschließend eine lokale Spiegelung für die Redundanz der Daten errichten kann. Wer lokal lieber auf Ext4 setzt, das als Alternative zu ZFS durchaus zur Verfügung steht, benötigt zusätzlich einen RAID-Controller in Hardware für echtes Hardware-RAID-1. Der kann bei ZFS entfallen, weil ZFS sich ohnehin selbst um die Redundanz seiner Daten kümmert.

Ceph-Setups sollten in den einzelnen Systemen ausschließlich HBAs anstelle von RAID-Controllern verwenden, weil Ceph die Redundanz der Daten hier komplett im Alleingang sicherstellt. Ein zusätzlicher RAID-Controller würde also nur höhere Kosten implizieren und mehr Aufwand verursachen, auf der RADOS-Seite aber nichts bringen. Ganz im Gegenteil: Mit Hardware-RAID läuft RADOS regelmäßig deutlich langsamer im Hinblick auf die verfügbare Bandbreite der Speicherlaufwerke als ohne.

Moderne Technologien

Administratoren dürfen mit Fug und Recht davon ausgehen, dass Proxmox die meisten modernen Funktionen unterstützt, die man von einem Virtualisierer gegenwärtig erwartet. Das umfasst die schon erwähnten Snapshots, mit denen sich der Status einer Instanz zu einem beliebigen Zeitpunkt festhalten lässt. Auch Hochverfügbarkeit stellt das Produkt wie beschrieben nicht vor große Herausforderungen. Die Auswahl der unterstützten Betriebssysteme ist endlos, eben weil KVM zum Einsatz kommt, das einen regulären Computer mit AMD64-Architektur emuliert. Exoten wie FreeBSD sind also ebenfalls kein Problem, auch nicht die verschiedenen Windows-Varianten.

Wichtig ist aber, dass für ein Betriebssystem der Qemu-Agent zur Verfügung steht und dann im Gast auch installiert ist. Er funktioniert so ähnlich wie die Open-VM-Tools für VMware: Er dient als eine Art Konfigurationsschnittstelle aus dem Host in die Instanz hinein. Darüber kann Proxmox einer Instanz etwa Befehle zum Neustart schicken. Obendrein liefert der Qemu-Agent diverse Metrikdaten aus der Instanz hin zur Außenwelt, und auch Konfigurationsparameter wie die gegebene IP-Adresse eines Systems gibt er weiter. Das führt etwa dazu, dass Proxmox diese Werte in der Übersichtsseite einer virtuellen Instanz überhaupt erst anzeigen kann.

Zentrale Voraussetzung dafür ist, dass der Administrator in der Konfiguration einen Haken neben der Option für den Qemu-Agenten setzt. Tut er das, sollte er den Agenten aber auch tatsächlich in der Instanz installieren, denn bei gesetztem Haken kommuniziert Proxmox bloß noch über den Agenten mit der Instanz. Alternative Wege wie klassische ACPI-Signale, wenn der Admin auf Ausschalten bei einer Instanz klickt, entfallen dann. Laufen Befehle an den Agenten jedoch ins Leere, weil er in der Instanz gar nicht vorhanden ist, schaltet beim Shutdown-Kommando Proxmox die Instanz nach spätestens fünf Minuten sonst einfach durch Beenden von Qemu ab. Ein solcher harter Shutdown beeinträchtigt schlimmstenfalls die Konsistenz des Dateisystems in der Instanz; der Administrator tut also gut daran, ihn nach Möglichkeit zu vermeiden.

Fernab von seinen Standardfunktionen punktet Proxmox mittlerweile auch bei modernen Technologien. Seit Proxmox 8 gibt es beispielsweise Unterstützung für Software-defined Networking. Bei SDN verlagert sich ein großer Teil jener Konfiguration, die auf Switches typischerweise VLANs und physische Netzwerktrennung einrichtet, in die Software der Virtualisierer. VXLAN, Open vSwitch, GRE und Konsorten sind allesamt Tunnel- und Verkapselungstechnologien, die dieselbe Funktion auf der Host-Seite implementieren, dabei aber direkt aus der Virtualisierung heraus steuerbar sind.

Soll eine neue virtuelle Instanz entstehen, die ein komplett autarkes VXLAN anstelle eines händisch mühsam konfigurierten VLANs mit eigenen, getaggten VLAN-Schnittstellen nutzt, klappt das bei Proxmox mittlerweile also komplett, ohne die Konfiguration eines Switches anzufassen. Freilich ist die Funktion eher für größere Unternehmen interessant, die intern mit verschiedenen Projekten und Mandanten hantieren und diese voneinander separieren wollen oder müssen. Die verfügbare SDN-Implementierung zeigt so implizit auch: Haftete Proxmox in der Vergangenheit oft noch der Ruf an, die billige Alternative zu VMware für jene zu sein, die sich das Original nicht leisten können, so ist das Produkt VMware mittlerweile in vielerlei Hinsicht ebenbürtig.

Freilich bietet Proxmox heute nicht jedes Detail in Sachen SDN, das VMware beherrscht. Erinnert sei daran, dass VMware sich vor etlichen Jahren NSX einverleibte, eine Firma, die an der Entwicklung von Open vSwitch maßgeblich beteiligt war und eine eigene, kommerzielle Distribution davon pflegte. Vergleichbare Manpower steht den Proxmox-Entwicklern schlicht nicht zur Verfügung. Das macht, ganz im Sinne des Pareto-Prinzips, aber auch nichts: Die allermeisten Unternehmen benötigten eine einfache SDN-Struktur, die auf der Softwareebene Paketströme lenken und voneinander trennen kann. Dazu ist Proxmox mittlerweile problemlos in der Lage.

Fazit

In Wien dürfte gerade eine angespannte Mischung aus freudiger Erwartung und mancher Sorge herrschen: Freude, weil Broadcom mit aller Gewalt daran arbeitet, den VMware-Kundenstamm zu dezimieren und die Verwendung der Software so unattraktiv wie möglich zu machen. Sorge, weil Proxmox damit vor einer Wachstumsphase stehen dürfte, die alles bisher in der Firmengeschichte Dagewesene in den Schatten stellen wird. Nie war der Bedarf für eine valide VMware-Alternative so groß wie heute, und nie war Proxmox technisch so ausgereift wie heute. Im Hinblick auf die Funktionen, die seine Entwickler für Proxmox versprechen, ist das Produkt über jeden Zweifel erhaben.

In den allermeisten Fällen dürfte sich ein lokales VMware-Setup mit überschaubarem Aufwand in ein funktionales Proxmox-Setup umwandeln lassen. Für bestehende VMware-Instanzen bietet Proxmox sogar eine Import-Funktion, die etwa den Datenträger konvertiert und als Laufwerk für eine neue Proxmox-Instanz verwendet. Das Ganze garniert der Hersteller mit einem Preismodell, das man bei VMware besonders mittlerweile für nachgerade lächerlich halten dürfte: Wer keinen kommerziellen Support benötigt, ist mit 130 Euro pro Knoten pro Jahr dabei. Wer gerade in der VMware-Falle steckt, sollte sich Proxmox also unbedingt genauer ansehen und eine Migration zeitnah angehen. (jcb)