8.3 VMware ESX

Wie schon erwähnt, ist der VMware ESX Server momentan die Königsklasse auf dem Gebiet der Servervirtualisierung. Das zeigt sich auch bei der Administration, die mit den meisten und umfangreichsten Funktionen daherkommt. Ebenso wie beim Microsoft-Konkurrenten ist die Web-Administrationsoberfläche, von einigen Kleinigkeiten einmal abgesehen, vollkommen ausprogrammiert und funktionell komplett. Auch ein Linux-Neuling kann prinzipiell problemlos mit dem ESX Server arbeiten, denn es steht sogar ein Dateimanager zur Verfügung, sobald das System erst einmal installiert ist. Die Webadministration wird automatisch gestartet, und Sie können – je nach Sicherheitseinstellung – sowohl über das HTTP- als auch über das HTTPS-Protokoll und den Standardport 80 auf die Web-Administrationsoberfläche zugreifen. Sie werden dann automatisch weitergeleitet. Nach erfolgreicher Anmeldung steht Ihnen von der Verwaltung der Partitionen über die der SAN LUNs bis hin zum Anlegen und Verwalten der virtuellen Maschinen alles zur Verfügung. Ein weiteres Highlight ist die Ressourcenkontrolle, die hier gleich alle vier Kernkomponenten, nämlich Prozessor, Hauptspeicher, Festplatte und Netzwerk umfasst. Hier können Sie auf unterschiedliche Weise Prioritäten und Wertigkeiten den einzelnen virtuellen Maschinen vergeben und verwalten. Die Webadministration stellt Ihnen alle verfügbaren Protokolle des VMware ESX nach protokollierendem Dienst getrennt im Browser dar.

Des Weiteren stehen Ihnen wie beim VMware GSX Server Kommandozeilenbefehle zur Verfügung, die aber im Vergleich zu denen des GSX Servers deutlich umfangreicher ausfallen. Davon können Sie sich anhand des Befehlsverzeichnisses in Anhang A überzeugen.

Die Programmierschnittstelle unterscheidet sich prinzipiell nicht vom VMware GSX Server, glänzt jedoch wiederum mit einem Mehr an Funktionen.

8.3.1 Web-Administrationsoberfläche

Sobald Sie mit der Startseite der Web-Administrationsoberfläche auf Port 80 des VMware ESX Servers verbunden sind, können Sie mit dem Reiter Status Monitor einen Systemmonitor öffnen, der Ihnen die Auslastung des Wirt-Systems und der darauf laufenden virtuellen Maschinen anzeigt, wie in Abbildung 8.16 zu sehen ist.

Abbildung 8.16 Statusanzeige VMware ESX Server

Direkt neben dem Status Monitor, befindet sich der Reiter Memory, der Ihnen sämtliche Informationen über den physikalischen und den ausgelagerten Hauptspeicher des Wirt-Systems liefert. In drei Abschnitten lassen sich der vorhandene physikalischen Hauptspeicher, der reservierte physikalische Hauptspeicher des Wirt-Systems und die Hauptspeicherstatistik der virtuellen Maschinen ablesen.

Da die Ressourcenbelegungen in Abbildung 8.17 wenig hinreichend erklärt werden, habe ich sie in Tabelle 8.1 noch einmal im Einzelnen beschrieben.

Abbildung 8.17 Statusanzeige des Hauptspeichers, der Verwendung insgesamt und durch z. B. Ballooning-Speichertechniken

Tabelle 8.1 Memory Status VMware ESX-Beschreibung

Ressourcenbelegung	Beschreibung
Virtual machines	Dieser Hauptspeicher ist den virtuellen Maschinen zugeordnet und wird von ihnen verwendet.
Shared Common	Dies ist der Speicherverbrauch, der durch die Speicherkopien der Sharing Memory-Technologie entsteht.
Virtualization	Der gesamte virtuelle Schwund (virtual overhead), der durch alle virtuellen Maschinen und den VMkernel erzeugt und verwendet wird. Dieser Speicher geht durch die Virtualisierung effektiv verloren.
Service Console	Die Service Console benötigt je nach Anzahl der virtuellen Maschinen eine entsprechende Menge an Hauptspeicher.
Free	Diese Haupspeichermenge kann noch durch die Service Console oder durch virtuelle Maschinen genutzt werden.
Total	Die Gesamtmenge des vorhandenen physikalischen Speichers wird hier angezeigt.
Memory Savings Due to Sharing	Diese Menge an Hauptspeicher wird durch die Sharing Memory-Technologie insgesamt eingespart.
RAM reserved	Diese Hauptspeichermenge wird durch die virtuellen Maschinen im physikalischen Hauptspeicher verwendet. Falls ein Auslagern des Hauptspeichers erlaubt ist, darf nur die Differenz zwischen der maximalen und der minimalen Menge an Hauptspeicher für die virtuelle Maschine benutzt werden, ansonsten liegt der komplette virtuelle Hauptspeicher der virtuellen Maschinen im physikalischen Hauptspeicher des Wirt-Systems.
RAM unreserved	zeigt den verfügbaren physikalischen Hauptspeicher für virtuelle Maschinen an
Swap reserved	durch virtuelle Maschinen verwendeter ausgelagerter Hauptspeicher, dem Swapfile des VMkernels
Swap unreserved	Es handelt sich hier um den verfügbaren ausgelagerten Hauptspeicher durch ein Swapfile des Vmkernels.
Memory available to Power on a Virtual Machine	Dieser Hauptspeicher steht Ihnen noch zur Anlage einer neuen virtuellen Maschine zur Verfügung. Da pro virtueller CPU ein gewisser Virtualisierungsoverhead existiert, ist hier eine gesonderte Anzeige für eine 1 CPU und eine 2 CPU VM vorgesehen.
Private	die Gesamtmenge des von virtuellen Maschinen genutzten Hauptspeichers; hier wird kein durch die Shared Memory-Technologie verwendeter Hauptspeicher aufgeführt
Shared	Dies ist der gesamte Hauptspeicher, der durch die Shared Memory-Technologie von den virtuellen Maschinen genutzt wird.
Swapped	Durch die Ballooning-Technologie wird die virtuelle Maschine gezwungen, in ihre lokale Auslagerungsdatei zu schreiben, um physikalischen Speicher des Wirt-Systems für andere virtuelle Maschinen freizugeben. Die Menge des dadurch in die lokale Auslagerungsdatei geschriebenen Hauptspeichers ist hier gemeint.
Balloon Driver	Hier ist die Menge des durch die Ballooning-Technologie freigegebenen Hauptspeichers abzulesen.
Unused	Hauptspeicher, der noch nie von virtuellen Maschinen benutzt und daher noch nie einer virtuellen Maschine zugeordnet wurde
Total	die Gesamtmenge des Hauptspeichers, die den virtuellen Maschinen zur Verfügung steht

Der Reiter Options ist zweifelsfrei zur Verwaltung des VMware ESX Server der wichtigste und bietet Ihnen eine Vielzahl von Einstellungsmöglichkeiten und Funktionen. Alle erforderlichen Einstellungstools sind zentral und schnell zugänglich, wie Sie Abbildung 8.18 entnehmen können.

TIPP

Die Leistungsanzeigen der MUI bzw. des VirtualCenters oder dem vmkusage Tool können variieren. VMware hat dazu allerdings ein Whitepaper veröffentlicht mit dem Titel »Comparing the MUI, VirtualCenter und vmkusage« (siehe VMware-Webseite oder auf der beiliegenden CD-ROM.

Abbildung 8.18 Optionsansicht der MUI des VMware ESX Servers

Den Anfang macht der Punkt Startup Profiles, über den Sie das Startverhalten des VMware ESX Servers beeinflussen können. Es kann unter anderem das Hyperthreading bei neueren Intel-Prozessoren aktiviert werden, der zugewiesenen Hauptspeicher der Service Console, der abhängig von der Anzahl der laufenden virtuellen Maschinen ist, kann bestimmt werden und die Hardware kann der Service Console oder dem VMkernel zugeordnet werden. Sie können prinzipiell beliebig viel Hauptspeicher der Service Console zuweisen, korrekt umgehen kann sie aber mit maximal 800 MB RAM. Da die Anzahl der lauffähigen virtuellen Maschinen von der Größe des Hauptspeichers der Service Console abhängig ist, können Sie sich leicht ausrechnen, wie viel Hauptspeicher Sie benötigen. Tabelle 8.2 vermittelt noch einmal einen Überblick.

Tabelle 8.2 Benötigter Hauptspeicher der Service Console

RAM Service Console	virtuelle Maschinen
192 MB	bis zu 8 virtuelle Maschinen
272 MB	bis zu 16 virtuelle Maschinen
384 MB	bis zu 32 virtuelle Maschinen
512 MB	mehr als 32 virtuelle Maschinen
800 MB	maximal verwaltbarer RAM

Gerade der Punkt Hardware Profile ist sehr wichtig, da es in Ihrer Hand liegt, die installierte Hardware zwischen der physikalischen Welt, dargestellt durch die Service Console, und der virtuellen Welt zu verschieben bzw. die Zuordnung fest vorzugeben. Zudem ist es teilweise möglich, beide »Welten« auf ein Gerät zugreifen zu lassen. Dies erweist sich besonders bei Bladeservern als wichtig, da die Anzahl der Massenspeicher- und Netzwerkkontroller doch recht beschränkt ist. Bei dieser Einstellung sollten Sie sehr vorsichtig und mit Bedacht zu Werke gehen, denn ein falscher Klick kann hier das vorläufige Ende Ihres VMware Servers bedeuten.

Da ich auf die Netzwerkeinstellungen in späteren Kapiteln noch genauer eingehe, sei hier nur gesagt, dass Sie über den Aufruf Network Connections die zu verwendenden physikalischen Netzwerkkarten und deren Verbindung prüfen und virtuelle Switches anlegen können.

Der nächste Punkt Users and Groups ist für das Thema Sicherheit sehr wichtig, da Sie hier Ihre Administratoren anlegen und verwalten können. Es empfiehlt sich, pro Administrator einen eigenen Benutzeraccount anzulegen, denn es können dann Rechte sauber zugeordnet und überwacht werden.

Unter dem Punkt Security Settings (Abbildung 8.19) können Sie Ihren VMware ESX Server anhand vorgefertigter Profile oder mit einer eigens erstellten Sicherheitsrichtlinie (Abbildung 8.20) mehr oder weniger wasserdicht machen. Als Securitystufe ist High zu wählen, werden doch auf dieser Stufe alle relevanten Dienste geschützt. Unter der Einstellung High stehen Ihnen für die Kommunikation nur noch verschlüsselte Verbindungen zur Konsole, zum Dateisystem, zur MUI und zur Remote Console zur Verfügung. Das Vorhandensein frei erhältlicher, guter Tools wie Putty oder WinSCP garantiert dabei, dass man auch unter Windows problemlos mit den erhöhten Sicherheitseinstellungen zurechtkommen kann.

Abbildung 8.19 Sicherheitseinstellungen des VMware ESX Servers

Abbildung 8.20 Bearbeitbare Sicherheitseinstellungen des VMware ESX Servers

Während Sie bei VMware GSX und bei Microsoft Virtual Server die SNMP-Unterstützung des Wirt-Systems nutzen müssen und keine Erweiterungen für SNMP existieren, bietet Ihnen der VMware ESX Server beides. Über die Auswahl SNMP Configuration können Sie den SNMP-Dienst aktivieren/deaktivieren (in der Ausgangskonfiguration deaktiviert) oder automatisch mit dem Wirt-System starten lassen. Hier können Sie auch die SNMP-Erweiterung und VMware SNMP Traps aktivieren. Eine Konfiguration der SNMP-Einstellungen ist leider nicht über die MUI möglich. Um das tun zu können, müssen Sie auf die Service Console zurückgreifen und im Verzeichnis /etc/snmp die Datei snmpd.conf anpassen, die allerdings weder groß noch komplex ist. Eine Integration der Konfiguration über die MUI wäre aber für zukünftige Versionen überaus wünschenswert.

Hinter dem Aufruf Licensing and Serial Numbers verbirgt sich, wie der Name schon sagt, die Verwaltung der Lizenzen. Hier müssen Sie die EULA akzeptieren und die Lizenznummern des VMware ESX Servers eingeben, da ansonsten keine virtuelle Maschine lauffähig ist. Gegebenenfalls ist hier noch eine SMP-Lizenz einzutragen, falls Sie zwei virtuelle Prozessoren innerhalb Ihrer virtuellen Maschinen verwenden möchten. Zudem wird hier die Laufzeit von Testlizenzen überwacht.

Unter Third Party System Management and Backup Tools finden Sie Internetlinks von englischsprachigen VMware-Seiten, die sich mit den verschiedenen Systemmanagement- und Backup-Programmen beschäftigen, wie beispielsweise Hewlett Packard Openview oder IBM Tivoli. Hier finden Sie auch alle Informationen zur Installation der einzelnen Softwareclients.

Storage Management ist vor allem bei der Nutzung eines Storage Area Networks sehr interessant, da hier nicht nur die redundanten FibreChannel-Wege eingesehen und konfiguriert, sondern auch einzelne LUNs mit dem VMFS-Dateisystem formatiert und benannt oder aber gelöscht werden können. Darüber hinaus können Sie hier mehrere VMFS-Partitionen miteinander verbinden (»Spanning«) und dadurch recht einfach die Kapazität einer VMFS-Partition erhöhen, falls beispielsweise eine neue Partition hinzukäme. Dies gilt allerdings nur für einen ESX Server. Falls mehreren Servern der Zugriff gewährt werden soll (Stichwort VMotion), kann Spanning nicht verwendet werden. Angesichts des Umstands, dass jede VMFS-Partition über eigene SCSI-Reservations verfügt, rate ich Ihnen von einem Spanning allerdings ab, da die Performance darunter leiden könnte. Wenn Sie bei existierenden Festplatten (besser Partitionen) mit edit in die Eigenschaften wechseln, eröffnet sich die Möglichkeit (Abbildung 8.21), den Access Mode von Public auf Shared umzustellen bzw. die maximal mögliche Dateigröße einzustellen, um das Dateisystem dahingehend zu optimieren. Der Access Mode sollte in normalen virtuellen Umgebungen auf dem Standard Public belassen werden, einzige Ausnahme sind virtuelle Maschinen auf unterschiedlichen VMware ESX Servern, die sich gegenseitig clustern.

Abbildung 8.21 Storage Management VMware ESX-Festplatteneigenschaften

Da Sie innerhalb eines Storage Area Networks von Ihrem Server aus mehrere Wege zum Storage-Subsystem einrichten können (eigentlich sollte man bei solch wichtigen Servern besser müssen statt können schreiben), müssen diese Wege natürlich auch konfiguriert werden können. Diese Möglichkeit bietet Failover Paths innerhalb der Storage Management-Funktion. Hier werden Ihnen die einzelnen Partitionen mit den verbundenen FibreChannel-Adaptern und damit die entsprechenden gleichen Wege angezeigt. Falls nun mehrere Wege existieren, können Sie über die Auswahl edit, wie in Abbildung 8.22 gezeigt, die Priortät der einzelnen FibreChannel-Adapter einstellen bzw. sie im Problemfall sogar deaktivieren. Des Weiteren können Sie die Art der LUN-Zuordnung im Fehlerfall festlegen. Es stehen dafür die beiden Alternativen Fixed und MRU (Most Recently Used) zur Verfügung. Während bei Fixed immer versucht wird, auf den fest eingestellten Prefered Adapter, also den bevorzugten Adapter zu wechseln, sobald dieser denn verfügbar ist, wird bei MRU der letzte funktionierende Weg beibehalten. Fixed ist zwar die voreingestellte Failover-Methode, sie muss allerdings nicht zwangsläufig die für Sie richtige sein.

TIPP

Leider kann der eigentliche prefered Path nicht über die MUI verwaltet werden. Dies ist jedoch über die Service Console mit dem Befehl vmkmultipath –s möglich (siehe Anhang B).

Folgendes Beispiel mag dazu beitragen, diesen Ablauf ein wenig zu verdeutlichen:

Angenommen Sie hätten zwei Wege über die FibreChannel-Adapter FC1 und FC2 zu LUN1, der Partition im SAN, auf der Ihre virtuelle Maschinen laufen. FC1 sei der bevorzugte Weg.

• Fall 1 (Fixed):

  Falls FC2 aufällt, merken Sie natürlich nichts, während bei einem Ausfall von FC1 der VMware ESX Server direkt auf den zweiten Weg über FC2 ausweicht. Sobald nun FC1 wieder online ist, wird automatisch wieder zu diesem Adapter und damit zu dem bevorzugten Weg gewechselt.

• Fall 2 (MRU):

  Auch hier bedeutet ein Ausfall von FC2 kein Problem. Wenn FC1 ausfällt, wird wieder automatisch auf den Weg über FC2 umgeschaltet. Wird FC1 wieder aktiv, bleibt der Weg über FC2 trotzdem aktiv, bis dieser ausfällt oder bis Sie manuell umschalten.

Fall 1 hört sich wahrscheinlich besser an, da immer auf den FC1-Adapter umgeschaltet wird, und Sie damit, solange kein Fehler auftritt, immer wissen, über welchen Weg der VMware ESX Server zugreift. Problematisch wird es, falls ein Fehler in der Konfiguration der Wege oder bei einem FibreChannel Switch auftritt, beispielsweise ein Wackelkontakt, der einen ständigen Neustart des Switches nach sich zieht. In diesem Fall würde es im Fall 1 ständig zu Problemen in Form von immensen Perfomanceverlusten kommen, weil aufgrund des defekten Switches immer wieder auf den »defekten Weg« zurückgeschaltet wird. Es käme zu einem Leistungsausfall, weil die Wege pingpongartig gewechselt werden würden.

Abbildung 8.22 Anpassung der Wege zu einem SAN Storage

Der letzte Reiter unterhalb der Storage Management-Funktion heißt Adapter Bindings und zeigt Ihnen die verfügbaren FibreChannel-Adapter und die damit verbundenen SAN Targets in Ihrem System an, welche die Plattensubsysteme darstellen.

Zurück im Options-Menü bietet Ihnen der Menüpunkt Swap Configuration die Möglichkeit, ein VMkernel Swap File anzulegen bzw. zu aktivieren. Das Swapfile muss auf einer VMFS-formatierten Partition liegen und von der Größe her so ausgelegt sein, wie Sie später die Technik Memory Overcommitment nutzen wollen, d. h., virtuellen Maschinen mehr Hauptspeicher geben wollen, als physikalischer verfügbar ist. Maximale sinnvolle Größe des Swapfiles sollte mit der Kapazität des physikalischen Hauptspeichers identisch sein, da Memory Overcommitment nicht mehr unterstützt wird. Falls Sie über die Kommandozeile Swap konfigurieren wollen, können Sie statt nur einer Auslagerungsdatei bis zu 8 erstellen und konfigurieren. Äußerst wichtig ist es, die Swapfiles auch zu aktivieren, weil sonst der VMware ESX Server darauf nicht zugreifen kann.

Abbildung 8.23 Advanced Settings des VMware ESX Servers

Die beiden Menüpunkte Advanced Settings und Service Console Settings zeigen Ihnen die konfigurierten Parameter des VMware ESX Servers bzw. der Service Console an. Unter Advanced Settings finden Sie eine Vielzahl von verschiedenen Parametern, die das Verhalten des VMware ESX Servers beeinflussen. Beispielsweise die Standardwerte der Shares, die zur Ressourcenkontrolle genutzt werden, oder das Maskieren der LUN IDs. Ein sehr wichtiger, hier angesiedelter Parameter ist der Disk.MaxLUN, der standardmäßig auf 8 gesetzt ist. Sollten Sie mehr als 8 LUNs verwenden wollen, müssen Sie diesen Parameter entsprechend einstellen.

Generell erhalten Sie zu allen einstellbaren Parametern einen kleinen Hilfetext, an dem Sie sich orientieren können. Bis auf die SAN-Einstellungen ist für den Standardbetrieb normalerweise keine Änderung vorzunehmen, für das Tuning des System sollte man aber alles Nötige finden. Anders steht es mit den Einstellungen, die Sie über Service Console Settings erreichen. Lassen Sie tunlichst die Finger davon. Vor allem sollten Sie die Werte keinesfalls heruntersetzen, da hier die Ressourcen und die Prioritäten der Service Console festgelegt werden. Eine falsche Konfiguration innerhalb dieser Einstellungen macht den VMware ESX Server sehr langsam oder sogar nicht mehr lauffähig. Daher sollten Sie es hier bei den Standardwerten belassen.

Der Menüpunkt Systemlogs (Abbildung 8.24) und die Verlinkung auf dessen Unterpunkt Availability Report (Abbildung 8.25) sind eine Anzeige auf die verschiedenen Logdateien des VMware ESX Servers bzw. eine Statistik über die Verfügbarkeit des Servers. Während im Normalbetrieb diese Logs eher informativer Natur sind, sind sie erste Anlaufstelle im Fehlerfall. Eine Erklärung zu den einzelnen Protokollen finden Sie in Abschnitt 8.3.4, Protokollierung. Der Availability Report liefert Ihnen detaillierte Informationen zur Up- oder Downtime des Systems. Das macht ihn auch zu einer interessanten Grundlage für Präsentationen, die beispielsweise vor der IT-Leitung abgehalten werden.

TIPP

Da Sie beim manuellen Herunterfahren oder Neustarten des ESX Servers mittels eines Popups nach dem Grund gefragt werden, sollten Sie sich in Ihrem Administrationsteam über die Syntax abstimmen. Dies ist zum einen für einen sauberen Report, zum anderen für die aussagekräftige Systemprotokollierung unabdingbar.

Abbildung 8.24 System Logs – alle wichtigen Protokolldateien des VMware ESX Servers

Abbildung 8.25 Availability Report, die Verfügbarkeitsstatistik des VMware ESX Servers

Falls Sie sehr viele VMware ESX Server in Ihrem Unternehmen installieren wollen, bietet sich die so genannte »Scripted Installation« an, mit deren Hilfe Sie eine automatisierte Installationsroutine für weitere VMware ESX Server anhand der Konfiguration eines bestehenden Servers erstellen können. Um überhaupt in diesen Genuss zu kommen, müssen Sie jedoch zunächst die notwendigen Programmteile installieren.

Installationsabfolge:

• Nachdem Sie die VMware ESX Server-CD am Server eingelegt haben, müssen Sie das CD-ROM mit mount /dev/cdrom einhängen.

• Danach ist der Befehl /usr/bin/scriptedinstall-setup.pl aufzurufen, der die benötigten Daten der CD auf die Festplatte des Servers kopiert, verschiedene Skriptdateien anlegt und zum Schluss den Apache Server (welcher die MUI bereitstellt) neu startet.

• Nun können Sie sich wieder in der MUI anmelden und unter dem Punkt Scripted Installation erscheint ein neuer Inhalt, wie in Abbildung 8.26 zu sehen ist.

Abbildung 8.26 Scripted Installation, die automatisierte Installation weiterer VMware ESX Server

Wenn Sie diesen neuen Menüpunkt durchklicken, werden Sie nach und nach alle Installationsparameter wiedererkennen, die bei der Installation eines VMware ESX Servers ohne Automatismus von Wichtigkeit waren. Dazu gehören die Parameter für die Service Console, wie IP-Adresse, die virtuellen Netzwerke, die Festplattenpartitionierung und das Anlegen des Swapfiles. Die Einrichtung virtueller Netzwerke und das Anlegen und Aktivieren des Swapfiles, die Sie bei der manuellen Installation nach der eigentlichen Installation manuell über die MUI machen mussten, sind Aufgaben, die Ihnen hier abgenommen werden.

Abbildung 8.27 Abschluss der automatischen Installationsroutine Scripted Install

Nachdem Sie alle Einstellungen vorgenommen haben, erscheint eine Abschlussseite, die Ihnen zwei Dateien zum Download anbietet: eine Kickstart-Datei, falls Sie eigene Softwareverteilungsprogramme einsetzen wollen, oder ein Diskettenimage. Dieses Image können Sie entweder mit dem Windows Tool rawrite oder mit dem Linux-Befehl dd (dd if=/tmp/Floppyimage of=/dev/fd0) auf eine Diskette zurückspielen. Mit dieser Diskette können Sie dann Booten und die automatische Installation durchlaufen lassen. In Tabelle 8.3 sehen Sie einige wichtige Passagen innerhalb der Kickstart-Datei (ks.cfg), die Sie zur Installation verschiedener Server anpassen müssen.

Tabelle 8.3 Kickstart-Sektionen

Sektion	Beschreibung
network --bootproto static --ip 192.168.0.1 --netmask 255.255.255.0 --gateway 192.168.0.254 --nameserver 192.168.0.1 --hostname ESXServerX	Netzwerk
vmaccepteula	Automatisches Akzeptieren der EULA
vmserialnum --esx=xxxx-xxxx-xxxx-xxxx --esxsmp=xxxx-xxxx-xxxx-xxxx	Seriennummern für ESX und VirtualSMP

Wie beim VMware GSX Server gibt es auch hier den Menüpunkt Virtual Machine Startup and Shutdown, unter dem Sie Einstellungen für das Start- und Stopp-Verhalten der virtuellen Maschinen und ihre Startreihenfolge beim automatischen Starten festlegen können. Dieses funktioniert genauso wie beim VMware GSX Server.

Zum letzten Punkt Shutdown and Reboot bleibt eigentlich nicht viel zu sagen, außer dass man vorsichtig damit umgehen sollte, weil auch alle laufenden virtuellen Maschinen beendet werden. Falls sie sich nicht selbst sauber herunterfahren können, werden sie vom System einfach ausgeschaltet, was einem Abschalten der Stromversorgung gleichkommt. Außerdem werden Sie immer nach einem Grund gefragt.

Falls Sie sich überhaupt nicht mit der Kommandozeile anfreunden können, aber trotzdem im Dateisystem arbeiten und beispielsweise Dateien kopieren, löschen oder umbenennen wollen, bietet Ihnen die MUI einen vergleichsweise einfachen, aber doch sehr komfortablen Dateimanager an, den Sie im rechten oberen Teil der Web-Administrationsoberfläche unter dem Menüpunkt Manage Files aufrufen können.

8.3.2 Kommandozeile

Während die Kommandozeile des VMware GSX Servers noch recht viele Lücken bezüglich der Administration lässt, ist die VMware ESX Kommandozeile absolut komplett, d. h., Sie können jeden Befehl innerhalb der MUI über die Kommandozeile nachvollziehen. Darüber hinaus sind alle Einstellungen in Konfigurationsdateien im Textformat abgelegt und können daher einfach ausgelesen werden. Vergleichbar mit der VMware GSX-Version unter Linux stehen Ihnen die Bash-Skriptierung und die Perl-Skriptierung zur Verfügung, um z. B. Konfigurations- oder Sicherungsskripte zu erstellen und zeit- oder ereignisgesteuert ablaufen zu lassen. In Anhang A finden Sie alle relevanten Befehle, die über die Kommandozeile verfügbar sind.

8.3.3 Programmierschnittstelle

Auch hier sind die Möglichkeiten absolut identisch mit denen des VMware GSX Servers, nur dass keine Windows-Programmierung auf dem Wirt-System möglich ist, da das mitgelieferte Wirt-Betriebssystem auf einem angepassten RedHat 7.2 Linux basiert. Ein Ansprechen dieser Programmierschnittstelle über das Netzwerk ist selbstverständlich von Windows- und Linux-Hosts über VmPerl oder VmCOM API möglich.

8.3.4 Protokollierung

Die Protokolle des VMware ESX Servers können über die Web-Administrationsoberfläche eingesehen werden. Zusätzlich muss noch die so genannte »VMdump Partition« angelegt werden, in der bei Abstürzen oder schwerwiegenden Problemen ein Speicherabbild geschrieben wird. Dieses Speicherabbild finden Sie später im Root-Verzeichnis. Da diese Protokolle verschiedene Komponenten des VMware ESX Servers betreffen und zudem, dank der Symbiose des Wirt-Betriebssystems und der Virtualisierungssoftware bei jeder Version an gleicher Postion stehen, habe ich für Sie die Protokolldatei mit dem Ablageort in Tabelle 8.4 zusammengefasst. Darüber hinaus kann über die Web-Administrationsoberfläche noch ein Availability Report erstellt werden, der die Verfügbarkeit des ESX Servers genauestens zusammenfasst. Den gleichen Report erzeugt der Kommandozeilenbefehl /usr/sbin/vmkuptime.pl.

Tabelle 8.4 VMware ESX Server-Protokolldateien

Name / Ablageort	Was wird protokolliert?
VMkernel-Warnungen /var/log/vmkwarning	VMkernel Warnungen – Hier finden Sie Warnungen der Virtualisierungssoftware. Falls es Probleme mit einer oder mehreren virtuellen Maschinen geben sollte, könnten Sie hier fündig werden. kritische Systemalarme – Darunter versteht man schwerwiegende Fehler wie z. B. auch Zugriffsprobleme auf die VMFS-Partitionen.
VMkernel-Protokoll /var/log/vmkernel	VMkernel Meldungen – Hier findet man alle normalen Meldungen, die aus der Virtualisierungsoftware kommen, wie beispielsweise Hauptspeicherzugriffe der virtuellen Maschinen,
Service Console-Protokoll /var/log/messages	alle Meldungen der Service Console – Alle Meldungen des Linux-Systems unterhalb der Virtualisierungssoftware werden hier abgelegt. Falls es Probleme beim Starten des ESX-Wirt-Systems geben sollte, wäre hier der erste Ansatzpunkt.

Über ein mitgeliefertes Zusatztool namens vmkusage ist eine komplette Webübersicht mit Historie über die Auslastung der virtuellen Maschine und des Wirt-Systems verfügbar.

---

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.