Damit man die Frage sachlich korrekt – und frei von subjektiven Dingen – beantworten kann, muss man sich jedoch erst einmal mit den Detalis der beiden Virtualisierungslösungen auseinander setzen.

OpenVZ – OpenVZ ist der OpenSource-Ableger von Parallels Virtuozzo und besonders bei Hostern beliebt, da einzelne Hostserver mit VMs nur so vollgepackt werden können. OpenVZ ist dabei eine sogenannte  Container- bzw. Betriebssystemvirtualisierung, hier werden die Gäste überhalb der Kernel-Ebene positioniert.

Einer OpenVZ-VM steht also somit kein eigener Kernel, sondern lediglich eine eigene virtuelle Umgebung zur Verfügung, in der keine eigenen Kernel-Module oder Treiber geladen werden können. Die virtuellen Umgebungen sind dabei strikt voneinander getrennt.

Durch die Art der Virtualisierung verbrauchen die einzelnen VMs standardmäßig nicht sehr viele Ressourcen, womit auf einem Host besonders viele Container untergebracht werden können.

Problematisch ist jedoch das Speichermanagement: Laut diesem Artikel hier findet bei OpenVZ keine strikte Trenung statt, was den ansprechbaren RAM angeht. So zeigt z.B. der Befehl /proc/meminfo anscheinend den Arbeitsspeicher des Hostsystems an, was bei Applikationen, die gerne mal viel Speicher allokieren, zu gravierenden Problemen führt. So kann es also durchaus sein, dass eine Anwendung auf der VM förmlich “denkt”, dass viel RAM zur Verfügung stehe und somit versucht, diesen zu adressieren. Je nach Fehlerbehandlung kann es dann dazu kommen, dass die Anwendung – und im worst case auch die VM – abstürzt.

Ein weiterer Aspekt ist ein vollgelaufener Arbeitsspeicher, sobald dieser Fall bei einer OpenVZ-VM eintritt, könnten Adressierungsversuche von laufenden Programmen (wie z.B.  durch die Funktion malloc() unter C/C++) fehlschlagen und ebenfalls einen Fehler zurück geben. Je nach Anwendung können auch hier Probleme auftreten.

Das Verhalten von OpenVZ-Umgebungen ist in manchen Fällen also unvorhersehbar.

XEN – XEN ist “relativ neu” und wurde ursprünglich an der Univ. von Campbridge entwickelt. Die Software wird unter einer OpenSource-Lizenz veröffentlicht, wobei es von Centrix mittlerweile auch kostenpflichtige Virtualisierungslösungen gibt (Centrix hat XEN vor einigen Jahren übernommen und arbeitet nun eng mit Microsoft zusammen).

Unter XEN werden die VMs durch Paravirtualisierung realisiert: Der VMM (Virtual Maschine Manager, hier: Hypervisor) verdrängt dabei den Kernel in eine weniger priviligierte Schicht (z.B. CPU-Ring 1 in einer 32-Bit-Architektur) und platziert sich selbst als Schicht zwischen Hardware und Betriebssystem-Kernel. Dabei wird vorausgesetzt, dass sowohl Gast-, als auch Wirt-Betriebssysteme modifiziert werden können. Kann ein OS nicht modifiziert werden, da z.b. wie bei Microsoft Windows der Kernel nicht frei verfügbar ist, wird die VM mit diesem Betriebssystem vollvirtualisiert, was eher einer Hardwareemulation gleich kommt und nicht sehr perfomant ist.

Durch diese Architektur wird das Gastsystem mit einem eigenen Betriebssystem aufgesetzt, womit die virtuelle Umgebung vollständig vom Hostsystem und anderen VMs abgeschottet ist. Es ist also durchaus möglich, dass auf einem Debian-Host eine Windows-VM aufgesetzt wird. Die Gäste können dabei das Betriebssystem – falls möglich – frei modifizieren, wobei sich die VM also wie ein dezidierter Server verhällt. Wenn der Speicher voll läuft, fängt die XEN-VM an zu swappen, was zwar die Performance des Gastes negativ beeinträchtigt, laufende Applikationen jedoch vor dem Absturz bewahrt. Anders wie bei OpenVZ ist das Verhalten von XEN-Gästen also vorhersehbar, was vor allem mehr Planungskonsistenz und Sicherheit verspricht.

XEN vs. OpenVZ

Ob die Wahl nun auf XEN oder OpenVZ fällt, hängt jedoch auch von der geplanten Nutzung der VM ab. Es gibt sicherlich Anwendungen, für die sich eine OpenVZ-VM besser eignen würde, auch existiert unter OpenVZ mit ca. 3 Prozent ein kleinerer Overhead als bei XEN (aktuell ca. 5 Prozent).

Hier geht es also vor allem um Details, wobei ich persönlich die Speicherverwaltung von OpenVZ nicht hinnehmen würde. Ein weiterer Nachteil ist die fehlende Flexibilität bei OpenVZ: Wenn du beispielsweise von einem Linux-System auf Windows umsteigen möchtest, ist dies nur in Verbindung mit einem Host-Wechsel möglich – was nicht alle Anbieter offerieren. 

Da die Drittentwicklungen zu XEN (wie Webinterfaces) noch in den Kinderschuhen stecken, greifen momentan noch sehr viele Hoster zu OpenVZ/Virtuozzo, hier gibt es entsprechende Verwaltungstools und ausführliche Dokumentationen, die die Entwicklung von eigener Software erlauben. Hoster können somit schnell eigene GUIs schreiben, die Kunden z.B.  zum Neustarten von VMs nutzen können. Unter XEN gestaltet sich die ganze Angelegenheit schon etwas komplexer, da es hier weltweit gerade mal 14 WEb-GUIs zu geben scheint, die entweder kostenfrei oder kommerziell erhältlich sind, wobei nur eines dieser Interfaces für Hoster geeignet ist.

Hier muss man also eigene Lösungen entwickeln, damit Kunden ein ausreichendes VM-Management betreiben können.

Auf Grund der Speicherverwaltung und dem Verhalten von XEN-VMs kann ich jedoch jedem Nutzer zu XEN raten, falls dieser die Möglichkeit besitzt.

Dabei ist mir aufgefallen, dass es weltweit gerade mal 14 Webinterfaces zu geben scheint, die für Normalsterbliche entweder kostenlos oder zu erschwinglichen Preisen erhältlich sind und eine XEN-Verwaltung anbieten (z.B. Anlegen von Domains etc.).

Es ist schade, dass die Zukunft der Virtualisierung derzeit nur so wenig unterstützt wird, die Folge ist, dass sich immer mehr Unternehmen eigene Webmanagement-Software schreiben und damit die eigenen Kunden bedienen.

Ich bin der Meinung, dass die Situation in 2-3 Jahren jedoch eine andere sein wird und mehr Webinterfaces auf den Markt geschmissen werden.

Hoffentlich sind die meisten davon OpenSource

Kennt da wer von euch ein gutes Board, welches nicht nur eine bestimmte Virtualisierungslösung beinhaltet?