Upgrade vCenter Server Appliance 6.0

Wer eine bestehende vSphere 5.x Umgebung mit vCenter Server Appliance (VCSA) betreibt, möchte diese sicherlich bald auf Version 6 upgraden. Ein Inplace Upgrade ist aufgrund der internen Umstrukturierung von Diensten nicht möglich. Wohl aber ein Migrations-Upgrade. Diesen Vorgang werde ich hier aufzeigen. Upgrade vCenter Server Appliance 6.0 weiterlesen

APC PCNS Virtual Appliance

Virtuelle Infrastruktur erfordert redundante, unterbrechungsfreie Stromversorgung (USV). Die zusätzlich Abstraktionsschicht ist eine Herausforderung für Systeme zur automatischen Abschaltung der Anlage im Fall eines verlängerten Stromausfalls. Bisher erledigte dies für APC USVs die Software PowerChute Network Shutdown 3.x (PCNS). Das Paket konnte auf der vMA von vmware installiert werden. Den Vorgang habe ich im Artikel APC Network Shutdown mit vMA und ESXi beschrieben.

APC hat kürzlich das PCNS Paket auf Version 4 aktualisiert und deutlich verbessert. Neben der üblichen Installationsmethode in der vMA gibt es nun eine fertig konfigurierte PCNS Appliance, was die Bereitstellung erheblich vereinfacht.

APC PCNS Virtual Appliance weiterlesen

VMware EOL Matrix

Wo sind die Updates?

Der Blick in den Update Manager eines älteren vSphere 4.1 Clusters sorgte bei mir für etwas Verwunderung. Nach Prüfung der Hosts gegen die Update Baseline, stand dort: “Übereinstimmung”. Wie ist das möglich?

Das System war gewissermaßen auf dem neuesten Stand, da VMware dafür im Mai 2014 den Support eingestellt hatte. Für vSphere 4.x und andere Produkte kann man das in der VMware Lifcycle Product Matrix nachlesen.

Der generelle Supportzeitraum beträgt in der Regel 5 Jahre. ESXi 4.x erschien im Mai 2009 (tempus fugit) und damit gab es ab Mai 2014 keine neuen Patches mehr.

Lifecycle Support Phases

Der Lifecycle Support bei VMware gliedert sich in drei Bereiche:

  1. General Support Phase. Sie beginnt mit der allgemeinen Verfügbarkeit (GA) des Produktes. Innerhalb dieser Zeit erhält man Updates, Upgrades, Bugfixes, Treiber für neue Hardware, GuestOS Updates, Telefon- und Websupport.
  2. Technical Guidance Phase. Diese beginnt im Anschluss an die General Support Phase. Innerhalb dieses Zeitraumes erhält man keine neuen Updates oder Bugfixes, jedoch Zugang zu bestehenden Updates und Fixes. Der Telefonsupport ist eingestellt.
  3. End of Support Life Phase (EOSL). Es gibt nur noch Zugang zur Knowledgebase.

vSphere 6 – Bootimage erstellen

Ein halbes Jahr musste dieser Artikel auf die Veröffentlichung warten. Das Beta Programm NDA mit vmware erlaubte, jedoch nicht die Publikation.

Seit 30.6.2014 ist die vSphere 6 Beta verfügbar. Ich habe in der Zeit seither unteschiedliche Aspekte des neuen Produkts ausprobiert und werde die Erfahrungen hier veröffentlichen.

Eine wichtige Frage für die Praxis ist beispielsweise: “Wie bekomme ich das Image auf ein fertiges Bootmedium, das ich vor Ort nur noch einstecken und starten muss?”. In der Version 5.x half hier eine kleine VM, die als Image-maker fungierte.

Image Maker

Mit Version ESXi 5.0.0 hatte sich die Methode zur Erstellung von USB Bootimages verändert. Ich habe in einem älteren Artikel beschrieben, wie man diese vorab auf USB Medien erstellen kann, um damit Server auszurüsten. Die gute Nachricht vorab: Die Methode funktioniert auch weiterhin. Die Hilfs-VM zum Setup von ESXi 5.x kann auch für ESXi 6 beta verwendet werden.

ESXi6BootImage01

vSphere 6 – Bootimage erstellen weiterlesen

ESXi 5.5 VAAI unmap

Thin-Provisioning – also die schrittweise Zuteilung von Speicherressourcen – gibt es nicht nur in Form von VMDK Diskfiles, sondern auch auf Storage-Ebene. Hier werden Volumes nicht 1:1 als LUN an den Host übergeben, sondern das (reale) Speichervolume ist von der (virtuellen) LUN entkoppelt. Man kann so Datenspeicher effizienter ausnutzen und dynamisch zuteilen. Da der ESX Host nun keinen physischen Zugriff auf das Speichervolume mehr hat, sondern nur auf die virtuelle LUN, muss es eine Möglichkeit geben, mit welcher der Host der Storage Rückmeldung über gelöschte oder verschobene Speicherbereiche geben kann. Um diese Funktion wurde die “vStorage APIs for Array Integration” (VAAI) unter vSphere 5.0 erweitert. Die VAAI Funktionen heissen “primitives” und jene, die für die Rückgabe von Speicher verantwortlich ist nennt sich UNMAP.

Leider gab es damit einige Probleme in Verbindung mit Storage Geräten, weswegen diese Funktion von VMware schnell wieder zurückgezogen wurde. Bis zum Stand 5.5 wurde sie nicht wieder aktiviert. Man kann sie aber dennoch nutzen – wenn auch nicht komfortabel.

ESXi 5.5 VAAI unmap weiterlesen

Unmount Datastore nicht möglich

Das Entfernen eines Datenspeiches vom ESX Cluster muss einer genauen Prozedur folgen, andernfalls drohen sehr unangenehme Effekte infolge PDL oder APD.

Unmount des Datastores nicht möglich

Obwohl ich die Abfolge der Schritte genau eingehalten hatte, ließ sich ein Datastore nicht entfernen und brachte die Meldung:

The resource ‘Datastore Name: VMFS uuid: [uuid]’ is in use. Cannot remove datastore ‘Datastore Name: VMFS uuid: [uuid]’ because file system is busy. Correct the problem and retry the operation.

Hierfür gibt es typischerweise zwei mögliche Fehlerquellen:

  • vsantrace Files
  • Coredump Files

Unmount Datastore nicht möglich weiterlesen

VM Hardware Version Downgrade

Es gibt Situationen, in denen man die VM Hardware Version herabsetzen muss. Dies kann beispielsweise notwendig sein wenn:

  • ..die VM von einem ESXi 5.5 Host auf einen ESXi 5.1 oder niedriger migriert werden soll.
  • ..der WebClient nicht verfügbar ist und die VM mit dem vSphereClient verändert werden soll (bisher nicht möglich bei HW Version >= 10).

VM Hardware Version Downgrade 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)

ESXi: kritischer Fehler in CBT kann Backups unbrauchbar machen

Changed-Block-Tracking (CBT) ist eine sehr nützliche Funktion, um beispielsweise einer Backup Software mitzuteilen, welche Blöcke sich seit einen Zeitpunkt [t] verändert haben. Somit können gezielt diese Blöcke gesichert werden, was natürlich erheblich Zeit spart.
Genau in dieser CBT Funktion gibt es einen Fehler, der lange unerkannt blieb. Er tritt nach Angaben von VMware dann auf, wenn eine vDisk über 128 GB vergrößert wurde.
VMware und Veeam empfehlen, nach einer Vergrößerung der vDisk einer VM, einen CBT reset durchzuführen. Beim nächsten Durchgang von Veeam Backup wird CBT wieder aktiviert und arbeitet korrekt.

Alternativ kann auch ein PowerCLI Skript verwendet werden, das CBT im laufenden Betrieb zurücksetzt. Das Skript resetCBT wurde vom Veeam Support erstellt. Der Aufruf erfolgt mit Parametern. Es funktioniert nur bei eingeschalteten VMs.

Verwendung auf eigen Gefahr !

-vcenter: <FQDN vCenter>

-vms: Liste der VMs durch Komma getrennt (keine Leerzeichen!)

resetCBT.ps1 -vcenter example.vcenter.local -vms "vmname1,vmname2,vmname3,vmname4"

ResetCBT01

Update:

Möglicherweise löst VMware das Problem in ESXi5.5 mit aktuelltem Patchlevel (2143827) automatisch (?). Nach der Vergrößerung einer vDisk meldete Veeam Backup (v7) folgende Warnung:

ESXiCBT01Wurde von Seite des ESXi Servers das CBT automatisch deaktiviert?

Update 17. Nov 2014

Veeam hat einen Hotfix für B&R Version 7 veröffentlicht. Er besteht aus 4 DLL Dateien, die getauscht werden müssen. Voraussetzung ist Veeam Backup and Replication 7.0.0.871 (patch 4).

  • Sicherstellen dass Version 7.0.0.871 installiert ist
  • Veeam Dienste stoppen
  • DLLs im Verzeichnis “C:\Program Files\Veeam\Backup and Replication\Backup” mit den Hotfix DLLs ersetzen.
  • Veeam Dienste wieder starten

Links

  • Veeam KB – CBT Data Corruption
  • VMware KB – QueryChangedDiskAreas API returns incorrect sectors after extending virtual machine vmdk file with Changed Block Tracking (CBT) enabled (2090639)
  • Veeam KB – How to reset CBT

 

ESXi: TPS in Zukunft deaktiviert

VMware wird in Zukunft die Transparent Page Sharing Funktion im Standard deaktiviert lassen. Grund hierfür ist eine Untersuchung, die damit einen möglichen Seitenangriff aufgedeckt hat.

Published academic papers have demonstrated that by forcing a flush and reload of cache memory, it is possible to measure memory timings to determine an AES encryption key in use on another virtual machine running on the same physical processor of the host server if Transparent Page Sharing is enabled. This technique works only in a highly controlled environment using a non-standard configuration.

Mit anderen Worten: Der Angriff ist prinzipiell möglich, aber bisher nur unter Laborbedingungen reproduzierbar.

Ist das ein Problem?

Die Einsparpotenziale von TPS sind ohnehin umstritten. Es greift ohnehin nur wenn die Arbeitsspeicher Belegung bestimmte Grenzwerte Überschreitet. VMware vSphere verwendet large memory pages von 2MB Größe. Die Wahrscheinlichkeit zweier identischer Pages im RAM von dieser Größe ist eher gering. Dennoch ließ VMware die TPS Funktion aktiv. Das Thema wird sehr schön in einem Artikel von Frank Denneman diskutiert.

Wann wird abgeschaltet?

Die unterschiedlichen Versionen werden in folgenden Zeiträumen deaktiviert:

  • ESXi 5.5 Update release – Q1 2015
  • ESXi 5.1 Update release – Q4 2014
  • ESXi 5.0 Update release – Q1 2015
  • The next major version of ESXi

Links