vSphere5: Zombie VM mit PowerCLI abschiessen

Gelegentlich kommt es vor: Eine VM läßt sich werder beenden, hart abschalten, noch neu starten. Ein sogenannter Zombie.

Unter vSphere5 funktionieren PowerCLI und ESXCLI etwas anders als unter vSphere 4.x.

Methode1: (Soft)

> $VM = Get-VM.<VM-Name>
> $esxcli = Get-EsxCli -vmhost ($VM.Host)
> $WorldID = ($esxcli.vm.process.list() | Where { $_.DisplayName -eq $VM.Name}).WorldID
> $result = $esxcli.vm.process.kill("soft", $WorldID)
> $result

Methode2: (Hard)

…und bist Du nicht willig….. 🙂

> $VM = Get-VM.<VM-Name>
> $esxcli = Get-EsxCli -vmhost ($VM.Host)
> $WorldID = ($esxcli.vm.process.list() | Where { $_.DisplayName -eq $VM.Name}).WorldID
> $result = $esxcli.vm.process.kill("hard", $WorldID)
> $result

Auch Wildcards lassen sich hier einsetzen (Achtung!):

> $VM = Get-VM.<VM-Namepart>*

Schiesst alle VMs ab, die mit dem Teilamen beginnen. Weitere Informationen zum Thema finden sich im Originalpost bei Virtu-Al. Dort befindet sich auch eine PS Funktion, die obige Befehle vereinfacht. Die Syntax ist dann reduziert auf:

Get-VM <VM-Name> | Kill-VM

Eine alternative Methode bedient sich der esxcli cmdlets

Dies ist eine moderne Abwandlung (vSphere 5) einer Methode, die ich in einem älteren Artikel unter vSphere 4.x beschrieben hatte.

connect-viserver esx1.mydomain.com

Alle aktiven VM Prozesse auflisten.

$esxcli = get-esxcli
$esxcli.vm.process.list()

Hier muss man die WorldID der Zombie-VM notieren.

Klar zum Abschuss!

$esxcli.vm.process.kill("hard", <WorldID>)

Hier ist <WorldID> durch 3867 zu ersetzen.

vSphere5: Probleme mit Veeam 5.0.2

Wir erlebten kürzlich in einer brandneuen vSphere 5.0.0 Umgebung eine Überraschung mit Veeam (5.0.2). Zunächst lief alles rund und auch die Sicherungsjobs konnten erfolgreich abgeschlossen werden. Als ordentliche Dienstleister testet man natürlich die Wiederherstellung aus dem Backup. Zunächst den File-Level Restore. Dieser funktionierte ohne Probleme. Danach testeten wir ein Full VM Restore. Beim Versuch bekamen wir jedoch folgende Meldung:

Das Filesystem auf dem Datastore ist VMFS5 (nativ, 1MB Blocksize), vCenter ist die VMware Appliance (5.0.0). Das ausführende Konto hat volle Rechte auf den Datastore. Eine Suche im Veeam-Forum brachte etwas Licht ins Dunkel (Link).

Wie man dennoch wiederherstellen kann:

„vSphere5: Probleme mit Veeam 5.0.2“ weiterlesen

vSphere5: Upgrade auf VMFS5

Mit vSphere 5.0.0 kommt neben vielen anderen Neuheiten auch ein erneuertes Dateisystem VMFS5 hinzu.Die Unterschiede zwischen dem bisherigen VMFS3 und dem neuen VMFS5 erklärt Jason Boche in seinem Blog.

Die Migration ist sehr einfach und erfolgt im laufenden Betrieb. Die Blockgröße wird bei bei diesem Prozess nicht angetastet und somit nicht in die neue Standardblockgröße von 1MB konvertiert (!).

Angestoßen wird der Prozess im vSphere-Client unter: Home > Datenspeicher und Datenspeichercluster. Links den Datenspeicher auswählen und ins Register “Konfiguration” wechseln. Ist der Speicher noch nicht konvertiert erscheint unter Datenspeicherdetails die Upgradeoption (vgl Bild).

Ein Assistent prüft, ob alle angeschlossenen ESXi Hosts VMFS5 unterstützen (ab ESX 5.0.0).

Danach wird die neue Filesystemversion in den Datenspeicher Eigenschaften angezeigt.

Zur Beachtung: Die Blockgröße wurde nicht auf 1 MB standardisiert, sondern der ursprüngliche Wert beibehalten. Welche Auswirkungen dies haben kann erklärt ein lesenswerter Artikel von Frank Denneman.

MS Office: Problem mit Deinstallation über Systemsteuerung

Das Problem: Microsoft Office ist installiert, verhält sich aber extrem ungewönlich und stürzt ab (die Anti-M$ Trolle mögen an dieser Stelle bitte wieder in ihren Käfig gehen) ;-). Eine Reparaturinstallation oder Deinstallation über die Systemsteuerung funktioniert nicht. Was tun? System-DVD einlegen und neu installieren? Lieber nicht…

Zum Glück gibt’s da etwas von Ratio… äh Microsoft: KB290301 😉

(Vielen Dank für den Hinweis von MM)