Virtuelle Piloten

Inhaltsverzeichnis

Virtuelle Maschinen erobern die Rechenzentren sowie die Testplätze von Admins und Entwicklern. Etablierte Produkte, etwa die von VMware [ii] oder Microsofts Virtual Server [4, iii] (siehe „Daten und Preise“) und andere, bilden die Hardware kompletter Rechner auf einem einzigen physischen Server in sogenannten virtuellen Maschinen (VM) nach. Mehrere solcher VMs, auch Gäste genannt, können parallel und unabhängig in abgeschotteten Umgebungen auf der echten Hardware laufen. Jede agiert dabei wie ein vollwertiger Rechner, in dem sich unterschiedliche Gast-Betriebssysteme installieren lassen.

Die Vorteile liegen in der Hardwareunabhängigkeit der VMs, da die virtuellen Geräte immer gleich bleiben, in der schnellen Bereitstellung neuer Server durch einfaches Kopieren von Vorlagen sowie einem unkomplizierten Desaster Recovery durch komplette Sicherung der virtuellen Systemplatten als sogenannte Behälterdateien. Beim Testen unterstützt der Virtualisierer das Anlegen von Wiederanlaufpunkten auf Mausklick durch Snapshots. Komplette Umgebungen sind durch Suspend/Resume in Sekunden hochgefahren.

Daten und Preise
VMware GSX Server 3.2:
Windows	1149 Euro für zwei CPUs, unlimitiert 2170 Euro
Linux	1063 Euro zwei CPUs unlimiert 2095 Euro
Anbieter	Bechtle IT Systemhaus , Regensburg. Weitere Vertriebspartner über VMware [ii].
Virtual Server	ab 479,20 Euro (www.bit-superstore.de)
Preise ohne MwSt

Vor- und Nachteile im Virtuellen

Dem steht als Nachteil gegenüber, dass für die VMs nur die Hardware zur Verfügung steht, die das Virtualisierungs-Layer bereitstellt. So fehlen ISDN-Karten, Firewire und eine vollwertige Grafikbeschleunigung. Ebenso wenig lassen sich Dongles im PCI-Slot ansprechen. Bisher können die Virtualisierer jeder VM nur maximal 3,6 GByte RAM zuweisen und nur der ESX-Server [3] von VMware kann einer VM mehr als eine CPU bereitstellen. Aufgrund des Overheads der Virtualisierung kommt es zu Performance-Einbußen. Der Host muss zusätzlich gesichert sein, da er den „Single Point of Failure“ darstellt.

Projekt virtueller Workshop

Auf der virtuellen Kopie eines Produktionsservers kann der Administrator gefahrlos neue Patches oder komplette Migrationen mit echten Daten und Benutzerkonten testen. Nebenbei erlernt er den Umgang mit virtuellen Maschinen, bevor er ihnen heiße Dienste anvertraut.

Ein Beispiel wäre die Migration einer NT4-Domäne auf Windows 2003. Ebenso gut ließe sich aber auch der Umstieg auf Linux-Server oder Netware in der virtuellen Pilotumgebung ausgiebig erproben. Den Auftakt bildet die Installation eines sauberen NT4 Domain Controllers (DC) als virtuelle Testmaschine, mit der sich die Migration mit beliebigen Wiederanläufen in Ruhe durchspielen lässt. Später kann man Kopien mehrerer Produktions-Server in die Testumgebung übernehmen und dort virtuell vernetzen.

Als Software bieten sich VMwares GSX Server 3.2 oder Microsofts Virtual Server 2005 R2 an. Sie bedienen ein breites Spektrum von Gast-Systemen, lassen sich einfach verwalten und unterstützen durch die darunter liegenden Betriebssysteme ein breite Hardwarepalette. Für die praktische Umsetzung fiel die Wahl auf den GSX Server, wegen seiner flexibleren Netzwerkoptionen und der größeren Anzahl offiziell unterstützter Gast- und Host-Betriebssysteme. Außerdem bietet VMware durch den großen Bruder ESX Server die Erweiterbarkeit auf Datacenter-Niveau.

Beim Hostsystem spricht für Windows, dass damit auch Linux-Unerfahrene auf Anhieb zurechtkommen; die beschriebene Vorgehensweise gilt prinzipiell aber ebenso für Linux (siehe „Linux als Basis“). Der Host sollte mit 4 GByte RAM ausgestattet sein, um mehrere VMs parallel bedienen zu können. Mehr Hauptspeicher erfordert die PAE-Unterstützung des Windows Advanced Servers oder die 64-Bit-Version auf passender Hardware. Eine CPU mit mindestens 1 GHz genügt für ein Testsystem, ein Dual-Board mit schnellen Prozessoren verhindert Frust, wenn es mal um etwas Größeres geht. Idealerweise verfügt der Host über getrennte Platten-Controller für System und VMs. Um später das Web-Interface des GSX verwenden zu können, muss man den IIS installieren.

Völlig unspektakulär verläuft das Setup des GSX Server. Er erzeugt unter anderem einige neue Dienste und zwei virtuelle Netzkarten im Hostsystem - zu deren Funktion später mehr.

Zwei neue Desktop-Verknüpfungen künden von der erfolgreichen Installation (Abb. 1). Die „VMware Virtual Machine Console“ (VMC) zeigt dabei auf das gleiche Programm wie die „VMware GSX Server Console“ (VSC), liefert nur einen zusätzlichen Parameter für den lokalen Host-Zugriff mit. Bei der VSC handelt es sich um eine Remote-Console zum Erstellen, Konfigurieren und Bedienen der VMs, die auch auf anderen PCs im LAN installiert sein können.

Administratoren können über HTTPS und Port 8333 auf das „VMware Management Interface“ zugreifen. Es bietet einen Überblick über den Status aller VMs und ermöglicht zusätzliche Einstellungen, etwa das Festlegen der Start-Reihenfolge für die VMs beim Hochfahren des Host. Eine API-Schnittstelle für COM und Perl sowie das Kommandozeilentool vmware-cmd für die Verwendung in Batch-Dateien runden das Angebot an Werkzeugen ab. Zusätzlich sind viele Parameter der laufenden VMs als Leistungsindikatoren im Systemmonitor von Windows über „Computerverwaltung > Leistungsprotokolle und Warnungen > Leistungsindikatoren“ verfügbar. Auf VMwares Website [ii] existieren Zusatztools, etwa zum direkten Einhängen virtueller Platten am Host, zum Import von Microsoft-VMs oder der VMware-Player zum kostenlosen Weitergeben lauffähiger Maschinen. Das kostenpflichtige „Virtual Center“ verwaltet und überwacht VMs auf mehreren Hosts unter einer einheitlichen Oberfläche.

Die erste VM erstellen

Gleich nach der Installation ist es sinnvoll, für die zukünftigen VMs ein eigenes Verzeichnis anzulegen. Unterordner wie „Testumgebung“ und „Produktion“ schaffen Überblick in der virtuellen Welt. Wenn möglich, sollten die VMs auf einem zweiten Plattensystem liegen, damit deren Datenträgerzugriffe nicht den Host behindern. Im Menüpunkt „Edit > Preferences > Workspace > Default Location“ lässt sich das Standardverzeichnis einstellen.

Mit wenigen Mausklicks, kann der Administrator in der Remote-Console über „File > New Virtual Machine ...“ den ersten virtuellen Server bauen. Der Konfigurationstyp „Custom“ ermöglicht die volle Kontrolle über alle Einstellungen. Nach der Wahl des geplanten Betriebssystems, eines passenden Namens und eines eigenen Verzeichnisses für die Maschine legt er die Berechtigungen fest. Für einen Test brauchen die VMs nicht als „privat“ deklariert zu sein und das Konto, unter dem sie laufen, kann das eines lokalen Administrators sein. Dabei sollte man nicht unnötig viel RAM zuweisen, denn alle Maschinen müssen sich den physischen Speicher mit dem Host teilen. Unter „Host > Settings > Memory“ lässt sich festlegen, ob eine Auslagerungsdatei (Swap File) verwendet wird. Das ermöglicht ein Zuweisen von mehr RAM, als physisch vorhanden ist, allerdings auf Kosten der Performance. Die Voreinstellungen für die Netzwerkkarte und für den I/O-Adaptertyp sind vorerst zu übernehmen.

Bei virtuellen Platten handelt es sich um Behälterdateien (Container) auf einem Datenträger des Host. Dorthin gelangen alle Schreib- und Lesezugriffe der VM, wobei deren OS sie wie normale Festplatten behandelt. Es lassen sich außerdem physische Platten direkt einbinden. Darauf dürfen aber keinesfalls die VM und der Host gleichzeitig zugreifen. Beide würden sich sonst gegenseitig vermeintlich freie Sektoren überschreiben. Deshalb die Warnung: Niemals bei Experimenten die Systempartition des Host als physische Platte in eine VM einbinden.

„Create a new virtual disk“, erstellt eine neue Platte, wobei bis zu vier IDE-Geräte und vier SCSI-Controller zur Verfügung stehen, unabhängig von der physischen Hardware des Host. Bei Verwendung von virtuellen SCSI-Platten kann es bei der Treiberunterstützung im OS der VM hapern; deshalb sollte man die Vorschläge des GSX-Wizards für Controller und Plattentyp vorerst beibehalten.

Entfernt man den Haken an „Preallocate all Disk Space now“, belegen die Container auf dem Host nur so viel Platz, wie sie brauchen und wachsen nur bei Bedarf. Anderenfalls reserviert der GSX Server das gesamte Volumen. Das verhindert zwar das Defragmentieren der Behälterdatei, verschenkt aber unnötig viel Platz in der Testumgebung. Ein Aufteilen der Behälterdateien in 2-GByte-Segmente mittels „Split disk into 2 GB Files“ ist bei einer FAT32-Partition nötig oder wenn man die VMs später auf DVD weitergeben will. Vor allem vereinfacht es das Übertragen virtueller Maschinen auf einen ESX-Server. Die Wahl eines sinnvollen Plattennamens, wie „nt4dc01_sys.vmdk“ erleichtert die Zuordnung. Später können weitere Platten für Daten oder für ein Swap File hinzukommen. Die Trennung der Datenträger bringt Vorteile beim Klonen sowie bei der Arbeit mit Snapshots und kommt einer späteren Verteilung auf mehrere physische Plattensysteme zum Lastausgleich entgegen.

Betriebssysteme in der VM

Der linke Teil der Remote-Console listet die erstellte Maschine im Inventory auf, rechts erreicht man alle VMs über eigene Reiter, unter denen normalerweise der Bildschirminhalt erscheint (Abb. 2). Ist die VM ausgeschaltet, zeigt die RC die zugewiesene Hardware an, die der Host-Verwalter über den Menüpunkt „VM > Settings“ jederzeit anpassen kann.

Die Buttons für Power-Off, Power-On und Reset wirken wie die Schalter eines echten PC. Der Suspend-Button friert eine laufende VM ein und schaltet sie anschließend ab. Später kann man die VM an genau dieser Stelle blitzschnell wieder auftauen, was einem nach dem Hochfahren des Host viel Zeit spart.

Für die Installation des NT4-DC sorgt einfach eine bootfähige Setup-CD im CD-Laufwerk, das VMware standardmäßig an alle VMs durchreicht. Ebenso lässt sich ein ISO-Image als CD einbinden. Einstellen lässt sich das über die Settings der VM oder praktisch im laufenden Betrieb über das kleine CD-Symbol unten rechts in der Statusleiste. Sollte die VM nicht von der CD starten, führt die F2-Taste direkt ins virtuelle CMOS-Setup, in dem eine Änderung der Boot-Reihenfolge für Abhilfe sorgen kann.

Um die Tastatur für eine VM verwenden zu können, muss der Anwender deren Fenster einmal anklicken. Mit der Tastenkombination STRG+ALT erhält das Host-System den Fokus wieder zurück. Diesen Hotkey kann er unter „Edit Preferences > HotKeys“ ändern. Als Ersatz für die Kombination STRG+ALT+ENTF, etwa beim Anmeldebildschirm der VM, dient die Kombination STRG+ALT+EINFG.

Nach erfolgreicher OS-Installation sollte man die VMware-Tools in der neuen Maschine einrichten. Sie bringen unter anderem eigene Treiber für Maus und VGA mit. Danach läuft der Fokuswechsel vom Host in die VM und umgekehrt nahtlos ab, ohne Klicken und STRG+ALT. Vor allem sorgen die Treiber für ruckelfreies Arbeiten mit der Maus, für vernünftige Bildschirmauflösungen und ein Cut&Paste zwischen Host und VMs. Zeitabgleich mit dem Host sowie automatisches Herunterfahren des OS in der VM mit oder ohne Ausführen eigener Scripts sind weitere Funktionen. Über den Menüpunkt „VM > Install VMware Tools“ richtet der GSX Server das Paket automatisch im Gast-OS ein. Bei Linux-Gästen muss man eventuell erst den X-Server beenden und einiges manuell erledigen, wie es im Handbuch beschrieben ist.

Updates und Patches

Dem frisch eingerichteten Domänencontroller fehlen jetzt noch alle Service-Packs, Patches und Programme. An dieser Stelle taucht die Frage auf, wie man Dateien mit der VM austauschen kann, oder einfacher, wie die VM ins Internet kommt, um sich dort Patches abzuholen.

In jeder Maschine kann der zuständige Admin dafür bis zu vier virtuelle Netzkarten einbauen. Sie erscheinen innerhalb der VM als AMD PCNET-Adapter, für den jedes Betriebssystem Treiber mitbringt. Alternativ installieren die VMware-Tools einen optimierten Treiber für einen „VMware PCI Ethernet Adapter“, den der Server emuliert, wenn man als Netzkartentyp „vmxnet“ anstelle „vlance“ wählt.

Den Typ jeder Netzkarte (siehe „Arten virtueller Adapter“) kann man im laufenden Betrieb umschalten, etwa unten rechts über die Statusleiste. Die VM behandelt das wie ein Umstecken eines Patchkabels. So kann der Tester eine Maschine mal eben ins LAN hängen und bei Störungen sofort wieder isolieren. Als LAN-Geschwindigkeit zeigt der AMD-PCNET-Treiber immer nur 10 MBit an, obwohl der GSX Server für die VMs die reale physikalische Geschwindigkeit des Anschlusses nutzt. Nur bei einer Gigabit-Emulation hängt der Durchsatz stark von der Leitung der CPU des Host ab. Eine detaillierte Netzwerkkonfiguration erscheint unter „Edit virtual Network Settings“. Dort kann der Netzwerker für einen NAT-Adapter Port Forwarding konfigurieren, den DHCP-Bereich für die internen Netze ändern und genau festlegen, über welche physische Netzkarten die VM mit dem LAN kommuniziert.

Frisch vernetzt lassen sich nun Patches aus dem Internet installieren und Daten aus dem LAN holen. Ist die Konfiguration der VM abgeschlossen, sollte man einen Snapshot erstellen, bevor der eigentliche Test beginnt. Ein Snapshot speichert im laufenden Betrieb den Systemzustand einer VM. Der GSX Server leitet ab dann alle Festplattenschreibzugriffe in Redo-Files um. Ein erneuter Snapshot überträgt die Änderungen und beginnt wieder mit leeren Redo-Files. Ein Revert verwirft alle Änderungen und stellt den letzten Systemzustand binnen Sekunden wieder her.

Will man bestimmte Platten vor Datenverlust schützen, muss man sie über den Button „Advanced“ in den Modus „independent-persistent“ setzen. Der GSX Server schreibt dort permanent weiter, dadurch bleiben bei einem Revert die Daten erhalten. Für den Plattenmodus „independent“ muss man sich vor dem ersten Snapshot entscheiden, danach lässt sich der Zustand nicht mehr ändern. Bei vorhandenen Independent-Platten funktionieren Snapshots nur noch im ausgeschalteten Zustand der VM. Ein „Remove Snapshot“ versetzt die VM wieder in den ungeschützten Status ohne Redo-Files, was alle Änderungen festschreibt, es sei denn, es erfolgte vorher noch ein Revert.

In der Testumgebung kann eine Migration bequem stattfinden, denn Wiederanläufe sind jederzeit möglich. Für ein komplettes Testnetz könnten weitere Maschinen hinzukommen, beispielsweise durch einfaches Kopieren des Ordners einer VM, wodurch ein vollständiger Klone entsteht. Es genügt aber auch, nur die virtuelle Systemplatte zu kopieren und in neue VMs einzubinden. So entstehen in Minuten Netze mit mehreren Clients und Servern. Nach dem Start einer kopierten VM erscheint die Abfrage nach einem neuen „unique identifier (UUID)“. Mit „create new ...“ ändert der Admin unter anderem die MAC-Adresse der emulierten Netzkarte, damit es nicht zu Konflikten mit der Ursprungs-VM kommt. Wie in der realen Welt braucht jeder Klon eine eindeutige IP-Adresse samt Rechnername. Und sofern die Betriebssysteme unter Lizenzen stehen, muss es für jede laufende VM eine eigene geben. Mit dem Tool Vmsnap darf man unter dem GSX-Server in Testumgebungen mehrere Snapshots und Linked-Clones anlegen, wie von VMwares Workstation 5.5 [2] her bekannt [i].

Physische Maschinen übernehmen

Zwar ist eine Migration in einer sauberen Testumgebung lehrreich, aber wenig aussagekräftig. Erst mit den realen Applikationen, Dateistrukturen und Benutzern lässt sich das Migrationskonzept auf Herz und Nieren prüfen.

Dazu kann der GSX Server echte in virtuelle Maschinen klonen, um in einem eigenen abgeschotteten Netz die reale Umgebung 1:1 nachzubilden - samt virtueller Clients. VMware und andere bieten für diesen sogenannten P2V-Vorgang (physical to virtual) kostenpflichtige Werkzeuge an, für den Anfang genügt aber ein wenig Handarbeit.

Im Quellsystem muss man zuerst einen „Standard-PCI-IDE-Controller“ oder den „VMware-SCSI-Controller“, erhältlich auf der VMware-Website, vorinstallieren, damit das System in der VM seine Boot-Platte findet. Anschließend empfiehlt sich ein Ausdünnen - das Entleeren von Temp-Ordner und Papierkorb, Löschen von Dump-Files und ähnliches. Danach fertigt man von der Systemplatte des Originals ein Image an, das man in einer Hilfs-VM auf eine leere virtuelle Platte überspielt. Benötigte zusätzliche Daten überträgt später die normale Sicherungssoftware. Gegebenenfalls muss in der geklonten VM eine Umstellung des HAL (Harware Abstraction Layer) auf eine Single-CPU und das Entfernen alter Treiber erfolgen. In vielen Fällen funktioniert das Übertragen auf Anhieb, aber es lauern noch Stolperfallen, wie ein Anpassen der boot.ini, unterschiedlicher Plattengeometrien et cetera. Auf der Website des Autors [i] gibt es dazu einen Workshop.

Nach ausgiebigen Probeläufen kann nun an einem Wochenende die geplante Migration stattfinden, wobei man erwägen sollte, ob man nicht den Schritt zur Virtualisierung des produktiven Systems wagt. Laufen alle Server in VMs, geht die Migration genauso bequem wie in der Testumgebung über die Bühne: Läuft etwas schief, ist mit einem Revert oder dem Einspielen einer Sicherungskopie alles wieder behoben. Es gibt aber noch weitere Hilfmittel: Um den neuen VMware Player und Linux geht es in einer der nächsten iX.

Sven Ahnert
betreut als Mitarbeiter eines Systemhauses mittelständische Firmen in den Bereichen Netzwerke und Serversysteme.

Literatur

[1] Michael Plura; Virtualisierung; Durchgeistigt; VMware Workstation 5 im Test; iX 7/2005, S. 72

[2] Michael Ziegler; Virtualisierung; Virtuelle Multivitamine; Auf Endbenutzer zugeschnitten: VMware ACE; iX 3/2005, S. 68

[3] Kai Dupke; Virtualisierung; Großer Bruder; VMware-ESX und Virtual Center im Test; iX 11/2004, S. 96

[4] Michael Plura; Server-Konsolidierung; Einer für alle; Microsoft Virtual Server 2004: erste Eindrücke; iX 5/2004, S. 70

Mehr Infos

iX-TRACT

• VMwares GSX-Server bietet die Virtualisierung von Servern unter Unix, Linux und Windows.
• Der Server selbst kann sowohl unter Linux als auch unter Windows laufen.
• Eine Reihe von Tools vereinfachen Konfiguration und Verwaltung.