13.4 Funktionsumfang

Nachdem der VirtualCenter Server installiert ist, muss er an Ihre Infrastruktur angepasst werden. Da alle VMware Server und virtuellen Maschinen zu logischen Einheiten zusammengefasst werden können (ähnlich einer Struktur von Organisationseinheiten in einem Verzeichnisdienst wie z. B. Active Directory), bietet Ihnen VirtualCenter eine sehr gute Basis zur Strukturierung. Zudem stehen vielfältige Möglichkeiten der Erstellung, Konfiguration, Migration und Vervielfältigung der virtuellen Maschinen und in Teilen der VMware Server zur Verfügung. Darüber hinaus wird Ihnen ein flexibles Überwachungmedium an die Hand gegeben, mit dem auch ereignisgesteuerte Aktionen ausgelöst werden können. Das wichtige Thema Sicherheit kommt innerhalb des Produktes auch nicht zu kurz, denn es erweitert die Berechtigungsstruktur der VMware Server um ein Vielfaches.

13.4.1 Organisationsstruktur

Eine logisch korrekte und sinnhafte Struktur der VMware Server und der virtuellen Maschinen ist der wichtigste Schritt zum erfolgreichen Umgang mit dem VirtualCenter. Da Sie auf jede logische Einheit, im folgenden OU genannt, Berechtigungen vergeben können und diese in der Hierarchie vererbt werden, sollte auch dieser Aspekt berücksichtigt werden.

Nachdem Sie sich mit dem VirtualCenter Client angemeldet und die Lizenzen eingetragen haben (siehe Abschnitt 13.5, Lizenzen), befinden Sie sich in der grafischen Oberfläche des VirtualCenters. Hier existiert lediglich eine OU, die »Server Farms« genannt wird, unterhalb der sich später Ihre ganze logische Struktur befinden wird. Server Farms ist sozusagen die Root-Ebene (Abbildung 13.14). Innerhalb der grafischen Oberfläche erfolgt die Trennung wie bei einem Windows Explorer, d. h., links ist die Struktur zu sehen, und auf der rechten Seite sind die Eigenschaften der jeweiligen Auswahl angeordnet.

Abbildung 13.14 Der Anfang von allem innerhalb des VirtualCenters – gähnende Leere, die allerdings einen großen Vorteil bietet, da Sie auf der grünen Wiese anfangen können.

Die Struktur auf der linken Seite besteht aus mehreren möglichen OUs und den ihnen zugeordneten VMware Servern oder virtuellen Maschinen. In Abbildung 13.15 sehen Sie die hierarchische Strukur der einzelnen logischen Einheiten in einer Übersicht. Sobald Sie auf einer der logischen Einheiten mit der rechten Maustaste das Kontextmenü aufrufen, können Sie jeweils eine der untergeordneten Einheiten anlegen (Abbildung 13.14).

Tabelle 13.1 listet alle logischen Einheiten, die angelegt werden können:

Tabelle 13.1 Logische Einheiten innerhalb des VirtualCenters

Logische Einheit	Untergeordete Einheiten
Farm	Farm Group
Farm Group	Farm Group Host (GSX oder ESX Server) Virtual Machine Group Virtual Machine
Host
Virtual Machine Group	Virtual Machine Group Virtual Machine
Virtual Machine

Wie Sie in Tabelle 13.1 entnehmen können, ist es auch möglich, eine verschachtelte Struktur anzulegen. Innerhalb eine Farmgruppe können demnach weitere Farmgruppen, die wiederum Hosts und VMs enthalten, angelegt werden. Ebenso steht es mit den virtuellen Maschinen, wobei Sie mit verschachtelten Gruppen sehr gute Zuordnungen und für Ihre Unternehmensstruktur organisatorisch korrekte Gruppen anlegen können. Zudem können Sie mit Ausnahme von Hosts zu jeder logischen Einheit Berechtigungen pflegen.

Abbildung 13.15 Mögliche Struktur einer ausgebauten VirtualCenter-Landschaft mit sinnvoll angeordneten logischen Einheiten

Übrigens können Sie zu jedem Zeitpunkt die logischen Einheiten per Drag&Drop innerhalb der Gesamtstruktur verschieben. Die Grenzen werden nur durch die Logik der Hierarchie gesetzt.

13.4.2 Konfiguration des VMware Server

Da VMware VirtualCenter sowohl VMware GSX als auch VMware ESX Server unterstützt, können Sie die beiden – eine Agentenlizenz vorausgesetzt – auch unterhalb der Serverfarm einbinden. Die VMware Server selbst werden jedoch weder durch das VirtualCenter angelegt noch verwaltet. Der Verwaltungsmenüpunkt im Kontextmenü eines Servers verweist auf die Web-Administrationsoberfläche des jeweiligen Servers.

Integration VMware GSX

Um einen GSX Server integrieren zu können, müssen Sie einfach mit der rechten Maustaste auf die Serverfarm klicken und im darauf folgenden Kontextmenü Add Host auswählen (Abbildung 13.16). Daraufhin wird ein Wizard zur Anlage eines Servers gestartet. Zum selben Wizard gelangen Sie über + oder File • New • Add Host, wenn eine Serverfarm ausgewählt ist.

Abbildung 13.16 Anlegen eines neuen Hostservers innerhalb der Farm

Der Add Host Wizard fragt direkt nach den Angaben des hinzuzufügenden Servers, die aus der Netzwerkadresse, dem zu verwendenden Port und einem Benutzerprofil bestehen (Abbildung 13.17). Wichtig ist hierbei, dass der angegebene Benutzer Administratorrechte auf dem Server besitzt. Sobald Sie nun auf Next drücken, kontaktiert der VirtualCenter Server den VMware Server und prüft u. a. Produkt und Version ab. Hier wird entschieden, ob es ein GSX oder ESX Server ist, und dementsprechend werden alle Folgefragen darauf angepasst. Falls eine Firewall zwischen dem VirtualCenter Server und dem VMware Server existiert, muss diese den angegebenen Port durchlassen (Standardport 902). Falls Sie mit dem VirtualCenter Client über die Firewall an den VC Server müssen, ist zudem Port 905 freizugeben.

Abbildung 13.17 Anlage eines GSX Servers auf Microsoft Windows-Basis

Nachdem VirtualCenter den Server validiert und dabei einen GSX Server ausgemacht hat, werden Sie nach einem Benutzerprofil gefragt, mit dem später die virtuellen Maschinen gestartet werden sollen. Sie erinnern sich sicherlich an den Benutzeraccount unter VMware GSX, der angegeben werden musste, damit die virtuellen Maschinen automatisiert gestartet werden konnten. Da VirtualCenter prinzipiell nichts anderes als ein Automatismus zum Verwalten der virtuellen Maschinen ist, sollte hier ein neutraler Benutzeraccount angegeben werden. Falls Sie dies nicht wünschen, hindert Sie natürlich niemand daran, den Standardadministrator einzutragen.

Abbildung 13.18 Angabe des Virtual Machine Users bei Integration des VMware GSX Servers

Nach der Integration des Servers werden alle darauf registrierten virtuellen Maschinen automatisch im VirtualCenter unter Discovered VMs angelegt. Dazu zählen auch die als privat markierten virtuellen Maschinen, die Sie dann innerhalb des VirtualCenters mit Berechtigungen versehen können.

Integration VMware ESX

Der VMware ESX Server wird genau wie der VMware GSX Server über Add Host im VirtualCenter angelegt, wo dann die entsprechende Netzwerkadresse und ein administratives Benutzerprofil angegeben werden. Allerdings erscheint während des Erstellungsdialogs (Abbildung 13.17) eine Abfrage, ob VMotion auf dem ESX Server aktiviert werden soll. Grundvoraussetzung dafür ist auch hier eine gültige Lizenz, die im VirtualCenter hinterlegt ist.

Abbildung 13.19 Aktivierung der VMotion-Funktionalität innerhalb des VirtualCenters

In Abbildung 13.19 sehen Sie den Abfragedialog für die VMotion-Konfiguration. Nachdem VMotion erstmal eingeschaltet ist, müssen Sie noch die virtuelle Netzwerkverbindung (Network Label) angeben, über die später die Migration der VM stattfindet. Diese Netzwerkverbindung muss auf jedem teilnehmenden ESX Server und auf der virtuellen Maschine mit identischem Network Label auch existieren. Identisch heißt wirklich identisch, daher ist die Groß- und Kleinschreibung zu beachten. Neben dem Network Label muss noch eine freie Netzwerkadresse angegeben werden, mit der später VMotion zwischen den ESX Servern agiert. Falls die spätere VMotion-Verbindung über mehrere logische Netzwerke geht und demnach ein Router erforderlich ist, müssen Sie noch ein Netzwerk-Gateway angeben. Danach wird der ESX Server inklusive der darauf registrierten virtuellen Maschinen im VirtualCenter angelegt, und sie können ab diesem Zeitpunkt verwaltet werden (Abbildung 13.20). Die registrierten virtuellen Maschinen werden allerdings einer »unbekannten« Gruppe namens »Discovererd VMs« zugeordnet, die Sie natürlich sofort umbenennen sollten.

Abbildung 13.20 Nach der Integration des ESX Servers werden auch alle darauf laufenden virtuellen Maschinen hinzugefügt.

Verwaltung des VMware Servers

Da nun die VMware Server integriert sind, können sie auch verwaltet werden. Sobald Sie einen der Server, sei es nun ESX oder GSX, mit der rechten Maustaste anklicken, erscheint ein Kontextmenü, wie es in Abbildung 12.21 zu sehen ist. Hier können Sie nun neue virtuelle Maschinen anlegen bzw. anhand einer Vorlage erstellen lassen – aber dazu in einem späteren Abschnitt mehr. Allerdings ist ein Herunterfahren oder ein Neustart des Servers möglich, der über den Menüpunkt Shutdown angestoßen wird. Auch hier ist es empfehlenswert, in dem Bemerkungsfeld einen in Ihrem Unternehmen genormten Text anzugeben, um später alle Ereignisse besser nachvollziehen zu können.

Abbildung 13.21 Kontextmenü eines Servers unter VirtualCenter

Momentan viel wichtiger ist der Punkt Edit Host Configuration, der im Endeffekt nur ein Weblink auf die Web-Administrationsoberfläche des Servers ist. Das bedeutet, dass keine Konfigurationsänderungen am VMware Server selbst über das VirtualCenter vorgenommen werden können. Es beschränkt sich auf die Auswertung und Überwachung. Apropos Auswertung – über die beiden Menüpunkte Host Summary Report und Performance Report, können Sie sich detaillierte Informationen über die Auslastung und Ausstattung der Server und VMs beschaffen.

Abbildung 13.22 HTML-Datei, die über Host Summary Report generiert wurde

Während Ihnen der Host Summary Report eine Konfigurationsauflistung des Servers als HTML-Datei mit dem derzeitigen Stand generiert, können Sie über den Performance Report die Auslastung über einen bestimmten Zeitraum ausgeben. Dazu können Sie einfach, wie in Abbildung 13.23 zu sehen, den Pfad mit Dateinamen, die auszuwertenden »Core Four«-Komponenten (CPU, Memory, Disk, Network) und den Zeitraum auswählen. In der generierten Excel-Datei finden Sie zu jeder Komponente einen Graphen, die deren Auslastung anzeigt. Gerade Letzteres eignet sich hervorragend zur Vorbereitung von Präsentationen.

Abbildung 13.23 Einstellungsmöglichkeiten des Performance Reports

Mittels der Auswahl Remove, wird der Server mitsamt den zugehörigen VMs aus der Übersicht des VirtualCenters entfernt. Bedenken Sie hierbei, dass auch alle bis dato ermittelten Performancedaten unwiederbringlich verworfen werden. Daher empfiehlt es sich unter Umständen, vorher noch die Performancedaten des Servers und der VMs zu exportieren. Wer weiß, wann man diese Daten einmal benötigt. Properties als letzte Auswahl im Kontextmenü führt Sie abermals zu der VMotion-Konfiguration, falls es sich denn um einen VMware ESX Server handelt. Ansonsten können Sie hierüber den VMware VirtualCenter Agenten auf dem Server selbst neu starten (Abbildung 13.24). Dies kann nützlich sein, wenn der Kontakt zwischen dem VMware Server und VirtualCenter nicht korrekt funktioniert und beispielsweise keine Performancedaten mehr geliefert werden.

Abbildung 13.24 Eigenschaften des VMware Servers innerhalb des VirtualCenters

Soviel bis hierhin zum Kontextmenü eines VMware Servers unter VirtualCenter. Eine weitere interessante Serverfunktion bei VirtualCenter erschließt sich, wenn Sie den Server mit der linken Maustaste auswählen. Daraufhin erscheint im rechten Hauptfenster eine Übersicht, in der Sie sechs weitere Reiter finden, Summary, Virtual Machines, Performance, Tasks, Events und Alarms. An dieser Stelle sind besonders Summary und Tasks interessant. Die anderen Reiter heben wir uns für später auf.

Abbildung 13.25 Summary-Ansicht eines VMware ESX Servers im VirtualCenter

Der Reiter Summary zeigt Ihnen ein globale Übersicht Ihres VMware Servers an (Abbildung 13.25), die zum einen aus den Hardwareinformationen des Servers selbst besteht, aber auch aus den darauf laufenden virtuellen Maschinen und deren Auslastung. Darüber hinaus finden sich Informationen über die virtuellen Netzwerke, den verfügbaren VMFS-Plattenplatz und den verfügbaren Hauptspeicher für weitere virtuelle Maschinen. Unter dem Bereich Commands finden sich dann nochmals verschiedene Kommandos aus dem eben erklärten Kontextmenü.

Abbildung 13.26 Task-Ansicht eines VMware ESX Servers im VirtualCenter

Der andere, in diesem Zusammenhang erwähnenswerte Reiter namens Tasks bringt die Aufgaben bzw. Tätigkeiten des Servers in einer Übersicht zum Vorschein (Abbildung 13.26). Diese werden mit verschiedenen Eigenschaften im VirtualCenter hinterlegt, die aus dem Namen der Tätigkeit, dem betroffenen Server (oder VM), dem Fortschritt, dem Status und dem Benutzer bestehen, der diesen Befehl gab. Vor allem die Eigenschaft Fortschritt ist gerade bei der Migration, dem Klonen oder dem Anlegen neuer Vorlagen sehr interessant.

13.4.3 Erstellung einer virtuellen Maschine

Der Umgang mit virtuellen Maschinen ist die große Stärke des VirtualCenters, und nicht zuletzt deshalb können Sie mit ihm natürlich auch neue VMs anlegen. Beim Anlegen können Sie wiederum zwischen einer kompletten Neuerstellung, einem Klonen oder einem Erstellen mittels eines Templates unterscheiden. Für uns ist momentan nur die komplette Neuerstellung von Interesse. Dazu müssen Sie lediglich entweder im Kontextmenü des VMware Servers oder der Virtual Machine Group New Virtual Machine auswählen (Abbildung 13.21).

Abbildung 13.27 Wo soll die neue VM erstellt werden?

Nachdem Sie sich bei der Installation entweder für Typical oder für Custom entschieden haben, werden Sie nach der Virtual Machine Group gefragt, der die neue VM nach der Erstellung zugeordnet werden soll (Abbildung 13.27). Da Sie dies jederzeit per Drag&Drop ändern können, müssen Sie sich hier nicht allzu viel Kopfzerbrechen machen. Bei sehr großen Umgebungen kann es wiederum den Suchaufwand reduzieren.

Abbildung 13.28 Abschluss der Neuanlage

Die restlichen Installationsschritte sollten Ihnen aus den letzten Kapiteln bekannt sein. Diese Installation ist inhaltlich identisch und nur optisch verschieden. Aber was wäre die Welt ohne Ausnahmen. Eine Kleinigkeit gibt es noch beim Einsatz von Citrix Metaframe auf einer virtuellen Maschine zu beachten. VMware VirtualCenter fragt bei der Anlage einer neuen VM nicht nach, ob die Workload auf einen Citrix Terminal Server angepasst werden soll. Daher sollten Sie in diesem Fall die Zeile workload = "TerminalServices" der .vmx-Konfigurationsdatei der jeweiligen VM anhängen. Vorausgesetzt es hat alles geklappt, sollten Sie eine Meldung wie in Abbildung 13.28 erhalten, die Ihnen mitteilt, dass Sie sich bis zur endgültigen Erstellung noch etwas in Geduld üben müssen. Um den Erstellungsprozess im Auge zu behalten, können Sie auf die Task-Ansicht des VMware Servers zurückgreifen, auf dem die virtuelle Maschine erstellt wird.

Wenn virtuelle Maschine über das VirtualCenter erstellt werden, müssen Sie Folgendes beachten. Die Heimatverzeichnisse der virtuellen Maschinen, die mindestens die Konfigurationsdateien beinhalten, werden bei VMware ESX unter /home/vmware und bei VMware GSX unter dem bei der Integration angegebenen Benutzerprofil abgelegt.

13.4.4 Konfiguration einer virtuellen Maschine

Auch hier werden Sie prinzipiell nicht viel Neues feststellen, was Konfigurationsänderungen etc. angeht. Allerdings ist dies ja der größte Vorteil, sich gerade nicht noch ein neues Werkzeug mit eigenen Dialogen aneignen zu müssen, sondern sich direkt zurechtfinden zu können.

Um nun in die Konfiguration zu gelangen, müssen Sie einfach eine virtuelle Maschine in der Übersicht auswählen (Abbildung 13.29). Sobald dies geschehen ist, zeigt sich eine Übersicht mit allen relevanten Hardwareinformationen und ein ganzer Block mit Kommandos. Zudem existieren auch hier die Reiter, mit denen Sie sich Systemleistung, Tätigkeiten etc. anschauen können.

Abbildung 13.29 Summary-Ansicht einer virtuellen Maschine im VirtualCenter

Mit einem Klick auf Edit Properties gelangen Sie direkt in die Eigenschaftsansicht der virtuellen Maschine, die Sie übrigens auch direkt über das Kontextmenü einer VM erreichen können (Abbildung 13.30). Hier können Sie nun, wie gewohnt, die virtuelle Hardware anpassen bzw. ein CD- oder Floppy Image einlegen. Falls Sie eines der Geräte entfernen möchten, genügt es, dieses einfach auszuwählen und mittels Remove zu löschen.

Um neue Hardware hinzuzufügen wählen Sie einfach Add... aus, und es erscheint eine Auswahl der verfügbaren virtuellen Hardware (Abbildung 13.31). Dieser Hardware Wizard passt die verfügbaren Geräte an diejenigen des Wirt-Systems, also des VMware Servers an. Somit ist gewährleistet, dass Sie niemals nicht-unterstützte Hardware hinzufügen können.

Abbildung 13.30 Eigenschaften der VM im VirtualCenter

Abbildung 13.31 Hinzufügen virtueller Hardware einer ESX VM

Wenn wir vom Hardware zum Reiter Options wechseln, fällt auch hier eine Ähnlichkeit mit den herkömmlichen Optionen der MUI bzw. der VVMC auf. Besonders wichtig ist der Teil Configuration File unter der Sektion General, wo der genaue Pfad zur Konfigurationsdatei der VM (.vmx) steht.

Abbildung 13.32 Optionen der virtuellen Maschine im VirtualCenter

Die Sektion Power bietet Ihnen sämtliche bisher erwähnten Power-Optionen an, bzw., ob überhaupt und wie eine virtuelle Maschine beim Hochfahren des Wirt-Systems reagieren soll. Die letzte Sektion namens Advanced stellt Ihnen, wie zuvor bereits erwähnt, erweiterte Debugging-Optionen zur Verfügung.

Ressourcenkontrolle bei VMware ESX Servern

Wie Sie auch schon in Kapitel 12, Verwaltung der virtuellen Maschinen, erfahren haben, können Sie die vom Wirt-System bereitgestellten Ressourcen für die virtuelle Maschine sehr feinstufig und restriktiv einstellen. Diese Ressourceneinstellung können Sie entweder in den Eigenschaften jeder einzelnen virtuellen Maschine oder in einer Gesamtübersicht zentral verwalten. Innerhalb der VM-Eigenschaften müssen Sie zum Reiter Resources wechseln, den Sie in Abbildung 13.33 erkennen können.

Auch hier können Sie nun ähnlich der Webadministration die Core Four-Ressourceneinstellungen, die zugewiesenen Shares und die Prozessorzuordnungen pro virtueller Maschine anpassen. Es ist im Endeffekt nur eine andere und – wie ich finde – übersichtlichere Administrationsoberfläche zur Ressourcenkontrolle.

Abbildung 13.33 Einstellungsmöglichkeiten der VM-Ressourcen über deren Eigenschaften

Abbildung 13.34 Gesamtübersicht über die Ressourcenkontrolle aller virtuellen Maschinen der Virtual Machine Group

Die andere, weitaus übersichtlichere Verwaltungsansicht ist über den Kontextmenüpunkt Edit Virtual Machine Resources des VMware ESX Serverobjekts erreichbar. Hier werden Ihnen alle registrierten virtuellen Maschinen des ESX Servers aufgeführt, und Sie können die Anpassungen über einen Doppelklick auf die entsprechende Spalte der VM vornehmen. In Abbildung 13.34 sehen Sie des Weiteren die vier Reiter, mit denen Sie zwischen den Core Four-Komponenten wechseln können. Falls bezüglich der Ressourcenkontrolle noch Unklarheiten herrschen, empfehle ich Ihnen eine nochmalige Lektüre von Abschnitt 12.3.2, Optionen der virtuellen Maschine anpassen.

13.4.5 Migration der virtuellen Maschine

Man unterscheidet zwei verschiedene Migrationen innerhalb des VirtualCenters: »Cold Migration« und »Hot Migration«. Unter Cold Migration versteht man das Verschieben einer ausgeschalteten virtuellen Maschine von einem VMware Server zu einem anderen. Hier wäre auch ein Verschieben zwischen fremden Produkten also VMware GSX und VMware ESX Servern möglich. Mittels Hot Migration, auch »Vmotion« genannt, können sogar aktive virtuelle Maschinen zwischen ESX Servern ohne nennenswerte Ausfallzeit verschoben werden. Unglaublich, aber wahr: Hot Migration funktioniert wirklich. In meinen bisherigen Tests kam es noch nie zum Ausfall einer VM oder eines darauf laufenden Dienstes. Dieses Verfahren kann man besonders gut mit einem Citrix Terminalserver nachvollziehen. Ich selbst habe mit Microsoft Word in einer Citrix-Sitzung einen Text geschrieben, während die entsprechende VM migriert wurde. Es kam zu keinem Verlust von Tastatureingaben, man merkte lediglich eine kurze Pause von ca. 1 – 2 Sekunden. Dieses Verfahren der Hot Migration beeindruckt mich bis heute und zeigt die immensen Möglichkeiten der Virtualisierung deutlich auf.

Beim Migrieren einer virtuellen Maschine reagiert das VirtualCenter ein wenig untypisch im Vergleich zu der Vorgehensweise, die ein Administrator an den Tag legen würde. Diese Migration können Sie sich folgendermaßen vorstellen:

• Reservieren der benötigten Ressourcen auf dem Zielserver

• Kopieren der Konfigurationsdateien der VM auf den Zielserver

• Kopieren des Hauptspeicherinhalt der VM auf den Zielserver

• Freigeben der Festplattendateien der VM durch dem Quellserver

• Sperren der Festplattendateien der VM durch dem Zielserver

• Registrieren der VM auf dem Zielserver

• Umschalten der VM von Quell- auf Zielserver

• Aufheben der Registrierung auf dem Quellserver

• Löschen der .vmx-Konfigurationsdatei auf dem Quellserver

Gerade Letzteres kann beim Hardwareausfall eines ESX Servers zu Problemen führen, da alle .vmx-Dateien der dort laufenden VMs schlagartig nicht mehr zur Verfügung stehen. Daher kann ich Ihnen nur empfehlen, die Konfigurationsdateien regelmäßig zu sichern oder per Skript unter den ESX Servern in ein Sicherungsverzeichnis zu kopieren. Falls alle Stricke reißen, dann ist es kein Problem, einfach eine neue virtuelle Maschine mit den entsprechenden Festplattendateien und den Eigenschaften wie Name, Hauptspeicher und Netzwerk anzulegen. Es lebe die Dokumentation!

TIPP

Sowohl Cold als auch Hot Migration lassen sich im VirtualCenter nur innerhalb einer Serverfarm betreiben. Der einzige Ausweg aus dem Dilemma wäre die Verwendung eines Templates als »Mittelsmann«. Allerdings hat diese Beschränkung durchaus ihren Sinn. In großen Umgebungen existieren unter Umsänden verschiedene SAN-Anbindungen, auf denen die VMFS-Partitionen der ESX Server liegen. Fasst man nun alle ESX Server, die auf die gleichen VMFS-Partitionen zugreifen, zusammen, hat man über diese Beschränkung einen eingebauten Schutz, dass keine virtuellen Maschinen auf entfernte Massenspeicher migriert werden. Stellen Sie sich einen ESX Server an einem SAN-Subsystem in einer Außenstelle vor, die über eine 2 MBit-Verbindung an Ihre Zentrale angebunden ist. Wenn nun über die Zentrale eine Migration auf die ESX Server der Außenstelle ausgeführt werden würde, hätte das lange Wartezeiten und eine Blockierung der Außenstelle zur Folge.

Abbildung 13.35 Zur Migration einer VM muss im Kontextmenü der virtuellen Maschine Migrate ausgewählt werden

Sowohl die Cold- als auch die Hot Migration werden mit den gleichen Menüpunkten angestartet, nämlich entweder über das Kontextmenü der virtuellen Maschine (Abbildung 13.35) oder innerhalb der Summary-Ansicht (Abbildung 13.29) mit Migrate to new host. Sobald Sie diese Auswahl getroffen haben, erscheint der Virtual Machine Migration Wizard, der Sie durch die entsprechenden Abfragen führt. Des Weiteren können Sie mittels Drag&Drop migrieren, indem Sie das Objekt der virtuellen Maschine einfach mit gedrückter linker Maustaste auf den gewünschten Zielserver schieben. Falls Sie mehrere virtuelle Maschinen gleichzeitig verschieben möchten, können Sie das tun, indem Sie die VMs über die allseits bekannten Tasten ( – Bereich, – Einzeln) markieren.

Abbildung 13.36 Der Migration Wizard erscheint immer gleich, ob Hot oder Cold Migration

Die erste Abfrage betrifft den Zielserver, auf den die virtuelle Maschine migriert werden soll. Auch diese Abfrage ist unabhängig davon, ob eine Cold- oder eine Hot Migration stattfindet, da es hier um die Ablage der Konfigurationsdateien geht. Die Festplattendateien sind mit dieser Abfrage nicht gemeint. Auf den Screenshots zeige ich Ihnen nur die Umgebung bei Migration einer VM von einem ESX Server auf einen anderen. Es existiert ein Shared Storage-Bereich.

Abbildung 13.37 Auswahl des Zielservers für die Migration

Nachdem Sie den Zielservers ausgewählt haben, laufen die Abfragen des Migration Wizard zwischen Cold und Hot Migration auseinander, da bei einer Hot Migration keine Neuablage der Festplattendateien stattfinden muss.

Cold Migration

Bei einer Cold Migration werden Sie nun nach dem Ablageort der Festplattendateien gefragt. Unter VMware ESX werden Ihnen nur die verfügbaren VMFS-Partitionen gezeigt, VMware GSX hingegen zeigt Ihnen alle lokal verfügbaren Plattenbereiche an. Nach dem Migrieren wird die Festplattendatei mit sämtlichen REDO Logs oder Suspend-Dateien verschoben, d. h., diese Dateien existieren nur noch auf dem in Abbildung 13.38 angegebenen Speicherplatz.

Abbildung 13.38 Abfrage nach dem Ablageort der Festplattendateien. Da hier eine lokale VMFS-Partition auf dem ESX Server besteht, wird diese mit ihrem Friendly-Namen angezeigt.

Da eine Cold Migration auch zwischen GSX Servern, ESX Servern und unterschiedlichen Massenspeichern durchgeführt werden kann, wird der Migrationsprozess je nach Größe der Festplattendateien länger oder kürzer andauern. Der Ausfall an sich wird jedoch nie von kurzer Dauer sein und daher als Alternative zu Hot Migration, was die Verfügbarkeit angeht, komplett wegfallen. Dafür sind die Kosten einer Cold Migration sehr gering im Vergleich zu dem Einsatz von Vmotion, da Sie weder die teure Infrastruktur noch die Lizenzen benötigen. Zudem ist man deutlich flexibler, da keine gleichen Prozessoren oder Virtualisierungsprodukte Voraussetzung sind.

VMotion, Hot Migration

Um die begonnene Migration abzuschließen, müssen Sie nach Auswahl des Zielservers (Abbildung 13.37) die Priorität der Migration auswählen (Abbildung 13.39). Gerade diese Auswahl ist sehr wichtig, was die Verfügbarkeit der virtuellen Maschine angeht. Während bei der High Priority erst alle Ressourcen auf beiden Servern reserviert werden und nur bei optimalen Bedingungen migriert wird, verhält sich VirtualCenter bei einer Migration mit Low Priority wie die Axt im Walde und migriert unter allen Umständen. Im schlimmsten Fall kann es bei Low Priority zu einem »längeren« Ausfall der virtuellen Maschine kommen.

Abbildung 13.39 Abfrage zur Priorität der Migration

Leider unterliegt die Hot Migration einigen, teilweise recht harten Voraussetzungen. Dies rührt natürlich daher, dass doch recht große Datenmengen sehr schnell zwischen den Servern verschoben werden müssen, damit kein Ausfall entsteht. Da die Festplattendateien im SAN in einem shared Storage liegen, müssen nur der Hauptspeicher und die Konfigurationsdateien zwischen den ESX Servern verschoben werden. Bei einer virtuellen Maschine mit 3 GB RAM, die voll ausgelastet sind, kann eine solche Migration allerdings ein wenig Zeit in Anspruch nehmen. Das bedeutet aber keinesfalls einen Ausfall, sondern vielmehr Migrationszeit im Hintergrund, die Sie auf den beteiligten ESX Servern in der Task-Ansicht einsehen können.

Voraussetzungen für VMotion:

• Festplattendateien müssen in einem Shared Storage-SAN liegen, auf das beide teilnehmenden ESX Server Zugriff haben.

• Die Festplattendateien müssen in VMFS-Partitionen liegen, die einen Friendly-Namen haben. (Ab Version 2.5 können auch RAW Disks über Friendly-Namen als VMFS-Volume gemappt werden.)

• Gbit-Netzwerkverbindung mit einem gleichen Netzwerknamen innerhalb der Serverfarm. Empfohlen wird eine dedizierte Netzwerkverbindung zwischen den ESX Servern.

• gleiche CPU-Hersteller VMware Server (z. B. Intel oder AMD)

• gleiche CPU-Familie VMware Server (z. B. Pentium IV oder XEON)

Ich glaube, das größte Problem stellt das benötigte Storage Area Network dar, dessen Einrichtung, falls noch nicht vorhanden, eine doch sehr kostspielige Sache ist. In einem solchen Fall muss man sich die Frage stellen, ob eine Hot Migration mit VMotion den Kosten/Nutzen-Rahmen zu sehr sprengt und man darauf verzichtet. Weiterer Hemmschuh in gewachsenen Strukturen ist die Voraussetzung gleicher Prozessoren, die aufgrund der Vielzahl an möglichen Wirt-Systemen schwer zu erfüllen ist.

13.4.6 Klonen der virtuellen Maschine

Ein weiteres schönes Feature ist das automatisierte Klonen von virtuellen Maschinen, also die Erstellung einer neuen VM auf der Basis einer anderen. Aufgrund der festgelegten Dateien, aus der eine virtuelle Maschine besteht, ist diese Aufgabe auch manuell kein Problem, da sie einfach nur kopiert und danach ein wenig angepasst werden müssen. Allerdings kann VirtualCenter durch den Guest Customization Wizard deutlich mehr, können doch sogar Einstellungen innerhalb des Gast-Betriebssystems vorgenommen werden. Mehr dazu erfahren Sie in Abschnitt 13.4.8, Guest Customization Wizard.

Um nun den Wizard für den Cloning-Prozess anzustoßen, müssen Sie entweder in den Eigenschaften der VM oder im Kontextmenü den Eintrag Clone this Virtual Machine bzw. Clone ... auswählen, wie in Abbildung 13.40 gezeigt. Sobald der Clone Virtual Machine Wizard gestartet ist, werden Sie, wie Sie es schon von der Cold Migration her kennen, nach dem Zielserver und der zu verwendenden Virtual Machine Group gefragt.

Abbildung 13.40 Klonen einer virtuellen Maschine über die Eigenschaften oder das Kontextmenü

Danach werden Ihnen die verfügbaren Partitionen des Zielservers und dessen freier Speicherplatz angezeigt und zur Auswahl angeboten. Zudem können Sie den automatischen Start der virtuellen Maschine nach dem Klonen aktivieren. Dies kann vor allem dann überaus sinnvoll sein, wenn der Prozess automatisch ablaufen oder die VM für einen weiteren Mitarbeiter angelegt werden soll, der selbst jedoch über keinerlei Rechte verfügt, die VM zu starten (Abbildung 13.41).

Abbildung 13.41 Auswahl der Zielpartition während des Cloning-Prozesses

Sobald diese Auswahl getroffen ist, sind als Nächstes die vorhandenen virtuellen Netzwerkkarten an der Reihe. Wie in Abbildung 13.42 zu sehen, werden Ihnen die vorhandenen virtuellen Netzwerkkarten angezeigt, deren Zuordnung zu den entsprechenden virtuellen Netzwerken Sie nun anpassen können. Die Anzahl der virtuellen Netzwerkkarten hängt von der für das Klonen verwendeten Original-VM ab und sie werden mit NICn durchnummeriert. Nach dieser Zuordnung können Sie noch die Hauptspeichermenge und, falls es sich um einen ESX Server als Ziel handelt, die Priorität der Ressourcen ändern.

Abbildung 13.42 Zuordnung der virtuellen Netzwerken zu den verfügbaren virtuellen Netzwerkkarten

Und jetzt kommen die Stärken des VirtualCenters ins Spiel. Da Sie nun alle relevanten Angaben zur Konfiguration der virtuellen Maschine getätigt haben, greift der Customization Wizard in das Gast-Betriebssystem der virtuellen Maschine selbst ein. Genauer gesagt mit den Programmen Sysprep oder VMware Open Source Tools (siehe 13.4.8). In Abbildung 13.43 sehen Sie die Abfrage des Wizards zu dieser Funktion. Hier können Sie entweder den Guest Customization Wizard starten, der Sie nach allen betriebssystemspezifischen Einstellungen fragt, oder eine schon fertige XML-Datei einlesen, die vorher durch den Customization Wizard abgespeichert wurde, oder aber keinerlei Anpassungen machen, was zu einer ganz normalen Kopie führt. Wie der Guest Customization Wizard abläuft, erfahren Sie in Abschnitt 13.4.8.

Abbildung 13.43 Ab hier kann Sysprep bzw. sein Linux-Gegenstück gestartet werden.

Egal wie Sie sich entscheiden, nach diesem Schritt ist der Wizard beendet und der Cloning-Prozess startet, was Sie natürlich in der Task-Ansicht überwachen können. Sobald das Klonen abgeschlossen ist, existiert eine komplette Kopie der virtuellen Maschine mit allen installierten Programmen und Konfigurationen. Falls Sie den Customization Wizard bemüht haben, kann diese VM auch direkt produktiv genutzt werden, was in der Praxis sehr viel Zeit einspart. Übrigens ist das Klonen der virtuellen Maschine unabhängig von den Serverprodukten. Es kann demnach sowohl mit VMware GSX als auch VMware ESX und überkreuz genutzt werden.

13.4.7 Templates

Wenn Sie Cloning schon nützlich fanden, dann werden Sie von den Templates begeistert sein. Sie können dieses Verfahren mit dem eines Masterimages bei Imagingtools wie Symantec Ghost vergleichen, da von einer virtuellen Maschine eine Kopie gezogen und in einem Template-Verzeichnis dauerhaft abgelegt wird. Mittels dieses Templates können Sie jederzeit und sogar automatisiert eine neue virtuellen Maschine anlegen und auch vom Guest Customization Wizard anpassen lassen. Bei einem Windows 2003-Server mit einer Systemplatte von 10 GB dauert der Prozess der Neuerstellung einer VM mittels eines Templates ca. 15 Minuten. Danach steht Ihnen diese VM vollfunktional mit allen Gast-Betriebssystemanpassungen zur Verfügung.

Hier denkt man unwillkürlich an ein Disaster Recovery, weil unabhängig von der eingesetzten Backup Software eine neues System mit der gleichen Hardware, dem gleichen Betriebssystem, dem gleichen Servicepack-Stand und dem gleichen Computernamen installiert werden muss, bevor ein Rücksicherung, also ein Disaster Recovery überhaupt möglich ist. Falls all Ihre virtuellen Maschinen auf Templates basieren, wird dieser Prozess der Neuinstallation deutlich verkürzt. Während Sie bei einer manuellen Installation eines physikalischen Servers mindestens 1,5 Stunden benötigen, um überhaupt den Stand eines Templates zu erreichen, ist eine VM schon in 10 bis 20 Minuten fertig. Dies bedeutet eine Zeitersparnis von mehr als einer Stunde (meistens deutlich mehr) zwischen Ausfall des Systems und Rücksicherung der Daten.

Bevor Sie ein neues Template anlegen, sollten Sie je nach Ablageort ein Verzeichnis auf dem VirtualCenter Server anlegen und in den VirtualCenter-Eigenschaften hinterlegen. Falls Sie ein VMFS-Dateisystem als Ablageort nutzen möchten, ist diese Einstellung nicht relevant. Finden können Sie diese Einstellung über File • VMware VirtualCenter Settings im Reiter Templates. Dort können Sie den Pfad zu dem Templateverzeichnis mit beispielsweise d:\vc-template angeben. Bedenken Sie jedoch, dass diese Templates entsprechend viel Plattenplatz beanspruchen, weil sowohl Konfigurations- als auch Festplattendateien abgelegt werden.

Erstellung eines Templates

Abbildung 13.44 Die Erstellung eines Templates über die Eigenschaften der VM oder das Kontextmenü

Um ein Template zu erstellen, müssen Sie wiederum entweder in die Eigenschaften der VM wechseln und Create Template oder im Kontextmenü New Template from this Virtual Machine... auswählen (Abbildung 13.44). Danach wird der New Template Wizard gestartet, der Sie sofort auffordert einen Namen und gegebenenfalls eine Beschreibung für Ihr Template einzugeben (Abbildung 13.45).

Abbildung 13.45 Wie soll das Template benannt werden?

Über den Namen sollten Sie gerade in großen Umgebungen mehr als eine Sekunde nachdenken, denn gerade im Falle eines Ausfalls kann das kostbare Zeit einsparen helfen. Stellen Sie sich einfach vor, Sie hätten zwei Templates Windows SP4 und Windows SP2. In Wirklichkeit handelt es sich aber um Windows 2000 SP4 und Windows 2003 SP2 und bei falscher Auswahl muss die Erstellung der VM zweimal ablaufen. Dieses Beispiel mag zwar konstruiert erscheinen, zeigt Ihnen aber die Wichtigkeit der Namensvergabe recht pragmatisch auf.

Abbildung 13.46 Ablageort der Template-Dateien

Die nächste Frage des Wizards gilt dem Ablageort der Template-Dateien. Hier stehen Ihnen zwei Möglichkeiten zur Auswahl: auf dem VirtualCenter Server selbst oder auf einem für den ESX Server sichtbaren Datastore, also einer VMFS-Partition innerhalb des SAN. Die zweite Auswahl können Sie nur treffen, falls die VMware Server und der VirtualCenter Server auf die gleichen VMFS-Partitionen (SAN LUN) Zugriff haben. Um mehrere VMs gleichzeitig über ein Template erstellen zu können, muss dies auf dem ESX Server extra aktiviert werden. Innerhalb der Konfigurationsdatei /etc/vmware/config müssen Sie den Parameter template.useFlatDisks="TRUE" ändern bzw. hinzufügen und den VirtualCenter-Agenten neu starten.

TIPP

Bei der Verwendung der VMFS-Datastores für die Templates, sollten die VMFS-Partitionen manuell formatiert werden, damit die maximale Dateibegrenzung bei 1024 (vmkfstools -C vmfs2 –n 1024) statt normalerweise 256 Dateien liegt. Begründet liegt dieser Schritt darin, dass die Template-Dateien in 2GB Dateien aufgeteilt werden und dadurch deutlich mehr Dateien im VMFS liegen, als es bei normalen Festplattendateien der Fall wäre.

Ablageort VirtualCenter Server

Vorteile:

• Templates von VMware GSX und VMware ESX nutzbar

• bessere Sicherungsmöglichkeiten, da Windows NTFS-Dateisystem

Nachteile:

• Belastung des Netzwerkes

• langsamerer Umgang mit den Templates, als über VMFS Datastore, da neben dem FC-Netzwerk das Ethernetnetzwerk verwendet wird

Ablageort VMFS-Datastore

Vorteile:

• deutliche schnellere Handhabung der Templates, da sich alles innerhalb des FC-Netzwerkes abspielt

• keine Belastung des Ethernet-Netzwerkes

Nachteile:

• nur für VMware ESX verwendbar

• Sicherung nicht mit jeder Sicherungssoftware möglich, da die Daten im VMFS-Dateisystem liegen

Abbildung 13.47 Template-Ansicht im VirtualCenter – hier können Sie alle verfügbaren Templates sehen und verwalten.

Danach wird das Template angelegt und kann jederzeit für neue virtuelle Maschinen verwendet werden. Die Template-Dateien finden Sie entweder im ausgewählten Datastore oder im Template-Verzeichnis des VirtualCenters mit der Endung .vmtx (Template der Konfigurationsdatei) beziehungsweise .vmtd (Template der Festplattendateien). Zudem können Sie sich über den Reiter Templates alle derzeit vorhandenen Templates anzeigen lassen und auch verwalten, d. h. löschen, erstellen und verteilen (Abbildung 13.47).

Erstellung einer neuen VM mittels Template

Womit wir beim nächsten Thema wären. Nachdem die Templates erstellt sind, liegt es in der Natur der Sache, aus diesen neue virtuelle Maschinen anzulegen. Auch hier gibt es wieder viele verschiedene Wege, die zum Ziel führen, als da wären Kontextmenü des VMware Servers, der Virtual Machines-Ansicht des VMware Servers oder mit einem Rechtsklick auf eines der Templates in der Template-Ansicht. (Vom normalen Menü spreche ich schon gar nicht mehr.)

Abbildung 13.48 Erstellen einer neuen VM mittels Template über das Kontextmenü des VMware Servers

Ab diesem Zeitpunkt folgen die gleichen Fragen wie beim Cloning einer virtuellen Maschine, d. h., Sie können sich an Abschnitt 13.4.6 orientieren. Sobald Sie den Deploy Template Wizard und vielleicht auch den Guest Customization Wizard komplett durchlaufen haben, finden Sie die fertige VM an gewohnter Stelle innerhalb der VirtualCenter-Struktur.

13.4.8 Guest Customization Wizard

Sowohl beim Klonen als auch beim Erstellen einer neuen VM mittels Template haben Sie schon Bekanntschaft mit dem Aufruf des Guest Customization Wizards gemacht, der zum Vorkonfigurieren des Gast-Betriebssystems dient und für Microsoft Windows und wenige Linux-Derivate eingesetzt werden kann. Dazu muss je nach Gast-Betriebssystem Sysprep (Microsoft Windows) im entsprechenden VirtualCenter-Verzeichnis abgelegt oder die VMware Open Source Tools (Linux) müssen installiert werden. Neben der Vorkonfiguration von Rechnernamen und Netzwerkeigenschaften des Gast-Betriebssystems kann ein ganz wesentlicher Schritt für Windows-Systeme automatisiert werden, nämlich die Generierung einer neuen SID. Diese Generierung der neuen SID (Security Identifier) ist bei einem Windows-Betriebssystem zwingend notwendig, da dieser Rechner sonst nie eindeutig im Netzwerk zu identifizieren wäre. Falls Sie von dieser Thematik bisher unberührt blieben, dann googlen Sie einfach mal ein wenig oder schauen sich unter www.sysinternals.com die Beschreibung des kostenfreien NewSID Tools an.

Durch die Automatisierung beim Erstellungsprozess durch das VirtualCenter müssen Sie sich keinerlei Gedanken mehr über das Problem der Eindeutigkeit bei Windows-Systemen machen. Realisiert wird dieser Prozess übrigens über das Microsoft Programm Sysprep, mit dem ein Windows-Betriebssystem von allen individuellen Einstellungen befreit wird (Hardwarekonfiguration, SID). Diesen Sysprep-Lauf werden Sie innerhalb des VirtualCenters als Guest Customization Wizard wiederfinden. Einzige Voraussetzung ist, dass Sie das Microsoft Sysprep Tool in die festgelegten Verzeichnisse des VirtualCenters kopieren. %programfiles%\VMware\VMware VirtualCenter\resources\windows\sysprep ist das Wurzelverzeichnis der Sysprep Tools, das in verschiedene Versionen verzweigt.

Tabelle 13.2 Sysprep-Verzeichnisse des VirtualCenters

Verzeichnis	Inhalt
1.1	Version 1.1 der Sysprep Tools, die auf der Windows-Webseite zu finden sind. Das Sysprep Tool dieses Verzeichnisses wird dann verwendet, wenn die Verzeichnisse der entsprechenden Betriebssystemversion kein Sysprep enthalten. Allerdings wird diese Version nur für Windows 2000 unterstützt, funktioniert aber auch mit XP und Windows 2003.
2k	Sysprep Tool für Windows 2000
xp	Sysprep Tool für Windows XP
svr2003	Sysprep Tool für Windows 2003

Das Sysprep Tool in der Version 1.1 finden Sie unter der URL http://www.microsoft.com/windows2000/downloads/tools/sysprep/default.asp. Die Sysprep-Dateien für die einzelnen Betriebssysteme finden Sie auf jeder Betriebssystem-CD im Verzeichnis \Support\Tools in der DEPLOY.CAB-Datei, die Sie z. B. mit WinZIP öffnen und extrahieren können.

Mittlerweile existiert auch das Gegenstück für verschiedene Linux-Betriebssysteme, die durch die VMware Open Source Components gewährleistet wird. Diese Komponenten können Sie auf der VMware-Webseite unter http:// www.vmware.com/download innerhalb der Rubrik VirtualCenter finden, und sie müssen dann nur noch auf dem VirtualCenter Server installiert werden.

Folgende Betriebssysteme werden derzeit durch die VMware Open Source Components unterstützt:

• Red Hat Enterprise Linux AS 3.0

• Red Hat Advanced Server 2.1

• SUSE Linux Enterprise Server 8

Sobald Sie den Guest Customization Wizard starten (Abbildung 13.43), öffnet sich, vorausgesetzt Sie haben Sysprep oder die Open Source Components korrekt installiert, ein Dialog mit Fragen zur Konfiguration. Es gibt natürlich auch hier wieder Windows- und Linux-Varianten, die grundsätzliche Funktion bleibt aber gleich. Im Folgenden werde ich trotzdem nur auf die Microsoft Windows-Welt eingehen, erscheint sie mir doch ein wenig erklärungsbedürftiger.

Während des Dialoges werden Sie, ähnlich wie bei der Erstinstallation, nach allen relevanten Angaben eines Windows-Systems gefragt. Einige der wichtigsten sind hier beispielsweise Rechnername, Seriennummer, Administratorkennwort und Zeitzone. Irgendwann erscheint der Dialog zur Netzwerkkonfiguration, wie in Abbildung 13.49 zu sehen, in dem Sie schon die komplette Konfiguration des späteren Servers angeben können. Wenn Sie keine feste IP-Adresse benötigen oder sie später manuell einstellen möchten, reicht hier die Auswahl Typical Settings vollkommen aus, da alle virtuellen Netzwerkkarten automatisch für DHCP konfiguriert werden. Bei weitergehender Konfiguration über Custom Settings werden Sie bei jeder angeschlossenen virtuellen Netzwerkkarte einzeln nach IP-Adresse, Gateway, DNS und WINS Server gefragt.

Abbildung 13.49 Netzwerkkonfiguration über den Guest Customization Wizard

Eine überaus interessante Konfigurationseinstellung ist die Domänenmitgliedschaft. In Abbildung 13.50 sehen Sie die entsprechende Abfrage, über die Sie entscheiden können, ob die virtuelle Maschine Mitglied in einer Arbeitsgruppe oder einer Domäne werden soll. Falls Sie die Domänenmitgliedschaft wünschen, muss ein Benutzerprofil mit entsprechenden Rechten angegeben werden. Und denken Sie daran, dass die Netzwerkkonfiguration passen muss, weil sonst kein Domänencontroller gefunden werden kann, um die Mitgliedschaft einzurichten.

Abbildung 13.50 Soll die virtuelle Maschine direkt schon in einer Domäne Mitglied werden?

Nachdem alle wichtigen Windows-Konfigurationen angegeben wurden, folgt eine der wichtigsten Abfragen des Wizards. Über Generate New Security ID wird die schon erwähnte SID des Gast-Systems neu, und vor allem eindeutig generiert und in die relevanten Registry-Zweige geschrieben. Falls innerhalb des zu klonenden Servers oder des verwendeten Templates lokale Administratorenprofile existieren, deren Passwort nicht leer ist und die Sie mit einem neuen Passwort überschreiben wollen, müssen Sie Delete all user accounts auswählen.

Abbildung 13.51 Hier wird einer der wichtigsten Parameter »NewSID« abgefragt.

Zu guter Letzt werden Sie, falls gewünscht, noch nach einem Ablageort für die Konfigurationsdatei gefragt, die durch den Guest Customization Wizard erzeugt wird. Diese Konfigurationsdatei wird dann im XML-Format abgespeichert und kann für spätere Erstellungsprozesse wiederverwendet werden. Diese XML-Datei bedarf unbedingt eines Schutzes, denn alle Einstellungen inklusive Rechnernamen, Netzwerkkonfiguration und Seriennummer sind darin enthalten. Im Übrigen werden die Angaben zu den Kennwörtern immer verschlüsselt in dieser Konfigurationsdatei abgelegt.

13.4.9 Überwachung und Alarme

Jetzt, da alle VMware Server laufen und die virtuellen Maschinen angelegt sind, will man sie möglichst im Auge behalten. Dazu steht Ihnen einmal die Performance-Ansicht zur Verfügung, die Sie in den Eigenschaften jedes VMware Servers, der VM-Gruppen und der virtuellen Maschinen finden (Abbildung 13.52). Diese Performance-Monitore teilen sich auf die Core Four (CPU, Memory, Disk, Network) auf und stellen Ihnen alle Leistungsdaten ab dem Zeitpunkt der Überwachung durch das VirtualCenter bereit. Der Übersichtlichkeit wegen können Sie in der rechten oberen Ecke zwischen der Tages-, Wochen-, Monats- und Jahresansicht wechseln.

Abbildung 13.52 CPU Performance-Ansicht einer VM innerhalb des VirtualCenters

Während der Performance-Monitor nur der »manuellen« Überwachung dient, kann mittels Alarms eine ereignisgesteuerte Aktion ausgeführt werden (Abbildung 13.53). Alarme können sowohl für VMware Server als auch für virtuelle Maschinen hinterlegt und konfiguriert werden. Standardmäßig existieren immer drei vordefinierte Alarme, welche die Prozessorbelastung, den Heartbeat und die Hauptspeichernutzung überwachen und je nach Status zwischen OK (grün), Warnung (orange) und Fehler (rot) wechseln. Die vorkonfigurierten Alarme können übrigens weder angepasst noch gelöscht werden.

Abbildung 13.53 Ansicht der vorkonfigurierten Alarme für einen VMware Server und deren derzeitiger Status

Um einen neuen Alarm anzulegen, können Sie über das bekannte Kontextmenü der logischen Einheit oder über die Ansicht Alarms (Abbildung 13.53) gehen. Daraufhin öffnen sich die Eigenschaften dieses neuen Alarms, und Sie können ihm erst einmal einen Namen geben. Zudem können Sie je nach ausgewählter logischer Einheit (z. B. Server Farms) zwischen Host- und VM-Überwachung unterscheiden. Wenn Sie nun auf den Reiter Triggers wechseln, stehen verschiedenste Auslöser zur Auswahl. Hier können Sie sich nun auf recht einfache Weise Alarme zusammenstellen, die für Sie von Interesse sind.

Abbildung 13.54 Wann soll der Alarm ausgelöst werden?

Über Actions können Sie nun konfigurieren, welche Aktion wann ausgeführt werden soll. In Abbildung 13.55 beispielsweise würde eine E-Mail versandt werden, sobald der Alarmstatus des VMware Servers von gelb auf rot umspringt. Was hier momentan noch fehlt, ist eine Zeitsteuerung, die dafür sorgt, dass z. B. erst dann eine Aktion ausgelöst wird, wenn der rote Status 5 Minuten andauert. Vorsicht: Um E-Mails überhaupt versenden zu können, müssen Sie in der Konfiguration des VirtualCenter Servers einen Mailserver konfigurieren.

Abbildung 13.55 Was soll passieren, sobald ein Alarm ausgelöst wurde?

13.4.10 Geplante Tasks

Wie Sie soeben gelesen haben, können Sie verschiedene Aktionen aufgrund bestimmter Gegebenheiten ausführen. Diese durch Alarme ausgelösten Aktionen sind immer ereignisgesteuert und nicht vorhersehbar. Nun kann es aber durchaus sinnvoll sein, Aktionen zeitgesteuert durchführen zu lassen. Beispielsweise haben Sie mehrere VMware ESX Server im Einsatz und jede Nacht benötigt eine einzige virtuelle Maschine sehr viel Performance, da eine zeitkritische Anwendung läuft, während alle anderen VMs nur wenig ausgelastet sind. Da wäre es doch praktisch, mittels VMotion alle VMs bis auf die lastintensive von einem ESX Server auf die übrigen zu verteilen. Nachdem die zeitkritische Anwendung fertig ist, können die VMs wieder automatisch zurückgeschoben werden. Oder stellen Sie sich ein automatisches Backup vor, das von 20 – 23 Uhr läuft. Man würde die VM einfach um 19:50 ausschalten und um 23:15 wieder anlaufen lassen. Ich denke, Sie geben mir Recht, wenn ich konstatiere, dass es sehr viele dieser Anwendungsfälle gibt, die mit einem geplanten Task optimal gelöst werden können.

Abbildung 13.56 Anlegen eines Scheduled Tasks über den entsprechenden Reiter im VirtualCenter

Um nun einen solchen geplanten Task anzulegen, müssen Sie in die Ansicht Scheduled Tasks des VirtualCenters wechseln und dort entweder über New oder im Kontextmenü New Scheduled Tasks... den New Task Wizard starten. Dieser bietet Ihnen eine Vielzahl von vorgefertigten Aktionen an. Sei es das Anlegen einer VM mittels eines Templates oder automatisierte Anpassungen der Systemressourcen – die Auswahl ist groß (Abbildung 13.57).

Abbildung 13.57 Was soll getan werden? Es stehen Ihnen vielfältige Möglichkeiten, wie das Migrieren einer VM zur Auswahl.

Im Falle des Backups und dem zeitgesteuerten Herunterfahren der virtuellen Maschine wäre wie in der Liste in Abbildung 13.57 Change the power status of a virtual machine auszuwählen. Durch diese Auswahl werden Ihnen die vorhandenen Optionen, in diesem Fall die Power-Optionen angezeigt (Abbildung 13.58). Leider existiert hier noch keine Möglichkeit eines »sanften« Herunterfahrens des Gast-Systems, daher sollte man beim harten Power Off vorher ein Shutdown-Skript in der VM zeitgesteuert ausführen.

Abbildung 13.58 Zu jedem Task gibt es die entsprechenden Eigenschaften, hier die Power-Optionen.

Nach Auswahl der auszuführenden Aktion werden Sie nach der betroffenen virtuellen Maschine und, falls eine Migration oder ein Klonen ausgewählt wurde, nach dem gewünschten Zielsystem gefragt. Die Auswahlansicht (Abbildung 13.59) zeigt Ihnen die hierarchische Struktur des VirtualCenters an, was wiederum ein Beleg dafür ist, wie wichtig eine klare und sprechende Hierarchie und Namensvergabe ist.

Abbildung 13.59 Auf welcher virtuellen Maschine soll die Aktion ausgeführt werden?

Zum Schluss können Sie noch den Zeitpunkt der Ausführung und, falls gewünscht, ein Intervall angeben (Abbildung 13.60). Als Basis für die Zeitberechnung dient immer der VirtualCenter Server und nicht der Client. Falls eine Task nach jedem Neustart des VirtualCenter-Serverdienstes erfolgen soll, ist After Startup die richtige Wahl.

Abbildung 13.60 Wann und wie oft soll die Aktion ausgeführt werden.

Darüber hinaus können Sie sich zusätzlich bei jedem Lauf des Tasks per Mail über den Status informieren lassen. Danach ist der Task angelegt, und Sie können ihn in der Ansicht Scheduled Tasks sehen, bearbeiten und auch direkt aufrufen. Übrigens wird beim Löschen eines Objektes der zugehörige Scheduled Task ebenfalls gelöscht.

13.4.11 Sicherheit und Berechtigungen

Da auf einem VMware Server sehr viele kleinere, aber nicht minder wichtige Systeme laufen ist die Zugriffssicherheit immens wichtig. Wenn nun durch das VirtualCenter auch noch sehr viele VMware Server innerhalb einer Verwaltung administriert werden, gewinnt der Aspekt Sicherheit noch deutlich mehr an Gewicht. VirtualCenter bietet Ihnen daher eine simple, aber wirkungsvoll Berechtigungsstruktur, die weit über die nativen Sicherheitsfunktionen der VMware Server hinausgeht.

Abbildung 13.61 Anzeige der berechtigten Gruppen und Benutzer inklusive deren Rolle und zugeordneter Hierarchie

Einsehen können Sie die vergebenen Berechtigungen über den Reiter Permissions, der außer auf den VMware Servern in jeder logischen Einheit existiert. Alle Berechtigungen in der hierarchischen Struktur werden vererbt, wodurch eine Gruppe mit umfassenden Berechtigungen auf der höchsten Ebene (Server Farms) automatisch auf jeder darunter liegenden Ebene gleiche Rechte hat. Nach der Installation des VirtualCenter Servers wird die Gruppe der lokalen Administratoren automatisch auf der höchsten Hierarchieebene als VirtualCenter Administrator berechtigt. Falls Sie dies anpassen möchten, müssen Sie die Änderung ebenfalls auf der höchsten Hierarchieebene durchführen.

Um eine neue Berechtigung einzurichten, können Sie einfach im Reiter Permissions über das Kontextmenü (rechte Maustaste) Add Permissions anklicken, und es wird eine Ansicht mit den Windows-Berechtigungsgruppen angezeigt. Daher ist es auch empfehlenswert, den VirtualCenter Server zum Mitglied einer Domäne zu machen und Domänengruppen zur Berechtigung zu benutzen. Idealerweise würden Sie im Active Directory eine Gruppe namens »VirtualCenter Admins« anlegen, die Sie in der VirtualCenter-Hierarchie an oberster Stelle als VirtualCenter-Administratoren berechtigen und die lokale Gruppe der Administratoren entfernen. Dadurch können Sie durch die Gruppenzugehörigkeit im Active Directory den VirtualCenter-Zugriff und damit den Zugriff auf die VMware-Verwaltung zentral steuern.

Abbildung 13.62 Welche Berechtigung hätten Sie denn gerne? Die Rollen in Kombination mit den hierarchischen Einheiten erweitern die Berechtigungen der VMware Server um ein Vielfaches.

Bei der Anlage einer neuen oder der Änderung einer bestehenden Berechtigung, unterscheidet man zwischen vier verschiedenen Rollen:

• Read Only User

• Virtual Machine User

• Virtual Machine Administrator

• VMware VirtualCenter Administrator

Doch welche Berechtigung haben diese vier Rollen genau?

Tabelle 13.3 Berechtigungen der einzelnen Rollen im VMware VirtualCenter

Read Only User	Virtual Machine User	Virtual Machine Administrator	VMware VirtualCenter Administrator	Berechtigung
X	X	X	X	Ansicht Farmen, VMware Server und VMs
	X	X	X	Poweroperationen an VMs (Start/Stopp)
	X	X	X	Zugriff auf die Remote Console (Fernsteuerung)
		X	X	Hinzufügen und Entfernen von VMware Servern
		X	X	Hinzufügen, Entfernen und Verschieben von VMs inklusive Templates und Klonen
		X	X	Hinzufügen und Entfernen von Farmen und VM Gruppen
		X	X	Hinzufügen und Entfernen von Templates und Tasks
		X	X	VirtualCenter-Einstellungen ändern, inklusive Performance-Intervalle, Template-Verzeichnis und SNMP/SMTP-Einstellungen
			X	Hinzufügen und Ändern von Lizenzen
			X	Hinzufügen und Entfernen von Benutzerberechtigungen

Wie Sie leicht erkennen können, steigen die Berechtigungen bzgl. Administrationsgewalt von unten nach oben stufenweise an. Während ein VMware VirtualCenter Administrator alle Berechtigungen hat, darf ein Read Only User immer nur einsehen. Da diese Rollen immer nur für die zugeordnete logische Einheit und deren untergeordneten Einheiten gelten, ist eine sehr granulare und flexible Berechtigungsvergabe möglich.

13.4.12 VirtualCenter Konfiguration

Auf den letzten Seiten wurde schon des Öfteren die Möglichkeit einer Mailbenachrichtigung angesprochen, welche die Konfiguration eines Mailservers voraussetzt. Dieser Eintrag und vieles andere muss in den Einstellungen des VirtualCenter Servers eingetragen bzw. angepasst werden. Wenn Sie über File • VMware VirtualCenter Settings zu den Einstellungen wechseln, wie in Abbildung 13.63 zu sehen, wird Ihnen ein Dialog mit drei Reitern namens Performance, Templates und Advanced angezeigt.

Abbildung 13.63 Änderung des Aktualisierungsintervalls der Performancedaten

Im Reiter Performance können Sie sich neue Aktualisierungsintervalle für die Sammlung der Performance-Daten einrichten. Falls Sie beispielsweise gerne alle 10 Minuten eine aktualisierte Ansicht hätten, wäre hier die richtige Stelle, um dies einzurichten. Den Reiter Templates haben Sie schon in Abschnitt 13.4.7 kennen gelernt, dort wird einfach der lokale Pfad auf dem VirtualCenter Server angegeben, in dem die Template-Dateien abgelegt werden sollen.

Abbildung 13.64 Eintrag des Mailservers und der E-Mail-Adresse des Absenders

Der umfangreichste und mit wichtigste Reiter ist Advanced, da hier alle relevanten Einstellungen von SNMP über SMTP bis hin zum VirtualCenter Serverport administriert werden können. In Abbildung 13.64 sehen Sie die drei relevanten Mailservereinstellungen, Absenderadresse (absender@domaene.de), Mailserveradresse (mailserver.firma.de) und Mailserverport (25). Erst wenn diese Daten eingetragen sind, können Sie sich per E-Mail benachrichtigen lassen. Alle relevanten Parameter, die Sie hier eintragen können, sind im Handbuch genau beschrieben. Wenn alle Konfigurationsänderungen gemacht sind, können Sie den Dialog wie gewohnt mit OK beenden.

Abbildung 13.65 Mit Hilfe der Custom Attributes können Sie zu jeder VM zusätzliche Daten erfassen

Eine weitere schöne Funktion sind die Custom Attributes, mit denen zu jeder virtuellen Maschine zusätzliche eigene Daten erfasst werden können. Abbildung 13.65 zeigt Ihnen den Dialog, den Sie über File • Custom Attributes aufrufen können. Über Add bzw. Remove können neue Attribute erstellt bzw. vorhandene gelöscht werden. Sobald Sie ein neues Attribut hinzufügen, wird dieses als New Attribute erscheinen, das dann über einen einfachen Klick mit der linken Maustaste umbenannt werden kann. Sobald Custom-Attribute eingetragen sind, finden Sie diese in der Virtual Machines-Ansicht jeder Virtual Machine Group des VirtualCenters. Hier können Sie dann zu jeder virtuellen Maschine beispielsweise eine Kostenstelle oder einen Vermerk für den Support hinterlegen.

---

Ihre Meinung

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.