Der Server von Oracle VM basiert auf dem Open-Source-Produkt "Xen", lediglich die Management-Oberfläche ist eine Eigenentwicklung von Oracle und damit Closed Source. Das gesamte Paket darf aber kostenlos heruntergeladen und produktiv genutzt werden. Möchte man jedoch Support von Oracle, muss dieser kostenpflichtig (999 Dollar pro System jährlich) erworben werden. Der ESX-Server von VMware ist kein freies Produkt und deshalb lizenzpflichtig (ab 1540 Dollar pro Jahr für Lizenz und Support). Kostenlos ist lediglich eine 30 Tage gültige Testversion.

Installation

Die Installation der Server verläuft bei beiden Systemen weitgehend identisch. Jeder bringt sein eigenes Betriebssystem mit, das von einer Boot-fähigen CD mit wenigen Klicks installiert ist. Bei den Management-Oberflächen gibt es jedoch unterschiedliche Ansätze. Oracle benötigt die kostenfreie 10g-XE-Datenbank zur Speicherung des Repository und einen kleinen Application Server, der eine Apex-Anwendung (Apex ist eine HTML-basierende Entwicklungsumgebung von Oracle) bereitstellt, über die das System per Web-Browser administriert werden kann. VMware hingegen braucht die Installation des Virtual Infrastructure Client (Fat Client) unter Windows oder alternativ die Verwendung eines Web-Frontends.

Zur Installation eines Gastsystems muss entweder ein fertiges Template oder ein ISO-Image auf den Server kopiert werden. Ein kleiner Vorteil des VMware Infrastructure Client ist die Möglichkeit, dass die Installation einer Software in einer virtuellen Maschine auch über das CD-ROM-Laufwerk am Client-PC erfolgen kann. Das Erstellen von ISO-Images und manuelles Kopieren entfallen also. Bei Oracle hingegen ist ein ISO-Image nötig, das auf den Media-Pool-Server von Oracle VM kopiert werden muss, erst dann lässt sich die Software in die VM einbauen. Die Bereitstellung der Daten für eine paravirtualisierte Installation ist unter Oracle VM auf einem HTTP-, FTP- oder NFS-Share möglich.

Ein gewisses Problem bei Oracle birgt auch die Systemanmeldung. Oracle VM benutzt eine Web-basierende Oberfläche, um die virtuellen Maschinen anzuzeigen. Hier muss sich der Benutzer zunächst gegenüber der Web-Oberfläche authentifizieren. Will er auf eine virtuelle Maschine zugreifen, wird eine VNC-Verbindung (Virtual Network Computing) zum Server hergestellt, die ebenfalls mit Benutzername und Passwort geschützt ist. Während dieses etwa fünf bis zehn Sekunden dauernden Anmeldevorgangs hat der virtuelle Server aber bereits zu booten begonnen, so dass es nicht möglich ist, etwa bei einem Windows-Start "F8" zu drücken, um das Gastsystem in einem abgesicherten Modus zu starten.

Der Infrastructure Client verwendet dagegen eine eigene Oberfläche und ein eigenes Protokoll zur Administration eines VMware Servers und dessen virtueller Maschinen. Hier ist nur eine einmalige Authentifizierung gegenüber dem Server notwendig, die auch für alle virtuellen Maschinen gilt. Sobald eine VM angeklickt wird, erscheinen sofort deren Informationen auf dem Bildschirm, mit denen dann gearbeitet werden kann. Ferner kann man bei VMware in das BIOS des Gastsystems gelangen und dort zum Beispiel die Boot-Reihenfolge verändern. Andererseits hat die Oracle-Lösung den Vorteil, dass sich auf sehr einfache Weise beliebigen Anwendern ein Zugang zur Konsole bereitstellen lässt, da diese keine Client-Software benötigen, um die Maschine zu verwalten.

Die Architektur von Oracle VM

Das zentrale Verwaltungssystem für die virtuellen Maschinen ist bei Oracle der VM Manager. Er beinhaltet die Oracle-Datenbank 10 XE-Edition und einen Application Server. Auf dem System wird die Web-Oberfläche für die Server-Verwaltung generiert, und in der Datenbank werden die Zustände der einzelnen Systeme abgespeichert. Ein VM-Manager-Server kann beliebig viele Server-Pools verwalten. Ein Server-Pool ist die Zusammenfassung von Hardwaresystemen zu einer gemeinsamen Einheit. Jeder Pool muss mindestens einen Pool-Master, einen Utility-Server und einen Virtual-Machine-Server enthalten, wobei diese Dienste auch auf einer physikalischen Maschine zusammengefasst werden können.

Innerhalb eines Pools kann für die virtuellen Maschinen über den VM Manager eine Live-Migration gestartet werden. Dafür müssen alle Server eines Pools auf denselben Plattenspeicher Zugriff haben, da bei einer Migration nur die Daten aus dem Arbeitsspeicher des VM Servers und nicht die gesamte virtuelle Festplatte über das Netz übertragen werden. Als kleine Einschränkung kann jedem Pool nur ein Storage zugeordnet werden, da sich die Maschinen der einzelnen Server nicht in unterschiedlichen Verzeichnissen befinden dürfen.

Der Pool-Master ist das zentrale Organ in einem Server-Pool. Er hält den Kontakt zur Außenwelt und ist für das Load Balancing auf den VM-Hosts zuständig. Es darf nur einen solchen Dienst pro Pool geben. Der Utility-Server ist für die I/O-Operationen der VMs in Bezug auf das Erstellen, Löschen und Umbenennen von Maschinen zuständig. Die Virtual-Machine-Server sind die Arbeitstiere in einem Pool, die virtuelle Systeme starten und ausführen. Davon kann es beliebig viele in jedem Pool geben.

Die Architektur von VMware ESX Server

Die Architektur von VMware ist etwas übersichtlicher als die von Oracle, da es nicht möglich ist, verschiedene Dienste auf unterschiedliche Systeme auszulagern. Unter VMware gibt es immer einen Virtual-Center-Management-Server, der als Dienst auf einem Windows-Server zu installieren ist. Er ist für die zentrale Verwaltung aller Ressourcen zuständig. Das, was Oracle als Pool bezeichnet, wird bei VMware als Cluster zusammengefasst. Jedes Cluster kann beliebig viele ESX Server enthalten.

Was die VMware-Handhabung jedoch wieder komplexer macht, sind die vielen verschiedenen Module des Systems. Das beginnt mit dem Virtual Machine File System (VMFS), das benötigt wird, damit verschiedene ESX Server gleichzeitig auf denselben Speicher einer virtuellen Maschine zugreifen können. Es ist die Voraussetzung für eine Live-Migration. Ein weiteres Modul ist der Distributed Resource Scheduler (DRS), der automatisch die verfügbaren Ressourcen optimiert und Systeme bei Überlast verlagert. Mit VMware HA gibt es eine Lösung, um die virtuellen Maschinen von einem ausgefallenen Knoten auf einem anderen zu starten. Aus jeder virtuellen Maschine wird ein Heartbeat gesendet, der dazu dient, die Maschine im Fehlerfall neu zu starten oder automatisch auf ein anderes System umzuziehen und dort zu booten. VMotion ist die Plattform, um die Migration von virtuellen Maschinen zu ermöglichen. Ein weiteres großes Modul ist das Consolidated Backup. Damit können die virtuellen Maschinen zentral gesichert werden.

Virtualisierungsmethoden

Im Bereich der Virtualisierung unterscheidet man zwischen Hardware- und Paravirtualisierung. Bei der Hardwarevirtualisierung werden dem Gastsystem Teilbereiche der physischen Hardware in Form von virtueller Hardware zur Verfügung gestellt. Dadurch kann ein beliebiges Betriebssystem, das für die CPU-Architektur geeignet ist, ausgeführt werden. VMware nutzt diese Methode derzeit ausschließlich, wobei sich die Systeme auf jeder CPU starten lassen. Unter Oracle VM werden für die Hardwarevirtualisierung Prozessoren mit Intel VT oder AMD-Pacifica-Kern benötigt (zum Beispiel Xeon-CPUs mit mehreren Kernen oder auch Core2Duo-CPUs). Ist diese Voraussetzung erfüllt, kann man neben dem für die Paravirtualisierung unterstützten Betriebssystem auch einen Suse Linux Enterprise Server oder gar ein Windows 2003 als Gastsystem betreiben.

Bei der Paravirtualisierung wird ein zusätzliches Betriebssystem virtuell gestartet, allerdings ohne virtualisierte oder emulierte Hardware. Stattdessen verbindet die Softwareschnittstelle eine abstrakte Verwaltungsschicht mit der Hardware. Dafür muss das Betriebssystem portiert und der Kernel angepasst werden. Dieses ist bei Oracle VM derzeit mit Red Hat und Oracle Enterprise Linux möglich.

Aufgrund der Architektur und dem geringeren Overhead ist die Paravirtualisierung performanter als eine Hardwarevirtualisierung. Der Vorteil der Lösung ist, dass diese Art der Virtualisierung auf jeder Hardware ausgeführt werden kann und sich die Hardware-ressourcen besonders gut ausnutzen lassen. Sie ist bis zu dreimal schneller als die Hardwarevirtualisierung. Damit ergibt sich ein großer Vorteil für Oracle VM, da VMware diese Art der Virtualisierung derzeit noch nicht unterstützt.

Live-Migration

Die Live-Migration unter Oracle VM beziehungsweise VMotion von VMware ist ein Feature, das es erlaubt, eine virtuelle Maschine im laufenden Betrieb von einer physikalischen Maschine unterbrechungsfrei (zumindest aus Benutzersicht) auf eine andere zu migrieren. Dies ist zum Beispiel der Fall, wenn Hardwarewartungen nötig sind oder man einen Server entlasten will. Damit die Migration funktioniert, muss die virtuelle Maschine permanenten Zugriff auf ihr Dateisystem haben, was durch ein Netzwerk-Dateisystem wie NFS oder Fibre Channel gewährleistet ist. Als günstige Alternative bietet sich hier auch iSCSI an.

Voraussetzungen für eine erfolgreiche Live-Migration sind:

• Beide Hosts müssen identische Hardware haben.

• Beide Hosts müssen Zugriff auf das gleiche Dateisystem haben.

• Beide Hosts sollten sich im gleichen Subnetz befinden, und die virtuelle Maschine sollte ein Bridge Network Setup haben.

• Unter Oracle VM müssen sich beide Systeme im gleichen Server-Pool befinden.

Um die Netzverbindung unter Oracle VM auf das neue System zu übertragen, wird von dem zu migrierenden Host ein ARP-Request generiert, der ankündigt, dass die IP-Adresse der virtuellen Maschine an einen neuen Ort gewechselt hat. Es geht dabei nur eine kleine Menge an Paketen verloren, die gerade "in-flight" sind und automatisch neu angefordert werden.

Bei Oracle VM erfolgt eine Live-Migration in fünf Schritten:

1. Pre-Migration: Auf Host A läuft eine virtuelle Maschine. Ein Ziel auf Host B wird ausgewählt.

2. Reservation: Host B überprüft die notwendigen Ressourcen und stellt anschließend einen Container bereit, der der virtuellen Maschine von Host A entspricht.

3. Iterative Pre-Copy: Alle Pages (Arbeitsspeicherinformationen) werden transferiert.

4. Stop-and-Copy: Die virtuelle Maschine auf Host A wird gestoppt und der Netzverkehr auf Host B umgeleitet. Danach werden der CPU-Zustand und die noch zuletzt geänderten Speicher-Pages transferiert. Die Ausfallzeit des Systems beträgt bei einem 1-Gigabit-Ethernet-Netz zirka 200 Millisekunden.

5. Commitment-and-Activation: Host B bestätigt den Vorgang und setzt die Ausführung des Systems fort. Dabei wird Host B der primäre Host, und A beendet seine Prozesse.

Ein noch großes Problem von Oracle VM ist die kaum vorhandene Fehlererkennung während der Migration sowie der Umstand, dass das Zielsystem mindestens die Hardwarevoraussetzungen des alten Hosts erfüllen muss. Im Gegensatz zu den VMware-Mechanismen prüft Oracle VM Manager vor der Migration nicht, ob zum Beispiel auf dem neuen System genügend Ressourcen (Platten, Arbeitsspeicher, CPUs etc.) verfügbar sind. Ist dies nicht der Fall, versucht Oracle VM die virtuellen Maschinen dennoch zu transferieren, stoppt den alten Host, kann die VMs auf dem Zielsystem allerdings nicht starten, so dass die Migration ohne Fehlermeldung gescheitert ist und der alte Server manuell neu in Betrieb genommen werden muss. Solange man nicht sicher sein kann, dass die Migration unterbrechungsfrei stattfindet, ist der Sinn des Systems eher fragwürdig, da man immer eine Ausfallzeit einplanen muss. Außerdem hat Oracle in der Version 2.1 einen kleinen Bug verbaut: Der Manager entfernt die CD-Laufwerke vor der Migration nicht aus der virtuellen Maschine, so dass in vielen Fällen die Migration misslingt (siehe bugzilla.oracle.com #4785).

Diese Kinderkrankheiten gibt es in VMware ESX nicht mehr, da die Systeme wesentlich toleranter in den Anforderungen an die Hardware sind und eine Migration auch nur dann stattfindet, wenn die Rahmenbedingungen gegeben sind und die Maschine unterbrechungsfrei betrieben werden kann. Hier hat der ESX Server eindeutig die Nase vorn, während Oracle VM im jetzigen Zustand noch nicht für den Produktiveinsatz nutzbar ist. Es ist jedoch davon auszugehen, dass Oracle in einem in Kürze erwarteten Update einige dieser Probleme gelöst haben wird. (ue)