Powershell 2.0 verwaltet die VMware-Server, Teil 2
26. April 2011
Im ersten Teil wurde bereits gezeigt, welche Voraussetzungen für den Einsatz der PowerCLI gelten und wie die Verbindung zu einem ESX-Server von einer Workstation mit Powershell 2.0 mit installierter PowerCLI funktioniert. In diesem zweiten Teil geht es um verschiedene Aufgaben, die sich damit in einer ESX- beziehungsweise vSphere-4-Umgebung ausführen lassen.
Hier wird der Einsatz der verschiedenen Cmdlets gezeigt, die Verwaltungsaufgaben auf den VMware-Servern ausführen oder auch nur statistische Informationen über die Systeme liefern.
Nachdem die Voraussetzungen für den Einsatz der PowerCLI geklärt sind und die Verbindung von einer Workstation mit der Powershell 2.0 und den gewünschten VMware-Servern steht, kann der Administrator mit den eigentlichen Verwaltungsaufgaben beginnen. Alle vorbereitenden Maßnahmen schildert der erste Teil dieser Beitragsreihe.
Das PowerCLI verfügt über eine Vielzahl von Cmdlets, mit deren Hilfe sich die Protokolldateien auf einem Server und die zugehörigen, aktuellen Statistikdaten überprüfen lassen. Mit dem Cmdlet Get-Log zum Beispiel ist der Zugriff auf die Protokolldateien machbar. Doch üblicherweise wird der Administrator zuerst das Cmdlet Get-LogType benötigen.
Der Grund dafür ist ganz einfach: VMware-Server haben keinen festen Satz von Protokolldateien. Server auf der Basis von ESX und ESXi verfügen über weniger umfangreiche Sätze von Protokolldateien, da sie auch weniger Kerndienste bereit stellen – im Vergleich zu einem kompletten Server auf Basis von vSphere 4.
Aber auch her gibt es Besonderheiten zu beachten, da diese Protokolldateien mehrfach vorliegen – weil VMware die Protokolldateien rotiert und Sicherungen davon anlegt. Im einfachsten Fall hat man eine einfache Sammlung vorliegen, wie in Abbildung 2 zu sehen ist. Sie stammt von einem ESXi-Server. Um nur die Protokolleinträge von hostd zu bekommen, ist das folgende Kommando nötig:
Get-Log -Key hostd
Das PowerCLI gibt das Resultat dann als ein “Blob” von Einträgen zurück. Um sich die zugehörigen Textinformationen anzeigen zu lassen, muss der Administrator die zurück gelieferten Werte noch “expandieren”. Diese Aufgabe lässt sich wie folgt meistern:
(Get-Log -Key hostd).Entries
Wer wirklich alle bestehenden Protokolleinträge bekommen möchte, egal wie viele Protokolldateien und Einträge es auf dem betreffenden System gibt, der kann über eine Pipe die Ausgabe von Get-LogType in Get-Log leiten und so die Einträge für jede Protokolldatei expandieren:
Get-LogType | Get-Log | ForEach-Object { $_.Entries}
Doch das kann sich als eine sehr Ressourcen-intensive Aufgabe darstellen, vor allem beim betreffenden Server. Da gilt besonders für Systeme auf der Basis von ESX oder ESXi.
Wer kein Vorfiltern der Protokolleinträge ausführen will, und mit diesem Ansatz verstehen möchte, was alles auf dem betreffenden Server los ist, der sollte wohl besser das Bundling-Feature von Get-Log verwenden. Es wird zwar genauso lang dauern wie das interaktive Anzeigen der Protokolle, allerdings muss man es nur einmal ausführen. Zudem liefert dieser Ansatz auch einen noch einen kompletten Satz der Konfigurationsdateien des Servers.
Dazu muss der Administrator das Cmdlet Get-Log mit dem Bundle-Parameter aufrufen. Dazu ist dann noch der Pfad auf dem lokalen System anzugeben, in dem die Protokolle abgelegt werden sollen. Dieser Pfad muss aber bereits vorhanden sein. Soll das komplette “Bundle” zum Beispiel unter C:\tmp\Server1 abgelegt werden, muss man diesen Ordner zuvor anlegen. Dann ist das folgende Kommando nötig:
Get-Log -Bundle -DestinationPath c:\tmp\Server1
Wenn PowerCLI mit dem Zusammenfassen der Protokolle und ihrem Abspeichern fertig ist, gibt es einen Dateinamen zurück, der das Archiv für diese abgelegten Informationen angibt. Dabei handelt es sich um eine Standard-zip-Datei, wenn man VCenter einsetzt. Da die ESX- und ESXi-Server die üblichen Linux-Infrastruktur-Tools verwenden, wird es sich bei den Archiven um mit tar und zip verarbeitete Dateien mit der Endung .tgz handeln.
Öffnen lassen sich diese Archive mit Hilfe von WinZip oder 7-Zip.
In den Protokolldateien liegen Informationen über signifikante Ereignisse – und über die Konfiguration des Systems, wenn man das Bundle-Feature einsetzt. Wer dagegen mehr statistische Informationen braucht, der kann sich der Stat-Cmdlets bedienen, etwa um die Leistungsfähigkeit des Systems oder seine Auslastung zu bestimmen.
VMware-Server überwachen von sich aus bereits einen großen Bereich von Daten zur Leistungsfähigkeit des Servers, für virtuelle Maschinen (VMs), Resource Pools, Clusters und Hosts.
Für das Abfragen der statistischen Daten eines Servers, zu dem bereits eine Verbindung besteht, sind keine Besonderheiten nötig. Um sich zum Beispiel die unterschiedlichen Typen von Statistiken anzeigen zu lassen, ist nur das folgende Cmlet nötig:
Get-StatType
Dieses Cmdlet führt eine Liste von Namen oder “MetricIDs” von statistischen Größen auf, die von VMware verfolgt werden. Allerdings kann diese Liste auch sehr umfangreich und somit extrem unübersichtlich werden – zumal auch Doubletten in der Liste enthalten sein können. Etwas mehr Übersichtlichkeit kann daher nicht schaden – und das lässt sich über den folgenden Befehl erreichen:
Get-StatType | Sort-Object -Unique
In Bild 3 wird die ursprüngliche Ausgabe dieses Befehls gezeigt. Sie ist immer noch recht lang, allerdings ist die Liste bereits gekürzt und in alphabetischer Reihenfolge sortiert. Durch den Einsatz von einem oder mehreren dieser Namen, oder mit einer Variante, die Metazeichen (Wildcards) mit Get-Stat verbindet, lassen sich genauere Vorgeben machen, um die Statistiken des Servers abzufragen. Jedes der folgenden Kommandos verwendet eine legitime Angabe eines Statistik-Namens:
Get-Stat -Stat cpu.usage.average
Get-Stat -Stat cpu.u*.average
Das Cmdlet Get-Stat ist auch ohne das Aufzählen von Statistiktypen nützlich. Der Administrator kann auch ganz einfach eingeben:
Get-Stat
und damit bekommt er die angefallenen Statistikdaten für die Ausnutzung der Prozessoren, der Festplatten, des Arbeitsspeichers sowie der Netzwerkinterfaces für den betreffenden Server.
Ausführen von virtuellen Maschinen
Mit einem einfachen Kommando lassen sich VMs auf einem VMware-Server eintragen. Um jede VM, die auf dem derzeit angesprochenen Server zu ermitteln, und um dabei festzustellen ob die VM läuft (oder nicht), bedarf es nur des einfachen Befehls:
Get-VM
Dieses Kommando liefert eine Liste von VMware-Maschinen-Objekten zurück. Die standardmäßige Ausgabe wird den jeweiligen Namen der Maschine anzeigen, ihren Betriebszustand (sprich ihren PowerState), die CPU-Zahl und die Arbeitsspeichergröße. Dieses Cmdlet besitzt aber auch einige Parameter, um die Ausgabe abzuändern – genauer, sie zu filtern.
Der Parameter Name gehört dabei zu den am häufigsten eingesetzten Varianten. Damit besteht die Option, nur einzelne oder bestimmte Namen anzugeben, die können auch Metazeichen verwenden. Der folgende Befehl wird alle VMs liefern, deren Namen entweder mit XP oder Vista beginnt:
Get-VM -Name XP*,Vista*
Dieser Parameter erweist sich vor allem dann als besonders nützlich, wenn es darum geht, alle Maschinen auf einem VMware-Host zu ermitteln oder wenn man nur einige wenige VMs abfragen will, deren Namen alle einer gewissen Konvention folgen. Daher erweist es sich auch als sinnvoll, die Namenskonventionen für seine VMs konsistent zu halten.
Wer eine nicht allzu große VMware-Umgebung zu verwalten hat, der sollte auch weitere Parameter zu Get-VM ausprobieren. Als primäre Informationsquelle eignet sich die Help-Dokumentation sehr gut. Hier finden sich dann auch Ansätze für ein detailliertes Filtering.
Anlegen neuer Maschinen, Erstellen von Clones und Snapshots
Das Verwalten des kompletten VM-Bestands erweist sich in vielen Fällen al seine wahre Mammutaufgabe. Einige einfachere Aufgaben lassen sich aber gut demonstrieren. Auch hier leistet die Help-Dokumentation gute Dienste, wenn man komplexere Aufgaben zu bewältigen hat.
Wenn der Administrator eine neue VM in die Produktivumgebung einführen will, beginnt er üblicherweise mit einem Template. Dabei muss er nur den Namen dieser Vorlage kennen und sich einen Namen für die neue VM überlegen (Namenskonventionen einhalten macht das Leben einfacher).
Angenommen ein VMware-Template für Windows XP Professional trägt die Bezeichnung XppTemplate und daraus soll ein neues Gastsystem namens Xpp05 gebildet werden. Dann sieht der zugehörige Befehl wie folgt aus:
New-VM -Template XppTemplate -Name Xpp05
Beim Cloning wird das Cmdlet New-VM ebenfalls verwendet, allerdings gibt der Administrator logischerweise eine existierende VM an und nicht ein Template. Damit wird eine vollständige Kopie des Originalsystems erstellt (es gibt keine Möglichkeit, um sogenannte Linked Clones mit Hilfe von Cmdlets zu erstellen). Um die VM mit dem Namen Xpp05 zu klonen und daraus ein neues Testsystem namens XpTesting zu erstellen, muss folgender Befehl angegeben werden:
New-VM -VM Xpp05 -Name XpTesting
Als letzter genereller Punkt ist noch das Erstellen eines Snapshots nötig. Damit kann der Administrator zu einem festen Ausgangspunkt zurückkehren – sollte das einmal nötig werden. Der Befehl zum Snapshot lautet:
New-Snapshot -VM XpTesting -Name Creation
Damit wird dann ein Snapshot angefertigt – mit dem bezeichnenden Namen Snapshot.
Betriebszustände der virtuellen Maschinen
Zu PowerCLI gehören auch Cmdlets, um die Betriebszustände der Maschinen zu verwalten und zu steuern. Die meisten allerdings lassen sich nur dann sauber ausführen, wenn die VMware Tools innerhalb der VM installiert sind – doch das sollten die gängigen VMs immer haben, allein schon aus Performance-Gründen.
Das Starten einer VM ist der erste Schritt. Diese Aufgabe übernimmt das Cmdlet Start-VM. Für die VM namens Xpp05 sieht das wie folgt aus:
Start-VM -VM Xpp05
Bei den anderen Operationen an VMs machen die installierten VMware Tools den Unterschied aus. Ohne diese im Gastsystem installierten Tools müsste der Administrator das Neustarten (Restart), das Anhalten (Suspend) oder das Herunterfahren (Shut down) bei der VM Xpp05 wie folgt erledigen:
Restart-VM -VM Xpp05
Suspend-VM -VM Xpp05
Stop-VM -VM Xpp05
Diese Aktionen werden dann auf der angegebenen VM schlicht und einfach erzwungen.
Sollten aber die VMware Tools im Gastsystem installiert sein, kann man über die Cmdlets diese Tools ansprechen. Dabei wird die betreffende Aktion nicht “erzwungen”, sondern vielmehr angestoßen. Um das Neustarten, Anhalten oder Herunterfahren auf diese Weise zu absolvieren, sind die folgenden Befehle nötig:
Restart-VMGuest -VM Xpp05
Suspend-VMGuest -VM Xpp05
Shutdown-VMGuest -VM Xpp05
Auf eine Eigenheit sei dabei noch hingewiesen: Auch wenn die VMGuest-Cmdlets mit dem Gastbetriebssystem recht vorsichtig umgehen, so warnen sie die angeschlossenen Benutzer nicht davor, dass sich der Zustand der VM ändern wird. Wer ein herunterfahren mit diesen Cmdlets erledigen will, wird ein interaktiv angeschlossener Benutzer einen Herunterfahren-Vorgang sehen, den er nicht anhalten kann, oder aber er sieht nur seine aktuelle Sitzung einfach “verschwinden”.
Verschieben von laufenden VM
Wer mehrere Hosts in ESX-, ESXi- oder vSphere-4-Umgebungen betreibt, der kann laufende VMs bei einem sauber konfigurierten gemeinsamen Speicher von einem Host auf einen anderen Verschieben. Dazu ist das Tool VMotion von VMware nötig. Angenommen es liegt eine VM namens XP17 auf dem VMware-Host VH1. Und zudem besteht eine Verbindung zum Server VH1 und nun möchte man die VM XP17 auf einen anderen VMware-Host, das System VH2, verschieben. Dazu muss der Administrator nur ein VM-Objekt holen, dann dieses Objekt und das Zielsystem benennen und dann den Verschiebevorgang ausführen. Das sieht mit der PowerCLI so aus:
Move-VM -Destination VH2 -VM XP17
Unterdrücken von Bestätigungsmeldungen
Wer nun schon einige dieser Beispiele zur PowerCLI absolviert hat, der wird wahrscheinlich bemerkt haben, dass jedes Mal, wenn man etwas machen will, das entweder die Verbindung zu einem VMware-Server oder eine Sitzung eines Benutzers am VMware-Server betrifft, die PowerCLI einem zu einer Bestätigung auffordert. Das wird sich vor allem bei Skripts als großer Nachteil erweisen, den die sollte ja – zumindest zeitweise – unbeaufsichtigt und ohne Eingriffe des Anwenders ablaufen können.
Daher ist es sehr passend, dass es für alle Cmdlets, die eine derartige Bestätigung fordern, man dieses Verhalten abändern kann. Dazu gibt es den Parameter Confirm. Wenn der explizit auf false gesetzt ist, sind keine Bestätigungen nötig. Hierzu ist auch ein spezielle Syntax nötig: Der Wert für den Parameter muss über einen Doppelpunkt direkt an den Parameter angehängt werden. Damit sieht das so aus:
Confirm:$false
Um zum Beispiel die Bestätigung beim Neustarten (über Restart-VMGuest) zu unterdrücken, ist der folgende Befehl nötig:
Restart-VMGuest -VM Xpp05 -Confirm:$false
Dieses Vorgehen ist nötig, weil es sich beim Parameter Confirm um einen “Switch-Parameter” handelt. Der Name allein sagt der Powershell, dass e seine Bestätigungsnachfrage geben soll. Mit dem Einsatz des Doppelpunkts wird der Powershell dann gesagt, dass der Wert nach dem Doppelpunkt das Argument für den Parameter ist.
Abmelden vom Server
Ein letzter Schritt, der sich bei Skripts als seht wertvoll erweist, ist das Beenden der Verbindung mit dem Server. Das sollte man auch in einer interaktiven Sitzung machen, um möglichst sauber zu arbeiten. Dazu eignet sich das Cmdlet:
Disconnect-VIServer
Nach dem Ausführen dieses Cmdlets ist die aktuelle Verbindung zum Server geschlossen.
Auch wenn die Powershell und VMware die Verbindungen selbst – unter Umständen – schließen, sollte man doch diese Aktion in all seinen Aktivitäten mit der PowerCLI einbauen. Vor allem wenn Skripts umfangreiche Aktionen auf einem Server ausführen, ist diese Empfehlung sogar ein Muss. Das explizite Schließen einer Verbindung führt dazu, dass die Ressourcen unverzüglich wieder freigegeben werden. Damit kommt es zu weniger möglicherweise fehlerhaften Aktionen auf einem falschen Server.
Weitere Unterstützung: Die Ressourcen zur PowerCLI
In dieser Beitragsreihe wurde zwar eine komplette VMware-Verwaltungs-Session abgehandelt, doch dabei kam es nur zu einer Bekanntschaft mit wenigen, einfacheren Cmdlets. Es lassen sich aber weitaus komplexere Aufgaben mit Hilfe der PowerCLI bewältigen. Einige weiterführende Informationsquellen zur PowerCLI werden dem Administrator hier weiterhelfen.
Die Cmdlets der PowerCLI sind intern wie auch die native Powershell-Cmdlets dokumentiert. Daher kann der Administrator sich mit Get-Help und Get-Command detailliert in die einzelnen Cmdlets einarbeiten. Das PowerCLI bietet analog die PowerCLI-spezifischen Kommandos GetVICommand und Get-PoerCLIHelp.
Die standardmäßige PowerCLI-Installation besitzt auf Verweise, die man außerhalb des PowerCLI verwenden kann. Wer sich im Start-Menü das Verzeichnis VMware vSphere PowerCLI ansieht, der findet einen Verweis auf eine Windows-Hilfedatei namens vSphere PowerCLI Cmdlets Reference. Dabei handelt es sich um eine durchsuchbare Version der Konsolen-basierten Cmdlet-Help-Datei mit einem grafischen Interface. An derselben Stelle findet sich auch der vSphere PowerCLI Administration Guide (als PDF-Datei), der eine detaillierte Abfolge einer Sitzung mit PowerCLI zeigt.
Eine weitere, sehr nützliche Informationsquelle ist die Community zu PowerCLI im Web. Das PowerCLI selbst enthält das Cmdlet Get-PowerCLICommunity, mit dem automatisch ein Browser-Fenster geöffnet wird, das auf die Website der Community führt. Hier diskutieren Experten und Entwickler bei VMware. Zudem gibt e seine wachsende Sammlung von Skripts und anderen nützlichen Dokumenten zur PowerCLI.
