Shutdown von VMware ESXi-Hosts und VMs mit PowerCLI-Script
Für den Fall eines längeren Stromausfalls, den die USV nicht überbrücken kann, sollte die virtuelle Infrastruktur automatisch heruntergefahren werden, um Schaden zu vermeiden. Eingebunden in die USV-Software kann das folgende PowerCLI-Skript diese Aufgabe übernehmen.
Ablauf
Das Skript ermittelt alle laufenden VMs und fährt diese, gemäß der am ESX-Host vorgegebenen Reihenfolge, herunter; ist der Shutdown wegen fehlender/nicht laufender VMware Tools nicht möglich, wird die VM ausgeschaltet. Nachdem das Skript den Shutdown-Vorgang aller Gastsysteme angestoßen hat, wartet es bis die VMs heruntergefahren sind, oder die maximale Skriptlaufzeit überschritten wurde. Ist dieser Zeitpunkt erreicht, führt es den Shutdown der ESXi-Hosts durch.
Mit einer vSphere Hypervisor (Free ESXi)-Lizenz kann das Skript nicht genutzt werden.
Konfiguration
Zur Konfiguration wurden im oberen Teil des Skripts folgende Variablen hinterlegt:
| $VIServer | – Hier wird der vCenter-/ESXi-Server hinterlegt, über den die Verbindung hergestellt wird. |
| $credFile | – Zur Authentifizierung am vCenter-/ESXi-Server können Anmeldedaten hinterlegt werden. |
| $datacenter | – Filter auf bestimmte Datacenter („*“ = alle Datacenter). |
| $cluster | – Filter auf bestimmte Cluster („*“ = alle Cluster). |
| $VMhosts | – Filter auf bestimmte Hosts („*“ = alle Hosts). |
| $shutdownDelay | – Zusätzliche Verzögerung in Sekunden zwischen dem Shutdown der einzelnen VMs. |
| $maxWaitVMs | – Maximale Skriptlaufzeit bis zum Herunterfahren der ESXi-Hosts in Sekunden. |
| $testDelay | – Zusätzliche Verzögerung in Sekunden zwischen den einzelnen Prüfungen des PowerState der VMs. |
| $shutdownInOrder | – Herunterfahren der VMs in ($true)/entgegen ($false) der am Host vorgegebenen Startreihenfolge. |
| $excludeVMs | – Liste von VMs, die nicht heruntergefahren werden (mit dem Host beendet). |
Verbindung
Wird keine Verbindung zu einem vCenter-Server, sondern direkt zu einem ESXi-Host aufgebaut, ist es notwendig Zeile 46 auszukommentieren und statt dessen Zeile 47 zu nutzen.
Authentifizierung
Hat der ausführende Benutzer keine Berechtigung zur Verbindung mit dem Server kann über die Variable $credFile ein VICredentialStoreItem zur Authentifizierung genutzt werden. Erstellen kann man die Datei in der PowerCLI mit dem Befehl:
New-VICredentialStoreItem -host <Server IP/Name> -user <Benutzername> -password <Passwort> -file <Datei>
Der im Befehl angegebene Host wird im Skript nicht zur Verbindung verwendet; er wird durch $VIServer bestimmt.
Der Befehl muss unter dem ausführenden Benutzer ausgeführt werden, da das in der Datei verschlüsselte Passwort von anderen Benutzern nicht wieder entschlüsselt werden kann. Soll das Skript unter dem Benutzer NT-Authorität\System ausgeführt werden kann die PowerCLI-Shell mit dem Sysinternals-Tool PSExec gestartet werden, um eine passende Datei zu erstellen:
PSexec.exe -i -s C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe -psc „C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI\vim.psc1“ -noe -c „. \“C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI\Scripts\Initialize-PowerCLIEnvironment.ps1\““
(Pfade müssen ggf. angepasst werden -> s. Verknüpfung „VMware vSphere PowerCLI“)
Skriptausführung
Das PowerCLI-Skript kann, z.B. in einer Batch-Datei, mit folgendem Befehl aufgerufen werden:
C:\WINDOWS\SysWOW64\WindowsPowerShell\v1.0\powershell.exe -psc „C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI\vim.psc1“ -Command <Pfad>\PowerCLI-Shutdown.ps1
(Pfade müssen ggf. angepasst werden.)
Um mehrere Instanzen des Skripts parallel zu starten kann in einer Batch-Datei vor dem jeweiligen Befehl start.exe gesetzt werden:
start.exe <Befehl1>
start.exe <Befehl2>
…
Die Ausgabe kann mit >> in eine Textdatei geschrieben werden:
<Befehl> >> <LogFile>
Bei Verwendung der start.exe muss der Parameter /B angehängt werden, um die Ausgabe in eine Datei umzuleiten:
start.exe /B <Befehl> >> <LogFile>
Da die Ausführung von nicht-signierten Skripten standardmäßig nicht erlaubt ist, muss auf dem ausführenden System die Powershell ExecutionPolicy einmalig geändert werden:
Set-ExecutionPolicy RemoteSigned
Außerdem ist es ggf. notwendig das Powershell-Skript in den Dateieigenschaften zu entsperren:
Weitere Fehler, die Auftreten können:
– Aufgrund umpassender Proxyeinstellungen kann bei der Verbindung folgendes Problem auftreten:
Connect-VIServer : <date> <time> Connect-VIServer Could not connect using the requested protocol.
+ Connect-VIServer <<<< <VIServer>
+ CategoryInfo : ObjectNotFound: (:) [Connect-VIServer], ViServer
ConnectionException
+ FullyQualifiedErrorId : Client20_ConnectivityServiceImpl_Reconnect_ProtocolError,
VMware.VimAutomation.ViCore.Cmdlets.Commands.ConnectVIServer
Um die aktuellen Einstellung der PowerCLI zu ermitteln, kann der Befehler Get-PowerCLIConfiguration verwendet werden. Ist die Policy auf den Wert UseSystemProxy gesetzt, kann das Problem entweder durch Korrektur der Windows-Proxyeinstellungen behoben, oder – wenn kein Proxy benötigt wird – die Verwendung eines Proxys mit folgendem Befehl deaktiviert werden:
Set-PowerCLIConfiguration -ProxyPolicy NoProxy
– Unter Windows 2003/XP mit ESXi 5.5-Hosts kann diese Meldung auftreten:
Connect-VIServer : <date> <time> Connect-VIServer The underlying connection was closed: An unexpected error occurred on a send.
+ Connect-VIServer <<<< <VIServer>
+ CategoryInfo : NotSpecified: (:) [Connect-VIServer], ViError
+ FullyQualifiedErrorId : Client20_ConnectivityServiceImpl_Reconnect_WebEx
ception,VMware.VimAutomation.ViCore.Cmdlets.Commands.ConnectVIServer
Behoben werden kann sie durch Installation des Microsoft Hotfix KB948963 (s. auch VMware KB2031053)
Filter
Um nicht alle vom vCenter-Server verwalteten Hosts/VMs herunterzufahren, sondern nur einen bestimmten Cluster oder Datacenter kann die Auswahl über die Variablen $datacenter, $cluster und $VMhosts gefiltert, oder auch einzelne VMs über $excludeVMs vom Shutdown ausgeschlossen werden.
Natürlich sollte man sich vor dem produktiven Einsatz ausgiebig in einer Testumgebung mit dem Skript auseinandersetzen – ggf. mit Auskommentierung der Shutdown-Befehle (Zeilen 64, 69 und 121) – und die definierbaren Delays und die Gesamtlaufzeit mit Sorgfalt planen.
Download
- Skript: PowerCLI-Shutdown.ps1 (ZIP) – Letzte Änderung: 16.07.2012
Links
- PowerCLI: Shutdown your Virtual Infrastructure | Virtu-Al.Net
- VMware: New-VICredentialStoreItem
- Microsoft TechNet: PsExec
- VMware KB2031053: Search fails and Hardware Health and Health Status plug-ins are disabled in the vSphere Client
- Microsoft KB948963: An update is available to add support for the TLS_RSA_WITH_AES_128_CBC_SHA AES128-SHA and TLS_RSA_WITH_AES_256_CBC_SHA AES256-SHA AES cipher suites in Windows Server 2003
(16 Bewertungen, ⌀: 4,80 / 5)
Loading...
15. Februar 2013 um 16:31 Uhr - -
[…] man das wohl mit VB machen, aber hab davon echt keinen Plan. Das PowerCli Script ist von hier: Shutdown von VMware ESXi-Hosts und VMs mit PowerCLI-Script | blog.bistron.eu […]
1. April 2014 um 09:09 Uhr - -
Hallo Dennis,
dein Skript PowerCLI_Shutdown.ps1 ist genial. Soweit funktioniert es sehr gut. Nunmehr haben ich ein Frage an dich. Vielleicht kannst du helfen?
Eine zusätzliches Ziel ist es, dass Skript so „umzubiegen“, dass
— im ersten Schritt die „nicht-excludedVMs“ herunterfahren …
— dann eine definierte Zeit warten ..
— im zweiten Schritt die „excludedVMs“ herunterfahren …
— zum Schluss die ESX-Hosts herunterfahren
Kannst du helfen oder hast du einen Tipp wie man das realisieren kann?
VG
Joerg
8. Mai 2014 um 17:24 Uhr - -
Hallo,
gäbe es eine Möglichkeit VMs, die im vCenter unter gewissen VM Ordnern liegen priorisiert runterzufahren? Also den Ordner „Testlab“ als letztes und den Ordner „Produktion“ als erstes?
Gruß,
Daniel
12. Mai 2014 um 18:57 Uhr - -
Hallo Daniel,
ohne Anpassungen ist es nicht möglich Ordner zu priorisieren.
Die einzige Option, um die Reihenfolge zu beeinflussen, ist z.Z. die Festlegung der Startreihenfolge am ESXi-Host (+ $shutdownInOrder).
MfG
5. Oktober 2014 um 17:14 Uhr - -
Hallo Dennis,
sehr interessanter Ansatz, nachdem der Shutdown-Wizard meiner Powerwalker-USV so gar nicht wirklich laufen will.
Ich habe meinen ESXI-Host direkt eingetragen, leider funktioniert das Script nicht wirklich: Er sieht zwar die beiden laufenden VM’s, es wird aber nichts heruntergefahren. Vorher kommt auch eine Fehlermeldung:
Name Port User
—- —- —-
10.0.1.100 443 root
2014-10-05 16:35:45 CollectEnvData
Get-VMStartPolicy : 05.10.2014 16:35:48 Get-VMStartPolicy Der angefor
derte Wert „systemDefault“ konnte nicht gefunden werden.
Bei C:PowerWalker2.12PowerCLI-Shutdown.ps1:51 Zeichen:47
+ $shutdownOrder = $ESXHosts | Get-VMStartPolicy <<<< | Sort-Object -Property
@{Expression="StartAction";Descending=$true},@{Expression="StartOrder";Ascendin
g=$shutdownInOrder}
+ CategoryInfo : NotSpecified: (:) [Get-VMStartPolicy], VimExcept
ion
+ FullyQualifiedErrorId : Core_BaseCmdlet_UnknownError,VMware.VimAutomatio
n.ViCore.Cmdlets.Commands.Host.GetVMStartPolicy
2014-10-05 16:35:48 ExcludedVMsOnl
2014-10-05 16:35:48 Waiting 2/2 VMs online / 00:03:50.1734380 left…
So I guess there is a problem with "Get-VMStartPolicy" … from the vSphere documentation I also understand that this command does not work on a single ESXI host?
Is there any modification which works without this?
28. Oktober 2014 um 22:45 Uhr - -
Hallo,
nachdem ich einen Kommentar von Max im VMware PowerCLI Blog gefunden hatte, konnte ich das Problem nachstellen.
Wie dort beschrieben tritt der Fehler nur auf, wenn in der
vmAutoStart.xml(auf dem ESXi-Host unter/etc/vmware/hostd/) für stopAction der Wert systemDefault mit kleinem „s“ steht (bei waitForHeartbeat scheint es nicht zu stören).Demnach könntest Du Dir mal die Einträge in Deiner
vmAutoStart.xmlansehen und sie ggf. entsprechend anzupassen. Nach einem Neustart des hostd, sollte das Skript ohne Fehler laufen.Auch wenn bei meinem Test keine Probleme auftraten: bitte zumindest erst auf einem Testsystem nachstellen und die Sicherungskopie der vmAutoStart.xml nicht vergessen… im Zweifel besser den VMware-Support kontaktieren 😉
MfG
8. April 2019 um 00:55 Uhr - -
Hi,
ich habe das identische Problem. Bei mir war das systemDefault mit kleinem s. Ich habe es mit einem grossen ersetzt. Den Host neu gestartet, aber das Problem bleibt bestehen. Ich arbeite mit eine Singel Host: ESXi 6.5.0 Update 1 (Build 5969303)
Danke für die Hilfe
6. Mai 2019 um 11:04 Uhr - -
Hallo,
leider kann ich das Problem nicht nachstellen. Kannst Du mir Deine vmAutoStart.xml bitte mal zukommen lassen?
29. Oktober 2014 um 14:29 Uhr - -
Nach der Anpassung der vmAutoStart.xml funktioniert das Script genau so wie es soll!
Vielen Dank nochmals, somit erspare ich mir jetzt die vMA. 😀 😀
29. April 2015 um 08:44 Uhr - -
Hallo Dennis,
nach meinen ersten ‚Gehversuchen‘, habe ich das Script bis Zeile 50 zum Lafen bekommen, aber da passiert etwas, dass ich auch beim Lesen des Codes nicht verstehe. Mir wird gemeldet, dass Get-VM ein Argument für Datastore bekommt, dass leer oder NULL ist. Danach purzeln weitere Fehler, die vermutlich aber folgefehler sind rein. Ich kenne mich leider mit PowerCLI zu wenig aus, um hier den Debugger anzuwerfen. Die Ausgabe bis Fehlermeldung ist exakt folgende:
———-
2015-04-29 08:19:49 *** StartShutdownScript ***
2015-04-29 08:19:49 ConnectVIServer
Name Port User
—- —- —-
192.168.110.52 443 root
2015-04-29 08:19:50 CollectEnvData
Get-VM : Das Argument für den Parameter „Datastore“ kann nicht überprüft werden. Das Argument ist NULL oder leer. Geben Sie ein Argument an, das nicht NULL oder leer ist, und führen Sie dann den Befehl erneut aus.
Bei P:CLIPowerCLI-Shutdown.ps1:50 Zeichen:32
+ $VMsOnline = $ESXHosts | Get-VM <<<< | Where {$_.PowerState -eq "poweredOn"}
+ CategoryInfo : InvalidData: (:) [Get-VM], ParameterBindingValidationException
+ FullyQualifiedErrorId : ParameterArgumentValidationError,VMware.VimAutomation.ViCore.Cmdlets.Commands.GetVM
———-
Hast DU dazu eine Idee?
Lieben Dank und beste Grüße! 🙂
29. April 2015 um 20:27 Uhr - -
Hallo Björn,
den Fehler habe ich bisher noch nicht gehabt und auch meine (zugegebenermaßen nur kurze) Suche hat nichts wirklich Hilfreiches zutage gefördert.
Wenn Du magst, kannst Du mir aber über das Kontaktformular noch eine nähere Beschreibung zum Aufbau Deiner Umgebung und der verwendeten Software (Version vCenter, ESXi, PowerCLI, …) schicken.
Sende Dir später auch noch eine Mail, wie Du das Problem evtl. noch ein wenig eingrenzen kannst.
MfG
1. August 2016 um 15:11 Uhr - -
Hallo,
gibt es auch eine Lösung für ESXi Hosts im HA-Cluster ? Wenn HA aktiviert wird ist die Shutdown Order die man im ESXi Host einträgt unwirksam bzw. wird automat. deaktiviert.