LSIProvider verhindert ESXi Upgrade

In einem früheren Beitrag berichtete ich von Problemen beim ESXi Upgrade von Version 5.0 auf 5.1. Inzwischen wurde klar, daß es sich nicht nur um ein Problem in Zusammenhang mit angepassten Fujitsu Images handelt, sondern um angepasste Images allgemein.

Angepasste images

VMware liefert mit den ESXi ein limitiertes Angebot an Hardware Monitoring Tools, sogenannte CIM Provider. Viele Serverhersteller bieten erweiterte Monitoring-Funktionen, indem sie die nötigen CIM Provider in angepasste Images packen, und diese von VMware zertifizieren lassen. Der Vorteil ist ein besseres Hardware Monitoring im vSphere Client.

Problem mit LSIProvider

Vor einiger Zeit änderte LSI den Namen seines CIM Providers, was dazu führt, daß der Upgradevorgang (5.0 -> 5.1) des ESXi Servers mit dem Update Manager scheitert. Der Server bootet mit ESXi 5.1 und bringt am Ende eine Fehlermeldung, daß er den LSIprovider nicht aktualisieren konnte. Danach macht er ein Failback auf Version 5.0, aber die Installation verhält sich erfahrungsgemäß seltsam. So funktionierten einige esxcli Kommandos nicht mehr und manuelles Entfernen des VIB war nicht mehr möglich. Keine Installation, der man gerne vertrauen möchte. Ich wählte in diesem Fall die Neuinstallation. „LSIProvider verhindert ESXi Upgrade“ weiterlesen

ESXi Config export error

Hin und wieder ist es notwendig, die Konfiguration eines ESXi Hosts zu exportieren. Zum Beispiel dann, wenn das Flashmedium getauscht werden muss. Das ist eine Standardprozedur, die in der Regel keine Probleme bereitet. Beim Versuch, die Konfiguration eines ESXi 5.0.0 Hosts zu sichern, der ein von IBM angepasstes Image hatte, scheiterte der Export und ich erhielt die Fehlermeldung:

Restore failed: A general system error occured: Internal error

Zunächst ist verwunderlich, daß hier „Restore faild“ steht, denn ich wollte die Konfiguration sichern. Der Rest der Fehlermeldung ist so vielsagend wie die „Allgemeine Schutzverletzung im Modul XYZ“, die wir als der PC Steinzeit noch kennen. 😉 „ESXi Config export error“ weiterlesen

vSphere5.1: IODM mit esxcli

I/O Device Management (IODM)

Mit vSphere 5.1 kamen neue Funktionen zum Monitoring von Storage Adaptern zur esxcli hinzu. Der Namespace storage san hilft bei der Überwachung von iSCSI, FC, FCoE und SAS Protokollen. Der namespace

Verbindung zum Server

Zunächst muss dem Befehl eine Verbindungsinformation übergeben werden. Nach absenden des Befehls fragt der ESXi nach Nutzer und Kennwort. Diese können wahlweise auch direkt übergeben werden.

  • –username=<myuser>  | -u=<myuser>
  • –password=<mypassword> | -p=<mypassword>
esxcli --server <ESXi Hostname> storage san <protocol> <cmd> <options>

Mit Übergabe der Zugangsdaten:

esxcli --server myESX.domain.com --user=root --password=mypassword storage san FC list
  • protocol: [FC | iSCSI | FCoE | SAS]
  • cmd: list, stats get, events get, reset
  • options: [–adapter | -A] vmhba<nummer>

Zeige Adapter

esxcli --server myESX.domain.com storage san FC list

esxcli_san01Selektive Auswahl nur eines speziellen Adapters:

esxcli --server myESX.domain.com storage san FC list --adapter vmhba4

esxcli_san02

Zeige Adapter Statistiken

esxcli --server myESX.domain.com storage san FC stats get

esxcli_san03Auch hier lässt sich die Auswahl mit der (–adapter) Option wieder auf einen speziellen vmhba begrenzen.

 

Links

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.