Welche Kriterien spielen bei der Auswahl einer Virtualisierungslösung die größte Rolle? Neben der Leistungsfähigkeit und Hardware-Unterstützung ist auch die Verwaltungs und Bedienung der virtuellen Maschinen von Interesse. Im folgenden werden die Virtualisierungslösungen von Vmware und Microsoft hinsichtlich dieser Punkte untersucht.
Microsoft bietet zur Konfiguration ein reines Webinterface, das seinen Zweck durchaus erfüllt. Plattformunabhängigkeit wird jedoch nicht völlig erreicht, da die Übernahme von Bildschirm, Tastatur und Maus der virtuellen Maschinen über ein ActiveX-Steuerelement erfolgt, das nur unter Internet Explorer lauffähig ist. Mit anderen Browsern, vor allem auch unter anderen Betriebssystemen, können zwar die virtuellen Maschinen komplett installiert und konfiguriert werden, jedoch muss zur Kontrolle der Gastmaschinen ein externes Programm gestartet werden, das nur für Windows verfügbar ist.
Mit dem Webinterface von Microsoft lässt sich nicht nur der Virtual Server des eigenen Rechners administrieren, sondern auch der der anderen Hostmaschinen im Netzwerk. Dies erspart, anders als bei Vmware, die Notwendigkeit des Internet Information Server auf jeder Virtual-Server-Hostmaschine.
Vmware geht einen etwas anderen Weg. Die Administration und Kontrolle wird in der Regel über eine eigene Applikation gesteuert, die so genannte Vmware-Server-Konsole. Sie ist für Windows und Linux verfügbar.
Zwar bietet auch Vmware ein Webinterface. Es ist jedoch sehr einfach aufgebaut und bietet nur wenig mehr Komfort als manuelles Editieren der Konfigurationsdateien. Eine Kontrolle der Gastmaschinen ist hier gar nicht möglich. Lediglich das Herunterladen der Vmware-Server-Konsole wird angeboten.
Beide Systeme bringen zudem ein umfangreiches COM-API mit, das sprachenunabhängig genutzt werden kann, um administrative Aufgaben wie das Klonen einer virtuellen Maschine durch Scripts zu automatisieren.
 |
Das Webinterface von Vmware Server ist äußerst spartanisch.
|
In einer Gastmaschine können ein oder mehrere Netzwerkadapter auf unterschiedliche Weise an den Hostcomputer angebunden werden. Microsoft unterstützt bis zu vier Netzwerkadapter, während Vmware bis zu zehn unterstützt.
Folgende Möglichkeiten bestehen:
- Bridged: In diesem Modus wird ein virtueller Netzwerkadapter an einen realen Netzwerkadapter in der Hostmaschine auf Ethernet-Ebene gekoppelt. Dieser Netzwerkadapter erreicht die gleichen Rechner wie der Netzwerkadapter in der Hostmaschine. Umgekehrt betrachten alle Rechner, die den Hostcomputer sehen, auch die Gastmaschine als eigenen Netzwerkknoten.
- Host-Only: Hier sehen die Gastmaschinen sich nur untereinander plus die Hostmaschine. Die Gastmaschinen werden nicht im Netzwerk der Hostmaschine sichtbar. Dies ist insbesondere für einen Testbetrieb interessant.
- NAT: Diese Möglichkeit besteht nur bei Vmware. Es wird über der Hostmaschine ein NAT-Routing realisiert, so dass die Gastmaschinen im Netzwerk der Hostmaschinen nicht sichtbar sind, jedoch die Möglichkeit haben, andere Rechner im Netzwerk der Hostmaschine zu erreichen. Unter Microsoft Virtual Server kann ein NAT-Routing mit den Routingmöglichkeiten von Windows 2003 jedoch leicht realisiert werden.
Normalerweise wird man für den Produktivbetrieb "bridged" wählen, wenn die Gastmaschine im LAN normale Serveraufgaben erfüllen soll. Steht die Hostmaschine in einem sicherheitsempfindlichen Bereich, wie der demilitarisierten Zone (DMZ), und hat mehrere Netzwerkadapter für verschiedene Netze, so muss genau geplant werden, wie viele virtuelle Netzwerkadapter eingerichtet und mit welchen Netzen sie verbunden werden sollen, je nach den Aufgaben der Gastmaschine.
Deutlich komplexer ist die Auswahl des richtigen Festplattenlayouts. Man hat die Wahl zwischen einer Datei im Dateisystem, die dann als Image einer physikalischen Platte für das Gastbetriebssystem genutzt wird, und der Nutzung einer gesamten physikalischen Platte für ein Gastbetriebssystem, die dann der Hostmaschine nicht mehr zur Verfügung steht. Vmware bietet zusätzlich die Möglichkeit, nur einzelne Partitionen einer physikalischen Platte im Gastbetriebssystem zu nutzen.
Damit muss man auch zwischen Performance und Flexibilität wählen. Die Nutzung einer gesamten physikalischen Platte oder Partition ist deutlich schneller als das Arbeiten mit einer Imagedatei. Plant man jedoch, sich den Umzug einer Gastmaschine auf eine andere Hostmaschine zumindest vorzubehalten, so ist die Imagedatei die bessere Wahl.
Erheblich einfacher wird es mit einem Storagesystem, das der Hostmaschine eine physikalische Platte in der gewünschten Größe zur Verfügung stellen kann. Sie wird dann vom Gastbetriebssystem Eins zu Eins genutzt. Bei einem Serverumzug der Gastmaschine kann die Platte dann kurzfristig von der neuen Hostmaschine verwendet werden.
Als Festplattentechnik stehen SCSI oder IDE respektive SATA zur Auswahl. SCSI bietet deutliche Performance-Vorteile. Da weder Virtual Server von Microsoft noch Vmware Server im Gastbetriebssystem virtualisierte Treiber für IDE anbieten (sondern nur für SCSI), lässt sich eine optimale Leistung nur mit SCSI-Lösungen erreichen.
Insbesondere bei Linux als Gastbetriebssystem muss beachtet werden, dass nach der Installation der virtuellen Treiber ein anderer SCSI-Controller als bei der Installation von Linux eingestellt ist. ALso muss man unbedingt den Hinweise der Linux-Distributionen zum Wechseln des SCSI-Controllers folgen.
Soll statt einer realen Festplatte die virtuelle Maschine auf einer Image-Datei installiert werden, muss man bei Vmware Server aufs Dateiformat achten: SCSI und IDE sind nicht kompatibel. Eine mit einem IDE-System erstellte Image-Datei kann nicht in einen SCSI-Rechner genutzt werden. Umgekehrt gilt das gleiche.
Bei Microsoft Virtual Server existiert dieses Problem nicht: Hier kann eine Imagedatei logisch von IDE nach SCSI umgewandelt werden.
Beide Systeme bieten die Möglichkeit, Imagedateien nicht gleich in der vollen Größe anzulegen, sondern bei Bedarf wachsen zu lassen. Dies ist eine sinnvolle Option für Testzwecke, um erheblichen Speicherplatz zu sparen. Für den Produktivbetrieb sollte eine Imagedatei jedoch gleich in der vollen Größe und vor allem unfragmentiert angelegt werden. Sonst entsteht möglicherweise ein nicht unerhebliches Problem mit Doppelfragmentierung auf Host- und Gastbetriebssystem.
Bei der Konfiguration eines virtuellen Servers ist auch die Frage interessant, welche Teile überhaupt virtualisiert werden sollen. In der Regel benötigt man heute weder COM- noch LPT-Schnittstellen. Auch eine Soundkarte wird auf einem Server in der Regel nicht gebraucht. Gleiches gilt für ein Floppy-Laufwerk. Hier gilt, dass alles was nicht gebraucht wird, erst gar nicht auf der Gastmaschine eingerichtet werden sollte.
Ein CD/DVD-Laufwerk ist häufig für die Installation des Gastbetriebssystems nötig. Das im Gastbetriebssystem installierte Laufwerk kann wahlweise an ein physikalisches Laufwerk oder an eine ISO-Datei gebunden werden. Es kann zunächst in die Gastmaschine konfiguriert und später, wenn es nicht mehr benötigt wird, aus der Gastmaschine entfernt werden.
Ganz entscheidend sind Überlegungen zu Sicherheitsaspekten. Microsoft und Vmware bieten die Möglichkeit jede virtuelle Maschine unter einem anderen Benutzer hochzufahren. Dieser Benutzer benötigt in beiden Fällen lediglich Lese- und Schreibzugriff auf die Konfigurationsdatei der virtuellen Maschine und die Image-Dateien für Platten sowie CD/DVD-Images. Also kann man mit sehr eingeschränkten Rechten arbeiten.
Vmware Server in der Version 1.0.1 weist an dieser Stelle allerdings eine Sicherheitslücke auf: Nach der Installation steht ein Standardverzeichnis für virtuelle Maschinen bereit - in der Regel "C:\Virtual Machines". In diesem Verzeichnis werden alle bestehenden Berechtigungen mit "Jeder - Vollzugriff" ersetzt. Dies verbessert zwar in Einzelfällen dem Benutzer das "Ersterfahrungserlebnis", ist jedoch sicherheitstechnisch unverantwortlich, insbesondere bei einem Serverprodukt. Nach der Installation sollte man daher die Rechte einschränken.
Ganz anders sieht es aus, wenn die virtuelle Festplatte mit einer physikalischen Platte realisiert wurde. Windows erlaubt aus gutem Grund grundsätzlich nur Administratoren, physikalische Platten zu lesen und zu schreiben. Daher muss die virtuelle Maschine unter einem Benutzer mit Administratorrechten laufen. Ist dies nicht gewünscht, muss man sich Tools von Drittherstellern bedienen, die einem einzelnen Benutzer auch ohne Administratorrechten physikalische Plattenzugriffe ermöglichen.
Nachdem eine virtuelle Maschine für die Serveranwendung konfiguriert wurde, erfolgt die Installation des Gastbetriebssystems. Nach dem virtuellen Einschalten der Gastmaschine sind in beiden Lösungen die Möglichkeiten des erstmaligen Bootens sehr vielfältig.
Neben der Installation von Originalmedien wie CD oder DVD kann man auch problemlos von ISO-Dateien starten, wenn das virtuelle Laufwerk an eine ISO-Datei gehängt wurde. Das Verwenden von ISO-Dateien von Netzwerklaufwerken ist unproblematisch.
Darüber hinaus bieten sowohl Microsoft als auch Vmware einen Netzwerk-Boot nach dem PXE-Standard an, was eine Integration in eine bestehende Infrastruktur erleichtern kann. Ebenfalls bieten beide Lösungsanbieter fertige Images mit den vorinstallierten Betriebssystemen inklusive Lizenz an.
Wichtige Zusatztools
Die Installation des Gastbetriebssystems erfolgt identisch mit einer Installation in einer nicht virtualisierten Umgebung. Nach dem Setup müssen im Gastbetriebssystem noch die virtualisierten Treiber installiert werden. Sie heißen bei Microsoft "VM Additions" und bei Vmware "Vmware Tools". Insbesondere die virtuellen SCSI- und Netzwerkadapter sind für die Performance von entscheidender Bedeutung.
Unter Windows als Gastbetriebssystem ist diese Installation besonders einfach. Nach der Erstinstallation meldet man sich als Administrator an und kann aus der Verwaltungsumgebung per einfachem Mausklick die Installation anstoßen, die dann unter dem Gastbetriebssystem Windows automatisch anläuft. Nach einem weiteren Neustart ist die Gastmaschine mit deutlich erhöhter Leistung lauffähig.
Nicht ganz so einfach ist es unter Linux. Bei Vmware müssen aus einer Shell zwei Skripte ausgeführt werden. Das erste dient der Installation und das zweite der Konfiguration. Hierbei müssen auch einige Fragen beantwortet werden, zum Beispiel, wohin die einzelnen Komponenten kopiert werden sollen: /usr/bin oder /usr/local/bin.
Da es sich zum größten Teil um Kernelkomponenten handelt, gibt es Binaries nur für die offiziell unterstützten Linux-Distributionen als Gastbetriebssysteme. Für nicht offiziell unterstütze Versionen können die Treiber jedoch problemlos aus dem Konfigurationsskript kompiliert werden. Ein Test mit Fedora 5 verläuft ohne Probleme.
Dafür ist allerdings erforderlich, in der Gastmaschine mindestens den GCC-Compiler und die Kernelentwicklungskomponenten zu installieren. Dies ist unter Linux ohnehin von Vorteil, da bei einem Kernel-Update ohnehin alle selbst hinzugefügten Treiber jeweils neu kompiliert werden müssen.
Bei Microsoft Virtual Server sieht es geringfügig anders aus. Die VM Additions für Linux sind nicht im Produkt enthalten und müssen bei Microsoft Connect heruntergeladen werden. Eine Registrierung ist erforderlich. Die Microsoft-Tools müssen unter Linux generell neu kompiliert werden, was die Installation von GCC und den Kernel-Entwicklungskomponenten unerlässlich macht.
Für die täglichen Administrationsaufgaben eines virtuellen Servers eignen sich die vom Gastbetriebssystem zur Verfügung gestellten Remote-Login-Mechanismen besser als die Übernahme von Tastatur, Bildschirm und Maus der Gastmaschine durch die Virtualisierungslösung. Insbesondere Vmware mit Windows als Gastbetriebssystem zeigt sich hierbei nicht besonders performant. Unter Windows ist es einfacher, den Remote-Desktop zu verwenden, und unter Linux kann man Xwindows oder beispielsweise ein Shell-Login unter SSH nutzen.
Die Übernahme durch die Virtualisierungssoftware bleibt dennoch unerlässlich für den Fall, dass das Gastbetriebssystem nicht mehr im Multi-User-Betrieb funktioniert. Dies gilt für alle Fälle, in denen bei einem nicht virtualisierten Server ein physischer Zugang zum Server erforderlich wäre.
In puncto Leistung geben sich beide Systeme nicht viel. Bei rein prozessororientierten Aufgaben ist der Microsoft Virtual Server 2005 R2 etwa 5 Prozent langsamer als in einer nicht-virtualisierten Umgebung, während Vmware Server 1.0.1 etwa 14 Prozent Leistungsverlust aufweist. Servervirtualisierungsprojekte sind grundsätzlich nur dann performant, wenn eine leistungsfähige Multiprozessormaschine zur Verfügung steht.
Fazit
Beide Systeme eignen sich heute gut, um Servervirtualisierungsprojeke unter Windows zu realisieren. Vmware ist aber eindeutig Technologieführer. Neben 64-Bit-Gastbetriebssystemen und Dual-Prozessor-Unterstützung bietet Vmware wesentlich umfangreichere Tools, beispielsweise für den Serverumzug oder Server-Cloning, sowie eine bessere Unterstützung von Multi-Plattformumgebungen.
Bei der Hardware-Beschaffung sollte man auf die Unterstützung von Virtualisierungstechniken der Prozessorhersteller achten. AMD und Intel bieten Produkte an, die die Virtualisierung deutlich beschleunigen. Zudem bietet Vmware für große Virtualisierungslösungen noch den ESX-Server, der demnächst in einem weiteren Artikel ausführlich beleuchtet werden wird.
Lesen Sie auch: Virtualisierung: Newcomer Microsoft fordert Vmware[1]
URLs in diesem Artikel:
[1] = http://www.zdnet.de/enterprise/server/0,39023275,39149289,00.htm
