XCP-ng

XCP-ng wird direkt auf dem Server installiert. Der Hypervisor verteilt Prozessorzeit und Arbeitsspeicher auf die virtuellen Maschinen. Die Verwaltungsschicht XAPI startet und stoppt Gäste, verbindet ihre virtuellen Geräte und koordiniert Hosts. Xen Orchestra spricht diese Schnittstelle an und ergänzt unter anderem Backup-Aufträge.

Ein Unternehmen könnte beispielsweise seine Anwendungsserver und eine Datenbank auf drei Hosts betreiben. Für geplante Wartung sollen VMs umziehen können, nach einem Hostausfall soll ein anderer Host sie neu starten. Dafür müssen neben der Verwaltung auch Speicher, Netz und freie Kapazität passend eingerichtet sein. Die Installation von XCP-ng allein schafft diese Ausfallsicherheit noch nicht.

Die Funktionen von XCP-ng sind ohne kostenpflichtige Funktionsfreischaltung verfügbar. Eine XCP-ng-Subscription bezahlt professionellen Support. Davon zu unterscheiden sind die Angebote für die fertige Xen-Orchestra-Appliance, deren Funktionsumfang vom gewählten Angebot abhängt.

Der Xen-Hypervisor läuft direkt auf der Hardware. Die privilegierte Steuerdomäne Dom0 stellt unter anderem Gerätetreiber und Verwaltungsdienste bereit. Sie verarbeitet auch einen wesentlichen Teil der Ein- und Ausgaben der VMs. Für den Betrieb benötigt sie ausreichend eigene Ressourcen und einen geschützten administrativen Zugang.

Ein Pool fasst bis zu 64 Hosts zur gemeinsamen Verwaltung zusammen. Ein Host koordiniert den Pool, die Dokumentation nennt ihn Coordinator oder Master. Die Prozessoren müssen kompatibel sein und vom selben Hersteller stammen. Intel- und AMD-Hosts lassen sich nicht in einem Pool mischen. Außerhalb eines laufenden Upgrades müssen Version und Update-Stand zusammenpassen.

Lokale Datenträger bleiben auch nach dem Pool-Beitritt lokale Datenträger. Ein Pool macht daraus keinen gemeinsamen Speicher. Für XOSTOR gelten außerdem engere Grenzen: Die aktuelle Dokumentation verlangt mindestens drei Hosts und nennt höchstens sieben Hosts pro Pool.

SMAPIv1 ist die klassische Speicherverwaltung von XCP-ng. Sie organisiert virtuelle Disks und Vorgänge wie Snapshots. Die eigentlichen Lese- und Schreibzugriffe durchlaufen einen Datenpfad: Der virtuelle Blocktreiber im Gast reicht sie an tapdisk weiter, das die Daten im jeweiligen Disk-Format auf dem Speicher liest oder schreibt.

XCP-ng beschreibt tapdisk als überwiegend single-threaded pro virtueller Disk. Die Arbeit für eine Disk verteilt sich damit nicht beliebig auf zusätzliche CPU-Kerne. Wenn dieser Verarbeitungspfad ausgelastet ist, hilft eine noch schnellere NVMe-SSD allein nicht weiter. Zusätzliche vCPUs für den Gast beseitigen diesen Engpass ebenfalls nicht automatisch. Die Entwickler erläutern diese Grenze ausdrücklich.

Für die Datenbank aus unserem Beispiel ist das ein erheblicher Nachteil: Konzentrieren sich ihre Zugriffe auf eine virtuelle Disk, kann ein großer Teil der möglichen NVMe-Leistung ungenutzt bleiben. Viele gleichzeitig aktive Disks und VMs können den Host dagegen insgesamt stärker auslasten. Hoher Gesamtdurchsatz über mehrere VMs belegt deshalb nicht, dass auch eine einzelne VM-Disk dieselbe Leistung erreicht.

Die erreichbare Datenrate hängt unter anderem von CPU, Blockgröße, Zugriffsmuster, Disk-Format und Speicher ab. Eine universelle SMAPIv1-Drossel auf exakt 1 Gbit/s oder 1 GiB/s ist durch die geprüften Herstellerquellen nicht belegt. Bit und Byte dürfen dabei nicht verwechselt werden: 1 Gibit/s entspricht 128 MiB/s, 1 GiB/s dagegen 1.024 MiB/s.

Ein aussagekräftiger Test vergleicht zunächst eine virtuelle Disk mit der geplanten Anwendungslast und anschließend mehrere parallel aktive Disks. Neben dem Durchsatz zählen die Zahl der Ein- und Ausgaben pro Sekunde (IOPS) und die Antwortzeiten. Große zusammenhängende Transfers können gut aussehen, während viele kleine Datenbankzugriffe bereits zu lange warten.

Während des Tests sollten die CPU-Auslastung der tapdisk-Prozesse in Dom0, die Last der physischen Laufwerke und bei gemeinsamem Speicher auch das Netzwerk beobachtet werden. Ein ausgelasteter tapdisk-Thread bei noch freier NVMe-Leistung deutet auf den virtuellen Datenpfad als Engpass hin. Auch Backups und Snapshot-Zusammenführungen gehören in einen zweiten Test mit realistischer Hintergrundlast.

Mehrere virtuelle Disks können Arbeit auf mehrere tapdisk-Prozesse verteilen, wenn die Anwendung ihre Daten sinnvoll aufteilen kann. Das beschleunigt eine unverändert genutzte einzelne Disk nicht automatisch. Ein Stripe über mehrere Disks verändert außerdem Ausfallverhalten und Wiederherstellung und sollte nicht allein für einen besseren Benchmark angelegt werden.

PCI-Passthrough kann eine NVMe direkt an eine VM durchreichen und den üblichen virtuellen Disk-Pfad umgehen. Damit bindet man den Gast aber an Hardware. Gewohnte Möglichkeiten für Live-Migration und hypervisorbasierte Snapshots dieser Daten stehen dann nicht wie bei einer normalen virtuellen Disk zur Verfügung. Backup und Wiederanlauf müssen dazu passen.

Ein Storage Repository (SR) ist der von XCP-ng verwaltete Speicherbereich für virtuelle Disks. Eine einzelne virtuelle Disk heißt VDI. Die Wahl des SR bestimmt unter anderem, welche Hosts dieselben Daten erreichen und wie viel Platz Snapshots benötigen.

Bei Thin Provisioning wächst die Belegung mit den geschriebenen Daten. Thick Provisioning reserviert den vorgesehenen Platz früher und kann bei Snapshots deutlich mehr freien Speicher verlangen. In beiden Fällen braucht der Betrieb Reserven für Backups, Snapshots und deren spätere Zusammenführung.

Das bisherige VHD-Format begrenzt eine virtuelle Disk auf 2 TiB. Seit dem 5. Mai 2026 ist QCOW2 über die regulären Updates von XCP-ng 8.3 produktiv freigegeben. Das derzeit getestete Maximum beträgt 16.381 GiB, also knapp 16 TiB. VHD bleibt die Voreinstellung, auf geeigneten SRs werden neue Disks über 2.040 GiB automatisch als QCOW2 angelegt.

QCOW2 ist auf den meisten bestehenden SR-Typen möglich, darunter EXT, NFS und LVM. Ausgenommen sind derzeit XOSTOR (linstor) und SMB-SRs. Eine vorhandene VHD-Disk wird beim Vergrößern nicht automatisch umgewandelt. Format, SR-Typ und Konvertierungsweg müssen zusammenpassen.

Die QCOW2-Unterstützung wurde in den bestehenden Speicherpfad mit tapdisk eingebaut. Der Hersteller beschreibt ihre Leistung als grundsätzlich mit VHD vergleichbar. Ein Wechsel auf QCOW2 ist daher keine pauschale Lösung für den NVMe-Engpass. Disk-Größe und Disk-Geschwindigkeit sind zwei getrennte Fragen.

SMAPIv3 trennt die Verwaltung der Volumes stärker vom Datenpfad. Ein anderer Datenpfad, etwa auf Basis von SPDK, kann andere Leistungsmerkmale ermöglichen. Die geprüften Herstellerveröffentlichungen beschreiben solche Ansätze jedoch als Entwicklung beziehungsweise Preview. Aus dem Namen SMAPIv3 allein folgt weder eine höhere Leistung noch eine Freigabe für die eigene Produktionsumgebung.

Xen Orchestra verwaltet Hosts, Pools und VMs im Browser und führt Backup-Aufträge aus. XO Lite ist die schlankere, im Host bereitgestellte Oberfläche für grundlegende Verwaltungsaufgaben. Für den umfassenden Verwaltungs- und Backup-Betrieb dient Xen Orchestra.

XO lässt sich kostenlos aus dem offenen Quellcode bauen. Installation, Updates und Qualitätssicherung liegen dann beim Betreiber. Vates weist ausdrücklich darauf hin, dass diese Installationsart keinen professionellen Support und keine mit der Appliance vergleichbare Qualitätssicherung erhält.

Die vorkonfigurierte Xen Orchestra Appliance (XOA) bringt einen verwalteten Update-Weg mit. Ihre kommerziellen Funktionen und der Support richten sich nach Lizenz beziehungsweise gebuchtem Angebot. Wer Angebote vergleicht, sollte deshalb den enthaltenen Funktionsumfang und die Supportleistungen einzeln prüfen.

Bei Live-Migration wird eine laufende VM für einen geplanten Umzug auf einen anderen Host übertragen. CPU-Eigenschaften, Netzwerk und Speicherzugriff müssen passen. Liegt ihre Disk auf gemeinsamem Speicher, muss dieser Datenträger nicht mitkopiert werden. Bei einer Storage-Migration werden zusätzlich die Disk-Daten übertragen.

Hochverfügbarkeit (HA) versucht nach einem Hostausfall, geschützte VMs auf verbleibenden Hosts neu zu starten. Es entsteht eine Unterbrechung, und ausreichend freie Kapazität muss vorhanden sein. XCP-ng empfiehlt mindestens drei Hosts. Gemeinsamer Speicher, zuverlässige Netzwerk- und Storage-Heartbeats sowie geeignete VMs sind Voraussetzungen. Fencing schaltet einen problematischen Host ab, damit nicht zwei Instanzen unkoordiniert dieselben Daten verändern.

Xen Orchestra ergänzt vollständige und inkrementelle Backups. Ein Snapshot auf demselben Speicher ersetzt keine unabhängige Sicherung. Zusätzlich zu VM-Daten gehören die Konfigurationen von Xen Orchestra und den Pools in das Wiederherstellungskonzept. Ein Restore-Test zeigt, ob die Anwendung mit ihren Abhängigkeiten wieder startet.

Die früher Continuous Replication genannte inkrementelle Replikation überträgt Änderungen nach einem Zeitplan auf einen weiteren SR. Sie ist keine synchrone, lückenlose Spiegelung. Beim Ausfall fehlen Änderungen seit dem letzten erfolgreichen Lauf. Die Replik wird vor unbeabsichtigtem Start geschützt, der dokumentierte Wiederanlauf erfolgt über einen Klon.

XCP-ng verwendet Open vSwitch für virtuelle Netzwerke. VLANs trennen Netze logisch, Bonds können physische Verbindungen bündeln oder gegen Ausfälle absichern. Management, Storage und VM-Verkehr sollten so aufgeteilt werden, dass ein großer Transfer weder die Administration noch die Ausfallerkennung verdrängt.

Die Managementschnittstellen gehören in vertrauenswürdige private Netze. Für Storage sind durchgängige Erreichbarkeit und passende MTU-Werte entscheidend. Jumbo Frames helfen nur bei durchgehend passender Konfiguration. Ein schnelleres Storage-Netz behebt keinen bereits ausgelasteten tapdisk-Thread.

XCP-ng 8.3 unterstützt IPv6 auch für die Steuerdomäne. Die Release-Dokumentation kennzeichnet den gleichzeitigen IPv4-/IPv6-Betrieb dort weiterhin als experimentell. Das Netz der VMs ist davon getrennt zu betrachten. VLAN-Trennung und private IP-Adressen verschlüsseln den Datenverkehr nicht, Schutzbedarf und verwendetes Storage-Protokoll müssen zusammenpassen.

Das V2V-Werkzeug in Xen Orchestra kann eine VMware-VM während des Betriebs zunächst anhand eines Snapshots übertragen. Für den Abschluss wird die Quell-VM heruntergefahren und die verbleibende Änderung übertragen. Danach startet die VM auf XCP-ng. Diese Warm Migration reduziert die Unterbrechung, beseitigt sie aber nicht.

Der Zugriff erfolgt über die ESXi-Schnittstelle, direkter Zugriff auf das VMware-Storage ist nicht nötig. Vorab sind unter anderem Snapshot- und Abschaltrechte, Gasttreiber, BIOS-/UEFI-Modus, Netzzuordnung und der Importpfad für große Disks zu prüfen. Die Verfügbarkeit von QCOW2 allein belegt nicht, dass jeder VMware-Importpfad große Disks unterstützt.

Für eine Datenbank sollte ein Probelauf auch Transaktionen und Antwortzeiten unter Last prüfen. Eine VM kann fehlerfrei starten und trotzdem die benötigte Speicherleistung nicht erreichen. Ein dokumentierter Rückweg und ein geeignetes Wartungsfenster bleiben Teil der Migration.

Zum Prüfdatum ist XCP-ng 8.3 die aktuelle LTS-Version, mit angekündigtem Support bis zum 30. November 2028. XCP-ng 8.2 ist seit dem 16. September 2025 außer Support. Die Versionsnummer allein genügt nicht: Die regulären Updates enthalten auch wichtige Korrekturen an Storage, QCOW2 und Sicherheitskomponenten.

Dom0 ist eine privilegierte Steuerdomäne. Zusätzliche Fremdsoftware dort ist laut Hersteller nicht unterstützt. Administrative Zugriffe sollten begrenzt und Updates samt erforderlichen Neustarts geplant werden. Bei aktivierter HA muss die Wartung vorbereitet werden, damit ein absichtlicher Neustart nicht als unerwarteter Ausfall behandelt wird.

XCP-ng veröffentlicht Sicherheitsupdates öffentlich. Die Meldung vom 8. September 2026 enthält beispielsweise auch Korrekturen an tapdisk. Das unterstreicht, dass der Speicherpfad sowohl für Leistung als auch für Isolation relevant ist. Patch-Stand, Backup und ein getesteter Wiederanlauf gehören gemeinsam zum Betrieb.