ESX – HBA und NIC Firmware Status ermitteln

Zur Gewährleistung von Kompatibilität und bei Supportanfragen ist es gelegentlich notwendig, den aktuellen Firmware Status von Netzwerkadapter oder HBA zu ermitteln. Natürlich kann man theoretisch den Server neu booten und dabei in die BIOS Einstellungen des Adapters gehen, aber dies ist gerade bei ESX Servern mit viel Aufwand verbunden. VM müssen auf andere Hosts im Cluster migriert werden, ein Konsolenzugang oder eine Remotekonsole wird benötigt. Dies alles kostet viel Zeit.

Viel schneller geht es mit ein paar Kommandos auf der ESXi Shell, ohne den Host zu beeinträchtigen. Dazu benötigt man nur einen Zugang per SSH. „ESX – HBA und NIC Firmware Status ermitteln“ weiterlesen

Netzwerk am CITRIX NetScaler VPX instabil durch VMWARE Patch für ESX 5.1 und 5.5

NetScaler VPX ist die virtuelle VPN, Firewall und Applikationsfilterlösung von Citrix. Wir verwenden diese in etlichen Projekten insbesondere für den Zugang auf XenDesktop, die VDI Lösung von CITRIX, aus dem Internet. Sie steht als Appliance für die gängigen Hypervisoren zur Verfügung und basiert auf einem gehärteten FreeBSD.

Die virtuelle Appliance steht mit begrenztem Leistungsumfang und nach Registrierung bei Citrix frei für jeweils ein Jahr zur Verfügung und reicht bequem für mindestens fünf gleichzeitige externe Zugriffe auf die XenDesktop Umgebung.


Kürzlich gab es in einer Implementierung, die schon >1 Jahr fehlerfrei funktionierte, folgendes Verhalten: Der Zugriff auf XenDesktop von extern funktionierte zunächst, war dann aber plötzlich weg. Meistens nach stärkerer Grafik- und damit Netzlast im ICA Protokoll. Die VM war in Folge der Störung auch nicht mehr im Netzwerk pingbar.

Nach einem Reboot der NetScaler VM war zunächst wieder alles in Ordnung – erneute Last führt aber reproduzierbar wieder zum Absturz.

Nähere Analyse ergab, dass auch der Zugriff auf die Management WebGUI bereits den Abbruch der Netzverbindung auslösen konnte.

Um die VM eingehend zu untersuchen wurde sie exportiert und in einen ESX Testcluster portiert.

Erstaunlicherweise war im Testcluster alles ok. Die VM war auch bei Netzlast stets funktional und erreichbar.

Wieder zurück im Produktivcluster gleiches Verhalten wie vorher.

In der WebGUI war, wenn das Netz einmal so lange durchhielt, eine Fehlermeldung im SysLog zu sehen:

stall

Offenbar kommt für gesendete Pakete keine rechtzeitige Rückmeldung (ACK) und NetScaler startet daher das Interface neu. Infolgedessen gehen alle Verbindungen über dieses Interface verloren.

Die Suche nach dem Problem im Netz ergab zunächst keine Hinweise.

Schließlich fanden wir den zielführenden Hinweis in der KB bei VMWARE und auch CITRIX. Laut VMWARE liegt das Problem bei CITRIX.

Sobald man den Hypervisor unter ESX 5.5 auf Update 2 (build 2143827) oder ESX 5.1 auf EP 5 (build 1900470) gehoben hat.

Citrix umschreibt das Problem so:

NetScaler VPX network connectivity issue on VMware ESXi 5.1.0 2191751 and VMware ESXi 5.5 Build 2143827 is caused by tx_ring_length mismatch, which causes TX stalls.

Das Problem wurde am 05.11.2014 von CITRIX veröffentlicht. Es gibt noch keinen Patch für die NetScaler Appliance. Dieser ist aber angekündigt.

Im Testcluster war das VMWARE Update noch nicht installiert – daher lief hier noch alles stabil wie vorher.


Bis zum erscheinen eines Patches für die NetScaler VPX wird ein Workaround vorgeschlagen, der bei uns nachhaltigen Erfolg brachte:

Hierzu muss unter dem FreeBSD des NetScaler eine Datei /flash/boot/loader.conf.local erzeugt werden.

In diese muss der Parameter hw.em.txd=512 eingefügt werden.

Wie geht das am schlankesten?

  • Anmelden in der NetScaler VM Konsole als nsroot
  • Wechseln auf die Shell mit shell
  • Eingabe von echo hw.em.txd=512 > /flash/boot/loader.conf.local
  • Hierdurch wird hw.em.txd=512 in diese Datei geschrieben, die üblicherweise noch nicht vorhanden ist.
  • Prüfen ob der Eintrag vorhanden ist kann man mit less /flash/boot/loader.conf.local
  • Danach noch reboot eingeben um die Appliance neu zu starten.
  • Problem gelöst. Das NetScaler Netzwerk ist auch unter Last wieder stabil.

hw.em.txd


Links:

NetScaler VPX Loses Network Connectivity on VMware ESXi 5.1.0 2191751 and VMware ESXi 5.5 Build 2143827

After applying patches to an ESXi 5.1/5.5 host, Citrix NetScaler virtual machine with e1000 vNIC loses network connectivity (2092809)

Zombie VM killen

Eine Methode zum Abschuss einer Zombie-VM (eine VM die sich mit Mitteln des vSphere Clients nicht abschalten lässt).

Auf der ESX Konsole:

Zuerst der Versuch auf die nette Tour:

vmware-cmd /vmfs/volumes/<Volume>/<VMOrdner>/<VMName>.vmx stop

Die Chancen, daß das nicht zum Ziel führt sind erhöht. Schließlich funktionierte es über die GUI schon nicht. Also nochmal, jetzt aber mit etwas Nachdruck:

vmware-cmd /vmfs/volumes/<Volume>/<VMOrdner>/<VMName>.vmx stop hard

Wenn das auch nicht hilft, dann muss die Kettensäge ran. Wir haben es mit einem harten Zombie zu tun. 😉 Zunächst brauchen wir die PID der VM. Die bekommen wir mit:

ps auxfww | grep <vmname>

Die gesuchte PID (process ID) befindet sich rechts neben “root”.

kill -9 <PID>

vSphereCLI

Diese Methode ist auch bei ESXi einsetzbar.

esxcli --server <Host> --username root --password "<pass>" vms vm list

Die World ID der VM notieren

esxcli --server <Host> vms vm kill --world-id <ID> --type <soft|hard|force>

Die Modi soft, hard und force sind verschiedene Härtegrade der Abschaltung.

soft: löst einen normalen Shutdown der VM aus. Enstpricht dem “kill <PID>” auf der ESX Konsole.

hard: die etwas härte Methode. Schaltet die VM hart aus. Entspricht dem “kill -9 <PID>” im obigen Beispiel auf der Konsole.

force: wenn nichts mehr hilft. Abschuss ohne Rüchsicht auf Verluste. Sollte nur angewandt werden, wenn es mit soft oder hard nicht funktionierte.

powerCLI

PowerCLI erinnert in vielen Punkten an eine bash und ist daher auch sehr gut zur Progrmmierung geeignet. Für einige Aufgaben gibt es keinen direkten Befehl, aber diese können z.B. durch Aufruf der esxcli Kommandos ausgeführt werden.

Für die Einbindung des ESXCli Cmdlets benötigen wir PowerCLI 4.1.1

Die PowerCLI Kommandos fand ich im Blogbeitrag von Boerlowie. Herzlichen Dank.

Connect-VIServer -Server <Host> -Credential $(Get-Credential -Credential root)
$esxcli = Get-EsxCli -Server <Host>
$esxcli.vms.vm.list() | Format-Table -Property DisplayName, WorldID

Die WorldID der Zombie-VM notieren für das folgende Kommando. Auch hier gibt es wieder die drei Modi soft, hard und force (vgl. oben).

$esxcli.vms.vm.kill("soft", <WorldID>)