vSphere HTML5 Web Client

Der vSphere Webclient, der mittelfristig den weit verbreiteten vSphere-Client ersetzen soll, erfreut sich unter Anwendern keiner großen Beliebtheit. Und das, obwohl die Vorteile eines „Überall-Clients“ nicht von der Hand zu weisen sind. Einer der Schwachpunkte des Webclients ist u.a. das Plugin, das er zur vollständigen Funktion benötigt und Flash. Letzteres ist der größte Kritikpunkt. Angesichts der massiven Sicherheitslücken in Adobes Flashplayer, verbietet sich dieser geradezu. Daher war der Ruf nach einem Webclient ohne Flash in der VMware Community sehr laut.

No Flash

HTML5WebClient02

Seit einiger Zeit gibt es ein Projekt bei vmware Flings für einen Flash-freien HTML5 Webclient. Das ganze ist noch im Betastadium und noch nicht alle Funktionen implementiert, aber ein guter Anfang. Aktuell beherrscht der HTML5-Webclient folgende Funktionen:

  • VM Einschaltvorgänge
  • VM Eigenschaften ändern
  • VM Konsole
  • VM und Host Übersichten
  • VM Migration
  • Clonen und in Template verwandeln
  • VM auf Host erstellen
  • Monitoring, Aufgaben, Ereignisse

Um den HTML5-Webclient nutzen zu können benötigt man eine VM, die als OVA bereitgestellt wird. Er ist konzipiert, das vCenter (v6) zu verwalten. Für Verwaltung der ESXi Hosts sollte der Hostclient verwendet werden.

System-Voraussetzungen

  • 2 vCPU, 4 GB RAM (VM)
  • vCenter v6 oder höher
  • Chrome, Firefox, IE11

Installation

Die Installation ist noch etwas Handarbeit, soll aber künftig durch eine GUI vereinfacht werden.

Links

Problem beim Upgrade auf ESXi 6 mit Customized Images

Einige Server-Hersteller bieten für die ESX Installation auf ihrer Hardware sogenannte Customized Images an, die Common Information Model (CIM) Provider und Treiber enthalten. Damit können Hardwaredaten an den host und vCenter weitergegeben werden.

Bis auf ein Problem mit dem LSIprovider vor einigen Jahren, gab es mit den Customized Images praktisch keine Probleme. Das änderte sich mit dem Upgrade auf ESXi Version 6.

Tod durch Upgrade

Erst kürzlich berichtete mir ein Kollege von einem sehr unerfreulichem Upgrade-Versuch einer ESXi 5.5 Installation (FTS Customized) mit dem Customized Image für ESXi 6.0. Es endete in einer blanken Neuinstalltion mit dem Original VMware Image ESXi 6.

Dadurch gewarnt, wagte ich kürzlich ebenfalls ein ähnliches Upgrade eines ESXi 5.5 mit Fujitsu CIM Providern und Treibern. Allerdings nicht mit einem Customized ESXi 6 Image, sondern gleich mit dem sogenanten „Vanilla“ Image von VMware. Das Ergebnis war ein ESXi 6 Host, der nach dem Reboot praktisch nicht administrierbar war. Alleine ein Login auf der DCUI dauerte Minuten und auch sonst reagierte das System nahezu überhaupt nicht mehr. Auch hier half mir nur die komplett frische Installation mit einem aktuellen VMware Image.
Problem beim Upgrade auf ESXi 6 mit Customized Images weiterlesen

PernixData und Veeam Backup

Pernix FVP für Storage und VMs leistet erhebliche Beschleunigung für Storage und VMs in klassischen vSphere Clustern. Durch Verwendung von RAM oder Flash Speicher können Latenzen drastisch reduziert und IO erheblich verbessert werden. Dabei können VMs entweder im Write-Through Modus (Lesecache), oder im Write-Back Modus (Lese- und Schreibcache) betrieben werden. Bei letzterem werden Write-IO im Cache und auf einem oder mehreren weiteren Hosts (Peers) gehalten. Die VM kann bereits fortfahren, noch ehe der Block auf den Datastore geschrieben wurde. Storage Latenzen werden somit abgefangen und die Daten zu einem späteren Zeitpunkt geschrieben.

Cave Backup!

Genau in diesem cleveren Prinzip liegt jedoch ein potenzieller Fallstrick beim Backup. Befindet sich eine VM im WriteBack Modus und Veeam Backup erzeugt darauf einen Snapshot zur Sicherung, so ist die Konsistenz des Snapshots nicht gewährleistet. D.h. es gibt unter Umständen noch ausstehende Writes auf den Datastore, die dann im Backup fehlen und dieses im schlimmsten Fall korrupt werden lassen. PernixData und Veeam Backup weiterlesen

ESXi TPS Status ermitteln

Tranparent Page Sharing (TPS) ist eine Technik zur gemeinsamen Verwendung von Speicherinhalten, indem identische Pages nur einmalig abgelegt werden.

Seit Update 2b wurde TPS von VMware per Default deaktiviert, da es in seltenen Fällen zu Sicherheitsverletzungen zwischen VMs kommen konnte. Wie es sich zeigte, ist aber bei ESXi Servern mit höherer Build Nummer unter Umständen TPS noch aktiv. Das liegt daran, daß VMware TPS offensichtlich nur bei Neuinstallation abschaltet.

TPS Status

Wie kann man nun ermitteln, welchen TPS Status die ESX Server eines Clusters haben?

Hierfür kann man mittels PowerCLI einen oneliner ausführen.

# Connect-VIServer <myVC>
# Get-VMHost –State Connected | Get-AdvancedSetting –Name Mem.ShareScanGHz | Format-Table –Property Entity,Name,Value -AutoSize
# Disconnect-VIServer

Werte >0 deuten auf ein aktiviertes TPS.

TPS deaktivieren

# Connect-VIServer <YourvCenter>
# Get-VMHost –State Connected | Get-AdvancedSetting –Name Mem.ShareScanGHz | Set-AdvancedSetting –Value 0

Status erneut testen

# Get-VMHost –State Connected | Get-AdvancedSetting –Name Mem.ShareScanGHz | Format-Table –Property Entity,Name,Value -AutoSize
# Disconnect-VIServer

Links

VMware patcht glibc Lücke in mehreren Produkten

Die glibc Bibliothek ist in Linux Systemen weit verbreitet. Mitte Februar 2016 wurde vor einer kritischen Lücke in dieser gewarnt. VMware patcht nun eine Reihe seiner Produkte, die auf Linux basieren und die betroffene glibc Library verwenden. Windows Komponenten sind hiervon logischerweise nicht betroffen.

Was ist betroffen?

Betroffen sind die Hypervisoren ESXi 5.5 und 6.0. Frühere Versionen wie 5.1 oder 5.0 enthalten keine verwundbare Version von glibc.

Virtuelle Appliances auf Linux basis sind betroffen. VMware hat hierzu  KB 2144032 veröffentlicht.

Links

golem.de – Sicherheitslücke gefährdet fast alle Linux-Systeme
VMware Scurity Advisories – VMSA-2016-0002.1

ESXi – Zuordnung vmnic zu physischem Adapter testen

who is who?

Dieses Problem kennt jeder, der ESXi Server auf neuer Hardware ausrollt: Welcher physische LAN-Adapter entspricht welchem vmnic?
Eine pragmatische, aber mühsame Prozedur besteht darin, zunächst nur einen LAN-Adapter zu verbinden und dann in der DCUI den Linkstatus aller vmnics zu kontrollieren. Das Verfahren wird so lange wiederholt, bis alle Adapter mit dem Switch verbunden sind. Dumm nur, dass sich die LAN-Adapter auf der Server Rückseite und die Konsole bestenfalls auf der Server Vorderseite, oder gar in einem anderen Raum befinden. Das heißt Teamwork und Telefon ist gefragt…. Wer schon einmal versucht hat, hinter einem Server zu telefonieren, wird bestätigen dass dies kein gutes Verfahren ist.
Bei laufenden Systemen kann es aber auch sein, dass ein Entfernen der Patchkabel nicht möglich ist. Was also tun?

Ethtool

Hier kommt ein praktisches Bordmittel des ESXi zum Einsatz. Mit dem ethtool kann man physische NICs zum blinken bringen.

ethtool -p <device> <t in sec>

Um beispielsweise vmnic1 für 30 Sekunden blinken zu lassen, gibt man folgenden Befehl ein:

ethtool -p vmnic1 30

Eine Liste der im System vorhandenen vmnics und der korrespondierenden Hardware erhält man mit den Befehl

esxcfg-nics -l

Dies ist nur eine von vielen Möglichkeiten, die uns das ethtool an die Hand gibt. So kann man beispielsweise auch die Firmware eines physischen NICs abfragen.

vSphere 6 Update Sequenz für VMware Produkte

Beim Upgrade einer vSphere Infrastruktur ist die Reihenfolge der Produktaktualisierung zu beachten. VMware hat unter KB 2109760 die empfohlene Sequenz der Produktupdates beschrieben.

Ablaufplan für VMware Produkte

  1. vCloud Connector (vCC)
  2. vCloud Director (vCD)
  3. vCloud Networking and Security (VCNS, formerly vShield Manager)
  4. VMware Horizon View
  5. VMware NSX for vSphere (NSX Manager)
  6. vCenter Operations Manager (vCOPs)
  7. vCenter Server / vCenter Server Appliance
  8. vCenter Infrastructure Navigator (VIN)
  9. vCenter Site Recovery Manager (SRM)
  10. vCenter Update Manager (VUM)
  11. vRealize Automation Center (vRA, formerly known as vCloud Automation Center)
  12. vRealize Automation Application Services (vRAS, formerly vSphere AppDirector)
  13. vRealize Business, IT Cost Management (ITBM, formerly VMware IT Business Management)
  14. vRealize Configuration Manager (VCM, formerly vCenter Configuration Manager)
  15. vRealize Hyperic
  16. vRealize Log Insight (vRLI)
  17. vRealize Operations Manager (vROPs, formerly known as vCenter Operations Manager, vCOPs)
  18. vRealize Orchestrator (vRO, formerly vCenter Orchestrator)
  19. vSphere Big Data Extension (BDE)
  20. vSphere Data Protection (VDP)
  21. vSphere Replication (VR)
  22. vSphere ESXi
  23. vShield Edge / NSX Edge
  24. vShield App / NSX Logical Firewall (NSX LFw)
  25. vShield Endpoint / NSX Guest Introspection and Data Security (NSX Guest IDS)

Produkte von Fremdherstellern sind hier nicht berücksichtigt und müssen beim jeweiligen Software Herstellers erfragt werden.

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

VM Template in Clustern mit heterogenen CPU Generationen

Probleme bei der Ableitung vom Template

Ich konnte in der Vergangenheit immer wieder beobachten, dass die Ableitung vom Template gelegentlich scheiterte und die neue VM in einem endlosen Sysprep fest hing. Eine erneute Ableitung führte oftmals zum Erfolg, aber die Hintergründe waren mir bislang unklar. Nur durch Zufall bin ich heute auf die Ursache des gestoßen. Die VM war für automatische Anmeldung als Administrator konfiguriert und ich konnte sehen was unmittelbar vor dem Sysprep Versuch passierte. Es wurde ein Treiber für die CPU installiert und der Anwender zu einem Neustart aufgefordert.

sysprepCPU03Dies ist erstaunlich, da das Template der VM zuvor intensiv mit Updates versorgt und mehrfach neu gestartet wurde. Warum also wird nach dem Ableiten ein neuer CPU Treiber installiert?

Dazu muss man verstehen, dass sich der der beschriebene Cluster aus zwei unterschiedlichen Typen von Intel Servern zusammensetzt.

  • Xeon E5-2640 – Dual Socket Hexa-Core
  • Xeon E5-2690 v3 – Dual Socket Dodeca-Core

Durch EVC wurde die vMotion Komaptibilität zwischen den Hosts sichergestellt, dennoch muss das Template jeden Host Typ einmal „sehen“, um den passenden CPU Treiber zu installieren. Passiert dies erstmalig nach dem ableiten, so ist der Sysprep Vorgang gestört und scheitert.

Prevention

Es zeigt sich, daß es eine gute Praxis ist, ein Template auf jedem Host Typ im Cluster mindestens einmal zu booten. Sind erst alle Treiber installiert gibt es auch keine Probleme mehr bei der Ableitung.

 

Fehler bei Snapshot Konsolidierung unter ESXi 5.5 Update3

Ein schwerer Bug hat sich in Update 3 von ESXi 5.5 eingeschlichen. Versucht man auf Hosts mit diesem Build, einen Snapshot zu konsolidieren, so läuft die VM in einen Fehler.

Unexpected signal: 11

Der Fehler führt zum Absturz der VM. Ein Patch ist zum heutigen Zeitpunkt (2. Okt. 2015) noch nicht verfügbar. VMware beschreibt in KB2133118 wie man das Problem umgehen kann. Dies beinhaltet jedoch den Downgrade (!) eines Hosts für die Snapshot-Konsolidierung. Bis zur Behebung des Problems, kann also nur vor Updates auf 5.5U3 abgeraten werden.