Bereits Kunde? Jetzt einloggen.
Lesezeit ca. 13 Min.

Der Xen-Hypervisor XCP-ng: Der Thronfolger


Linux Magazin - epaper ⋅ Ausgabe 3/2020 vom 06.02.2020

Xen gilt als Hypervisor-Pionier unter Linux, auch wenn KVM ihm im Laufe der Zeit den Rang abgelaufen hat. XCP-ng will als Thronfolger den Glanz alter Tage zurückbringen. Funktioniert das?


Artikelbild für den Artikel "Der Xen-Hypervisor XCP-ng: Der Thronfolger" aus der Ausgabe 3/2020 von Linux Magazin. Dieses epaper sofort kaufen oder online lesen mit der Zeitschriften-Flatrate United Kiosk NEWS.

Bildquelle: Linux Magazin, Ausgabe 3/2020

© Andrey Kiselev, 123RF

Wer, wie der Autor dieser Zeilen, bereits ein paar Lenze in der IT hinter sich gebracht hat, erinnert sich zweifellos an Xen: Im vorletzten Jahrzehnt war dieser Hypervisor ein Hype-Thema in der Linux-Welt, weil mit ihm zum ersten Mal ein Open-Source-Hypervisor verfügbar war, der obendrein nicht von VMware stammte. Virtualisierung war seinerzeit als Konzept noch nicht so verbreitet wie heute, ...

Weiterlesen
epaper-Einzelheft 5,99€
NEWS 14 Tage gratis testen
Bereits gekauft?Anmelden & Lesen
Leseprobe: Abdruck mit freundlicher Genehmigung von Linux Magazin. Alle Rechte vorbehalten.

Mehr aus dieser Ausgabe

Titelbild der Ausgabe 3/2020 von Für und Wider. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Für und Wider
Titelbild der Ausgabe 3/2020 von News. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
News
Titelbild der Ausgabe 3/2020 von Zahlen & Trends. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Zahlen & Trends
Titelbild der Ausgabe 3/2020 von Weshalb Edge Computing nötig und wie es realisierbar ist: Rechnen im Außendienst. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Weshalb Edge Computing nötig und wie es realisierbar ist: Rechnen im Außendienst
Titelbild der Ausgabe 3/2020 von Edge in der Operational Technology: Leicht hinterher. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Edge in der Operational Technology: Leicht hinterher
Titelbild der Ausgabe 3/2020 von Interview mit „State-of-the-Edge“-Herausgeber Matt Trifiro: „Edge ist ein Ort“. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Interview mit „State-of-the-Edge“-Herausgeber Matt Trifiro: „Edge ist ein Ort“
Vorheriger Artikel
Aus dem Alltag eines Sysadmin: Darkstat: Rüstiger Methusalem
aus dieser Ausgabe
Nächster Artikel Eine eigene Suchmaschine bauen (Teil 5): Suchaktion
aus dieser Ausgabe

Wer, wie der Autor dieser Zeilen, bereits ein paar Lenze in der IT hinter sich gebracht hat, erinnert sich zweifellos an Xen: Im vorletzten Jahrzehnt war dieser Hypervisor ein Hype-Thema in der Linux-Welt, weil mit ihm zum ersten Mal ein Open-Source-Hypervisor verfügbar war, der obendrein nicht von VMware stammte. Virtualisierung war seinerzeit als Konzept noch nicht so verbreitet wie heute, stand aber durchaus schon auf der Wunschliste vieler Admins. Mit Xen waren echte virtuelle Maschinen unter Linux machbar: Man bootete einfach in einen speziellen Kernel, der einem die Domain 0 zur Verfügung stellte und auf dem der eigentliche Xen-Hypervisor lief. Wo Licht ist, gibt es auch Schatten: Die Funktion Paravirtual Operations (PVops) im Linux-Kernel existierte seinerzeit noch nicht. Wollte ein Hypervisor also mit dem Kernel kommunizieren, musste er diesem erst einmal beibringen, wie das funktioniert. Die Xen-Entwickler taten das in Form eines riesigen Patches, dessen Pflege angesichts der schnellen Linux-Entwicklung allerdings von Anfang an als aussichtsloses Unterfangen gelten musste.

Der Autor

Martin Gerhard Loschwitz ist Cloud Platform Architect bei Drei Austria und beschäftigt sich dort unter anderem mit OpenStack, Kubernetes und Ceph.

Aus der Zeit gefallen

Bald kam Xen deshalb unter die Räder: Wer einen aktuelleren Kernel als 2.6.18 brauchte, der konnte Xen nicht mehr nutzen. Zu dieser Zeit trat KVM auf den Plan, und nachdem PVops endlich in den Kernel integriert war, zog auch KVM mit wehenden Fahnen in die Linux- Quellen ein. Um Xen hingegen wurde es still: Citrix kaufte die Reste der kom- merziellen Angebote rund um den Hypervisor, allen voran XenServer, und betreute die vorhandenen Kunden. Gleichzeitig machte man sich allerdings auch daran, Xen weiterzuentwickeln. Mittlerweile funktioniert das Urgestein wieder bestens mit jedem aktuellen Linux-Kernel, es ist in diesen sogar integriert.

Die Macht von Open Source

Noch immer bietet Citrix den Citrix Hypervisor als Xen-basiertes Produkt an; es gibt auch eine abgespeckte freie Variante. Sie genügt manchen Xen-Fans in der Community aber offensichtlich nicht: In Form von XCP-ng [1] betritt ein Xen-basierter Hypervisor als Fork von XenServer die Bühne, der künftig mit den Lösungen von Citrix um Kunden wetteifern möchte. Welche Features bietet XCP-ng? Worin unterscheidet es sich von XenServer, und ist es eine valide Alternative zu KVM und Konsorten?

Bevor es an die technischen Details geht, lohnt es sich, noch einen genauen Blick auf die Motivation der Entwickler zu werfen - daraus ergeben sich die Gründe für manche Designentscheidung, die XCP-ng durchlaufen hat. Citrix bietet sein Produkt Hypervisor (früher: XenServer) in einer kommerziellen und einer freien Version an. Es enthält jedoch viel mehr als bloß den blanken Hypervisor.

Zur Erinnerung: Hypervisor bezeichnet ja im Grunde nur die zwischen Betriebssystem und Hardware liegende Verwaltungsschicht, die die Virtualisierung ermöglicht. Xen unterscheidet sich hier als echter Klasse-1-Hypervisor deutlich von KVM: Alle gestarteten Xen-Domänen (also Instanzen) sind dem eigentlichen Hypervisor unterstellt. Die Domain 0 (»dom0«) ist lediglich deshalb speziell,

weil sie den Xen-Hypervisor steuern kann und darf. Drumherum gibt es in XenServer allerlei praktische Verwaltungswerkzeuge, etwa ein GUI. An der Funktionalität scheitert es beim Citrix Hypervisor also nicht (Abbildung 1).

Das Problem: Citrix hat den Umfang der freien Edition (Abbildung 2) von XenServer in den vergangenen Jahren sehr oft verändert. Regelmäßig wanderten Funktionen aus der freien Version ersatzlos in die Kommerzvariante, darunter sehr wichtige Features wie die Möglichkeit, verschiedene Storages anzubinden. So entstand bei vielen Beobachtern der Eindruck, Citrix wolle sein Geld lieber mit den lukrativen virtualisierten Desktop- Produkten verdienen und aus Xen- Server lediglich so viel Umsatz wie irgend möglich herausquetschen. Für Admins ist das freilich völlig inakzeptabel, da es jegliche Planungssicherheit zunichte macht.

Game over

Den sprichwörtlichen Vogel schoss Citrix Mitte 2017 ab, als das Unternehmen praktisch von heute auf morgen weitere relevante Enterprise-Funktionen aus der freien in die Bezahlversion verlegte. Dazu zählte unter anderem die Möglichkeit, virtuelle Maschinen hochverfügbar zu betreiben. Die damals veröffentlichte Version 7.3 konnte in der freien Variante zudem nur noch drei Hosts als Virtualisierungsziel verwalten.

In der Community regte sich daraufhin heftiger Protest, der zu dem erwartbaren Resultat führte: Einige Firmen und private Entwickler schlossen sich zusammen und begannen auf Basis des vorhandenen Codes, eine Alternative zu bauen, die stets alle Features bieten sollte. Geld will man über den Verkauf von Support und Unterstützung verdienen.

Nicht nur das Lizenzierungsmodell von XCP-ng unterscheidet sich aber ganz maßgeblich vom Vorbild, auch technisch gibt es zwischen den Produkten mittlerweile einige Unterschiede. Fast wichtiger als diese ist aber eine Gemeinsamkeit.

Die API bleibt kompatibel

XenServer verfügt seit Jahren über eine eigene API, über die sich die laufenden Domains innerhalb eines XenServer-Clusters verwalten lassen. Hier war Xen Vorreiter; dass ein Dienst eine zentrale API bietet, die per REST-Schnittstelle alle relevanten Funktionen exponiert, ist ja nichts Neues. Als XenServer damit an den Start ging, war dieses Prinzip aber noch nicht annähernd so weit verbreitet wie heute. An der Kompatibilität der XenServer- API wollen die XCP-ng-Entwickler nichts ändern. Das bedeutet auch, dass sämtliche externen Werkzeuge und Programme, die es für XenServer gibt, mit den XCP-ng- Varianten ebenfalls zusamm enspielen.

Abbildung 1: Xen ist ein typischer Klasse-1-Hypervisor und funktioniert nach dem Domänen-Prinzip. Die Domäne 0 darf den Hypervisor konfigurieren.


Davon könnte etwa OpenStack profitieren, denn dessen Virtualisierungsmanager Nova verfügt über einen XenAPI-Treiber, über den sich Xen-VMs steuern lassen. Halten die XCP-ng-Entwickler ihr Versprechen, lässt sich in einem Setup jederzeit XenServer (oder Citrix Hypervisor) per Dropin durch XCP-ng ersetzen. Am Tooling des Admins ändert sich nichts, und auch OpenStack oder andere Produkte müssen keinen separaten Support für XCP-ng einbauen. Hier beweisen die Entwickler Weitblick. Darüber hinaus ergeben sich zwischen den Produkten mittlerweile aber ganz selbstverständlich Änderungen. XCP-ng will letztlich die Anwender von sich überzeugen, indem es mehr und bessere Features bietet als der große Bruder von Citrix. Dabei geben die Entwickler sich einige Mühe.

Mehr Knoten

So fiel zum Beispiel die künstliche Beschränkung der unterstützten Hypervisor- Hosts dem Eifer der Entwickler sehr zügig zum Opfer. Dazu muss man sich vorstellen, dass XenServer und XCPng ihre Rolle deutlich breiter auslegen, als KVM es je getan hat. Letzteres sieht seine Aufgabe darin, den Betrieb von VMs auf Linux-Systemen überhaupt zu ermöglichen. XCP-ng und seine Vorgänger wollen komplementär dazu auch Verwaltungswerkzeug für die virtuellen Maschinen sein.

Eine einzelne Instanz von XCP-ng kann dabei auch mehrere physische Hosts nicht nur verwalten, sondern sogar virtuelle Maschinen zwischen ihnen verschieben und Hochverfügbarkeit dafür konfigurieren. Das macht das Produkt besonders für kleinere Unternehmen interessant, die nach einer unkomplizierten Virtualisierungslösung suchen. In der jüngeren Vergangenheit landeten nicht wenige davon bei OpenStack und holten sich damit sehr viel oft gar nicht notwendigen Overhead in ihr Setup. In XCP-ng klettert die Zahl der unterstützten Zielknoten auf das technische Maximum von 16, was für kleine Virtualisierungsumgebungen ausreichen dürfte.

GUI und Konsole

Das Versprechen, mit Citrix Hypervisor so kompatibel wie irgend möglich zu bleiben, halten die XCP-ng-Entwickler auch ein, wenn es um das Frontend geht. Dem Admin stehen zwei prinzipielle Wege offen, die Lösung zu steuern: Auf der Kommandozeile existiert das schon vom XenServer bekannte Werkzeug Xconsole (Abbildung 3). Wer damit bereits in der XenServer-Version gearbeitet hat, muss auch in XCP-ng keine nennenswerten Schwierigkeiten befürchten.

Abbildung 2: Citrix Hypervisor (oder XenServer, wie das Produkt bisher hieß) war lange der Monopolist in Sachen Xen-basierte Produkte.


© Citrix

Eine weitere Möglichkeit, um Domänen und Xen-Hosts zu verwalten, offeriert ein grafisches Interface. Für diesen Zweck wurde (ursprünglich für XenServer) das Program XenAdmin entwickelt. Die Software steht nun steht in einer an den Fork angepassten Variante auch für XCPng zur Verfügung. Beim Umstieg von Citrix Hypervisor auf XCP-ng entsteht aus diesem Grund so gut wie kein erwähnenswerter Schulungsaufwand. Das ist gerade für kleine und mittlere Unternehmen ein nicht zu unterschätzender Vorteil (Abbildung 4), wenn sie sich daran wagen wollen, von Citrix Hypervisor zum neuen XCP-ng zu migrieren.

Abbildung 3: Alte Bekannte: Wie XenServer kommt auch XCP-ng mit dem Kommandozeilen-Frontend Xsconsole daher, über das es sich steuern lässt.


© Olivier Lambert

Schlaue Speicherverwaltung

Wer bei DMC instinktiv an eine ehemalige US-amerikanische Hip-Hop-Band denkt, ist vermutlich kein eingefleischter Xen-Nutzer. Im Hypervisor von Citrix hat das Kürzel eine festgelegte Bedeutung: DMC steht hier für Dynamic Memory Control. Die Funktion beschreibt das dynamische Verwalten von Speicher für laufende virtuelle Maschinen. Was unspektakulär klingt, ist in Wahrheit ein schlauer Mechanismus und funktioniert ungefähr so: Für jede Domäne legt der Admin eine Unter- sowie Obergrenze an Speicher fest, den diese vom RAM des Host-Systems beanspruchen darf.

Das Problem: Es ist kaum sinnvoll möglich, mehr Speicher in einem System zu vergeben, als physisch vorhanden ist. CPUs und deren virtuelles Pendant vCPUs dagegen werden in beinahe allen virtuellen Umgebungen oversubscribed. Hier greift die Annahme, dass virtuelle Systeme die ihnen zugewiesenen vCPUs nicht permanent zu 100 Prozent in Beschlag nehmen. Mit Arbeitsspeicher funktioniert das nicht: Gehen einem System die CPUs aus, müssen lediglich ein paar Prozesse darauf warten, dass ihre Aufgaben abgearbeitet werden. Läuft der Kernel indes in Sachen Speicher trocken, fängt dessen eingebauter Outof- Memory-Killer an, nach festgelegten Regeln Prozesse zu beenden.

Die dynamische Speicherverwaltung in Citrix Hypervisor stellt den Versuch dar, das vorhandene RAM so effektiv wie möglich zu nutzen. Innerhalb der festgelegten Grenzen steht es Xen dabei frei, den Speicher von VMs dynamisch zu vergrößern oder zu verkleinern - und zwar innerhalb der Grenzen, die der Admin für jede Domain festgelegt hat. Diese ausgesprochen nützliche Funktion sieht Citrix aber ausschließlich für sein professionelles Produkt vor, die freie Variante des Hypervisors enthält sie nicht.

Die XCP-ng-Entwickler hingegen bauen das Feature in ihre Version ein, sodass es künftig mit kommerziellem Support allen XCP-ng-Kunden zur Verfügung steht. Damit schafft XCP-ng gegenüber der freien Version des Citrix Hypervisor echten Mehrwert: Ohne DMC steht allen VMs nur der Speicher zur Verfügung, der ihnen statisch zugewiesen wurde, ob sie ihn nun wirklich brauchen oder nicht. DMC unterstützt den Admin letztlich dabei, totes Kapital im Rack zu vermeiden.

Grafik-Chips durchschleifen?

Wo früher der Prozessor als zentraler Rechenknecht im Server uneingeschränkt im Fokus des Interesses stand, spielt heute auch der jeweilige Grafikchipsatz eine herausgehobene Rolle. Zwar sind sowohl CPUs als auch GPUs darauf ausgelegt, Berechnungen vorzunehmen, doch bestimmte Operationen beherrscht die jeweils andere Art von Chip besser. Daher stellt es mittlerweile keine Ausnahme mehr dar, dass sich in Servern potente Grafikkarten mit mehreren GPUs befinden, obwohl an das Gerät gar kein Monitor angeschlossen ist: Die Grafikprozessoren dienen nicht dem Spielen, sondern kommen für jene Berechnungen zum Einsatz, die CPUs nicht so effizient hinbekommen.

Das bedeutet auch: Wenn Setups vom echten Blech in VMs umziehen und GPUs für etwaige Berechnungen brauchen, dann müssen diese in der virtuellen Maschine verfügbar sein. Die Frage, ob und wie sich physische Hardware eins zu eins in eine VM durchleiten lässt, gilt indes bei allen Virtualisierern als heißes Eisen. Bei vielen aktuellen Hypervisoren kam diese Funktion erst viel später hinzu, denn aus technischer Sicht ist der Vorgang anspruchsvoll. So stellt sich etwa die Frage, ob und wie sich Hardware an mehrere VMs gleichzeitig durchreichen lässt und wie in solchen Fällen Locking und ähnliche benötigte Features funktionieren.

Xen kann GPUs grundsätzlich durchreichen, in Citrix Hypervisor Free fehlt das Feature sehr zum Leidwesen der dortigen Benutzerschaft dagegen. Auch damit macht XCP-ng Schluss: Der Hypervisor unterstützt das Durchreichen von GPUs in virtuelle Systeme als normales Feature. Wer auf Xen setzt, aber Citrix kein Geld geben möchte, kommt insofern um XCP-ng gar nicht herum.

Die PV-Treiber sind wichtig

Weitere Vorteile begegnen Nutzern von XCP-ng auch an anderer, unerwarteter Stelle: innerhalb der virtuellen Maschinen, die in einer Umgebung mit XCP-ng laufen. Virtualisierung kommt ja bekanntlich in mehreren Stufen daher. Bei der Vollvirtualisierung mimt das Host- System einen kompletten Computer. Ihm kommt dann die Aufgabe zu, Funktionsaufrufe aus der virtuellen Maschine zwischen Gast- und Hostsystem zu übersetzen. Diese Konvertierung ist nun aber sehr rechenintensiv, weshalb dadurch einiges von der Leistung des Hosts verloren geht.

Abbildung 4: Für CLI-Allergiker gibt es die GUI XenAdmin, die man von XenServer bereits kennt.


© XCP-ng

Chiphersteller und Entwickler haben sich deshalb die Paravirtualisierung von Hardware ausgedacht: Hier nutzt der Hypervisor bestimmte Hardware-Features im Hinblick auf Virtualisierung, um einzelne Funktionen direkt in die VMs zu leiten. Bei der Vollvirtualisierung weiß das virtuelle System nicht, dass es virtualisiert ist; dem paravirtualisierten System ist dieser Umstand klar.

Die Sache hat allerdings auch einen Haken: Paravirtualisierung klappt nur, wenn es in der virtuellen Maschine einen passenden Treiber für die paravirtualisierte Hardware gibt. Wer etwa Windows schon einmal auf KVM betrieben hat, weiß: Es braucht eigene Virtio-Treiber für Windows, um von den potenziell hohen möglichen Bitraten bei I/ O und Netz zu profitieren.

Das ist bei Xen nicht anders; wie für KVM existieren die passenden Treiber auch für Xen. Citrix rückt sie allerdings nur heraus, wenn der Kunde zuvor Münzen einwirft. Ansonsten ist man auf die schon ziemlich alten Treiber angewiesen, die öffentlich zur Verfügung stehen. Zwischen diesen und der aktuellsten Version von Citrix ergeben sich deutliche Unterschiede, ganz besonders im Hinblick auf das jederzeit wichtige Thema Performance.

Auch hier schlägt XCP-ng einen anderen Weg ein: Es stellt für eine Reihe verschiedener Betriebssysteme aktuelle Treiber zur Paravirtualisierung bereit, sodass es nicht mehr nötig ist, auf die kommerziellen Citrix-Treiber zu setzen.

Grundlegender ZFS-Support

Sieht man sich die Entwicklung von XCP-ng näher an, wird schnell klar, dass die hinter dem Projekt stehenden Entwickler nicht ewig auf eine gepimpte Kopie von Citrix Hypervisor bauen wollen; auch die Entwicklung eigener Features steht durchaus auf dem Programm. Bei einem ihrer Leuchtturmprojekte gehen die Entwickler ein Thema an, an das Citrix sich bis heute nicht herangetraut hat: Support für ZFS als Storage-Backend (Abbildung 5).

Bekanntlich stellt die Kombination von ZFS und Linux ein schwieriges Thema dar. ZFS ist bis heute wegen einer zum Kernel teilweise inkompatiblen Lizenz nicht Bestandteil von Linux. Zwar bietet Oracle ZFS für Linux an, doch die Distributoren tun sich schwer damit, das Dateisystem in ihre Produkte zu integrieren. So müssen viele Xen-Nutzer auf ZFS verzichten, obwohl es in der Community einen exzellenten Ruf genießt.

Die Lizenzproblematik ist aber im Xen- Kontext nicht die einzige Herausforderung. ZFS unterstützt das »O_DIRECT«- Flag nicht, das Xen in vielen Situationen für direkten Zugriff auf einen Datenträger verwendet. Um dieses Problem zu lösen, müsste man Xen und XenServer so umbauen, dass »O_DIRECT« kein Hindernis mehr darstellt. Citrix hat sich bis heute nicht an das Problem gewagt, die XCPng- Entwickler hingegen gehen es an.

Um ZFS-Support in Citrix zu nutzen, aktiviert der Admin auf dem System das Repository xcp-ng-extras. Danach installiert er von dort die Kernel-Module und Userland-Werkzeuge für ZFS. Nun kann er ZFS-Dateisysteme anlegen und dann in XCP-ng ZFS als Pool für Speicher konfigurieren. Wer die beschriebene Lizenzthematik außen vor lässt, bekommt auf diese Weise ein zuverlässiges, leistungsstarkes Dateisystem.

Die Unterstützung für ZFS darf zweifellos als der größte Unterschied zwischen dem Citrix-Produkt und XCP-ng gelten, wenn auch nicht als einziger. Hinzu kommen viele kleine Veränderungen: Virtuelle Gäste lassen sich nun etwa auch mit UEFI-BIOS betreiben, wobei die Entwickler diesem Feature selbst noch nicht ganz trauen: Es ist offiziell als experimentell markiert. Schon während des Setups von XCP-ng lässt sich außerdem Software- RAID konfigurieren. Das ist für jene Setups interessant, bei denen die Hardware ohne RAID-Controller daherkommt, etwa weil beim Einkauf der Geräte der Preis ein relevantes Kriterium war.

Xen ist und bleibt Xen

Etwas weniger Euphorie kommt indes auf, setzt man den Feature-Umfang von XCP-ng in Relation zu modernen Technologien, etwa in Sachen Storage. Ceph hat sich in den vergangenen Jahren zu einer Art Alleskönner im Storage-Kontext entwickelt. Ein kleiner Ceph-Cluster ist weder sehr teuer noch schwierig aufzusetzen und zu betreiben. Für eine Virtualisierungslösung wie Xen erweist ein Ceph sich zudem als idealer Backend- Speicher, weil der Zugriff auf einen Ceph- Cluster von mehreren Compute-Knoten aus kein Problem darstellt.

Dass es sehr attraktiv wäre, Xen mit Ceph zu verheiraten, haben auch die XCP-ng- Entwickler erkannt. Für die Version 7.5 existierten hierfür sogar schon inoffizielle Pakete, die den Betrieb von virtuellen Maschinen auf Basis von virtuellen Ceph- RADOS-Blockgeräten (RBD) möglich machten. Das Storage-Plugin schafft es bis dato allerdings nicht in den offiziellen XCP-ng-Zweig, und mit den aktuellen 8.x-Releases von XCP-ng funktioniert es leider gar nicht mehr.

Abbildung 5: Anders als XenServer unterstützt XCP-ng auch ZFS offiziell. Mit dessen RAID-Funktionen lassen sich höhere Datenraten erreichen.


© XCP-ng

Dabei ist das Problem an und für sich gar nicht so schwerwiegend: Damit eine VM auf Basis von Xen RBDs als Backend- Speicher nutzen kann, muss der genutzte Emulator (meist Qemu) nur das RBDProtokoll beherrschen. Für KVM, das ja ebenfalls auf Qemu setzt, ist diese Aufgabe bereits seit geraumer Zeit erledigt. Auch für Xen gibt es ein gepatchtes Qemu-Paket, das bisher allerdings nicht offiziell unterstützt wird.

Schade: Der benötigte Storage-Pool-Treiber, der RBD und Xen letztlich integriert, liegt auf GitHub vor und funktioniert gut. Es bleibt zu hoffen, dass die Entwickler von XCP-ng hier bald Fakten schaffen und XCP-ng um einen weiteren Vorteil zur Citrix-Variante erweitern. Dass man dort Ceph auf absehbare Zeit in Hypervisor integriert, erscheint eher unwahrscheinlich.

Support

Wie im Enterprise-Umfeld üblich, darf man getrost annehmen, dass viele Kunden Citrix gar nicht deshalb Geld überweisen, weil das Produkt so herausragend wäre. In vielen Fällen dürfte stattdessen der kommerzielle Support das Zünglein an der Waage zugunsten von Citrix ausschlagen lassen.

Auch hier will XCP-ng dem Platzhirsch allerdings ans Leder: Eine eigene Firma ist bereits gegründet, um kommerziellen Support für XCP-ng anzubieten. XCP-ng. com hat lediglich zwei Subscription-Modelle im Angebot und mithin eine sehr einfache SLA-Struktur. Der Standard- Support bietet SSH-Login durch den Anbieter und einen Geschäftstag Reaktionszeit. Dafür fallen 600 US-Dollar pro Server jährlich an. Doppelt so teuer kommt die Enterprise-Variante, die dafür aber auch Zugang zu den Entwicklern, eine Stunde Antwortzeit, Support beim Setup von XCP-ng und andere Goodies bietet. Dieses durchaus attraktive Modell kommt deutlich günstiger als vergleichbare Angebote für ähnliche Produkte.

Fazit

Nach den Lizenzeskapaden und dem Schildbürgerstreich rund um die Features der freien Citrix-Hypervisor-Version haben Anwender und IT-Entscheider zu Recht die Nase voll von Citrix. XCP-ng erweist sich als eine gute Alternative zum kommerziellen Vorbild. Ein Blick ins Git- Verzeichnis von XCP-ng macht schnell deutlich, dass dessen Entwickler wissen, was sie tun. Dass sie XCP-ng bewusst kompatibel mit Hypervisor von Citrix halten, lässt Admins obendrein eine Hintertür offen, sollte ihnen XCP-ng doch nicht zusagen: Ein Umstieg zurück bleibt möglich.

Besonders fuchsen dürfte Citrix außerdem, dass die Firma durch XCP-ng ihr Quasi-Monopol auf XenServer-Support verliert. XCP-ng.com geht dabei recht niederschwellig vor: Die aufgerufenen Preise bleiben durchaus im Rahmen, hält man sich vor Augen, dass das Virtualisieren bisheriger physischer Systeme ja durchaus Kosten spart.

Hilfreich ist obendrein, dass XCP-ng mittlerweile sogar Features bietet, die es vermutlich nie in Citrix Hypervisor schaffen werden. Erweitert man XCP-ng nun um ein paar Features von Enterprise-Architekturen, eröffnet das dem Produkt viel Potenzial. Hätte es XCP-ng vor ein paar Jahren schon gegeben, hätten sich viele Unternehmen vermutlich einen teuren Ausflug in die OpenStack-Welt erspart. Auch, wenn die Cloud die Headlines dominiert: Kleine Setups zur Virtualisierung haben nach wie vor eine Daseinsberechtigung, und XCP-ng ist ein gutes Werkzeug, um sie zu bauen. (jcb)