vSphere Cluster komplett herunterfahren

Nachdem ich jetzt das zweite Mal bei einer Komplettabschaltung vom Rechenzentrum aufgrund von Arbeiten an der Stromversorgung beteiligt war schreibe ich mal ein paar Notizen dafür herunter.

Maßnahmen bevor es losgeht

DRS auf manuell stellen. Wir wollen nicht dass das vCenter anfängt VMs zu migrieren wenn das große herunterfahren aller VMs losgeht.
Ganz abschalten ist nicht zu empfehlen, dabei werden die Resource-Pools gelöscht und die VMs müssen hinterher wieder zugewiesen werden. Auf manuell stellen reicht.

vsphere_drs_manual

Läuft das vCenter als VM innerhalb des betroffenen Clusters, dann empfiehlt es sich das vCenter (und benötigte VMs, z.B. einen SQL-Server) direkt in den Autostart des ESXi zu packen, auf dem die VMs laufen.

esxi_vm_startup

Dafür sorgen dass auf dem vCenter (und SQL-Server) alle anstehenden Windows-Updates installiert sind. Es ist ärgerlich wenn das vCenter nicht richtig startet, weil sich durch die Installation von Updates der Start vom SQL-Server verzögert.

Für die Aktion bevorzuge ich zur Kontrolle den installierten vSphere Client. Auch wenn mit dem Web Client mittlerweile mehr geht, er bringt mir überhaupt nichts wenn das vCenter zwischendurch ausgeschaltet ist.

Herunterfahren des Clusters

Powershell ist hier unheimlich praktisch, es spart eine Menge Klickorgien. Allerdings rate ich davon ab dafür ein Script zu erstellen (es sei denn man macht sowas öfters), kleine Fehler rächen sich hier schnell und man hat dann doch wieder viel Handarbeit. Also hier eine kleine Auflistung von Powershell-Befehlen, die man am besten per Hand ausführt.

Hiermit kann man sich die VMware-Befehle in die normale Powershell holen:

Add-PSSnapin VMware.VimAutomation.Core -ea SilentlyContinue

Als nächstes speichert man sich die Zugangsdaten mit denen man sich zum Server verbindet in eine Variable:

$cred = Get-Credential

Dann zu den Servern verbinden. Wenn man das vcenter außerhalb des betroffenen Clusters laufen hat kann man sich ruhig dorthin verbinden:

Connect-VIServer vcenter -Credential $cred

Läuft das vCenter selbst als Virtuelle Maschine auf dem Cluster, dann empfehle ich direkte Verbindungen zu den ESXi-Servern, sonst ist es vorbei mit dem Scripten sobald das vcenter heruntergefahren wurde.

$esx = "esx1","esx2","esx3","esx4","esx5","esx6"
foreach ($server in $esx) { Connect-VIServer $server -Credential $cred }

Dann abschalten dass Scripte bei einem Fehler direkt gestoppt werden. Es gibt immer irgend eine VM die ein Problem hat und sich deshalb nicht herunter fahren lässt.

$ErrorActionPreference = "silentlycontinue"

Bisher habe ich dann für alle VMs einfach einen Autostart konfiguriert. Das geht recht komfortabel mit einem Powershell-Befehl, hat aber einen Haken: Es funktionierte bei mir beide Male nicht. Nachdem die ESXi-Hosts wieder eingeschaltet waren, waren alle vorher eingerichteten Autostarts wieder weg. Bisher konnte ich keinen Grund dafür finden. Daher mache ich es in Zukunft anders:

$runningVMs = Get-VM | where {$_.PowerState -eq "PoweredOn"}

Die VMs kann man auch noch einschränken, z.B. nach Resource-Pool oder Ordner

Get-VM -Location (Get-ResourcePool Pool1)
Get-VM -Location (Get-Folder Folder2)

Danach hat man alle VMs, die aktuell eingeschaltet sind, in einer Variable. Einzelne VMs, die man nicht in der Liste haben will, kann man bei Bedarf relativ einfach herausfiltern:

$runningVMs = $runningVMs | where { $_.Name -ne "vcenter" }

Die Liste exportieren wir dann in eine CSV-Datei:

$runningVMs | Export-Csv -Path "VMs-ClusterA.csv"

Nun können wir die VMs alle herunterfahren:

Shutdown-VMGuest -VM $runningVMs -Confirm:$false

Als letztes: Hosts herunterfahren:

Stop-VMHost -VMHost (Get-VMHost) -Confirm:$false

Wieder starten

Wenn das vCenter und die ESXi-Hosts wieder laufen kann das Starten der VMs los gehen. Als Erstes DRS wieder aktivieren, sonst müssen wir bei jeder eingeschalteten VM den Host auswählen auf dem sie starten soll.

Da das vCenter wieder läuft können wir diesmal direkt dorthin verbinden.

Connect-VIServer vcenter -Credential $cred

Als nächstes lesen wir die Liste mit den VMs wieder ein:

$runningVMs = Import-Csv -Path "VMs-ClusterA.csv"

Dann schalten wir die VMs wieder ein:

$runningVMs | Start-VM

Oder, um das Storage nicht durch gleichzeitiges Einschalten aller VMs zu sehr zu belasten:

foreach ($vm in $runningVMs) { Start-VM $vm.Name; Sleep 5 }

So starten immer nur ca 12 VMs gleichzeitig, das hat sich als recht guter Kompromiss erwiesen.

Diesmal wurde bei mir bei ca 30% der VMs das Einschalten durch die Frage verhindert, ob die VM Kopiert oder Verschoben wurde. Meines Wissens ist die einzige Auswirkung dieser Frage ob eine neue MAC-Adresse für die VM generiert wird oder nicht. Da mit den VMs weder das eine noch das andere geschehen ist, habe ich die Frage mit “Verschoben” beantwortet, damit sie ihre MAC-Adressen behalten. Auch das lässt sich bequem mit einem Powershell-Befehl für alle VMs beantworten:

Get-VM | Get-VMQuestion | Set-VMQuestion -Option "I moved it" -Confirm:$false

Danach sollten alle VMs wieder normal starten.

Veröffentlicht von

Gerald Schneider

Diplom-Informatiker (DH) in Rostock. Ich blogge über Entwicklung, Internet, mobile Geräte und Virtualisierung.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert