Kategorie-Archiv: ESXi

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.

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?

 

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

 

ESXi iSCSI Troubleshooting

Für jemanden, der hauptsächlich im FibreChannel Protokoll zu Hause ist, dem bereitet iSCSI immer wieder Spaß und Kurzweil. So geschehen in der vergangenen Woche, als wir ein verzwicktes Phänomen bei der Einbindung eines iSCSI Targets hatten. Auch wenn es eine gute Fingerübung für Troubleshooting war, so brachte es einige graue Zellen zum Rauchen.

Das Szenario

  • Zwei ESXi 5.5 Server mit je 2x1Gbit LAN Adapter für iSCSI
  • je 2 Kernelports in unterschiedlichen Subnetzen (10.0.0.x und 10.0.1.x) unabhängig von Management Network und VM-Network (192.168.1.x)
  • keine Jumboframes (MTU 1500)
  • zwei LAN Switches für Redundanz
  • 2 Datacore Server mit SANsymphony-V 10 und je 2 x 1Gbit für iSCSI Frontend Ports [FE]
Host iSCSI1 iSCSI2
ESX4 10.0.0.14 (vmk4) 10.0.1.14 (vmk5)
ESX5 10.0.0.15 (vmk4) 10.0.1.15 (vmk5)
SDS1 10.0.0.31 10.0.1.31
SDS2 10.0.0.32 10.0.1.32

 

DatacoreiSCSI2

Das Phänomen

Bei der Konfiguration des Software iSCSI Adapters kam jeweils nur für einen Kernelport eine iSCSI Verbindung zustande. Das Verhalten war auf beiden ESXi Servern gleich. Weiterlesen

VMs mit spezifischem NIC suchen

In größeren VMware Umgebungen kann die Suche nach bestimmten VM-Eigenschaften sehr mühsam werden. Natürlich kann man in die Einstellungen jeder VM gehen und nachsehen, aber das ist zeitaufwendig und stupide. Hier ist – wie so oft – PowerCLI der Freund und Helfer.

Zunächst stellt man eine Verbindung mit vCenter oder einem bestimmten ESX Host her.

Connect-VIserver <Servername>

Welche VMs haben einen e1000 Netzwerk Adapter?

Get-vm | ?{Get-networkadapter $_ | where-object {$_.type -like "e1000" }}

 

Welche VMs haben einen VMXNET Netzwerk Adapter ?

Analog funktioniert die Abfrage nach einem VMXNET Adapter. Im Resultat werden VMs mit VMXNET2 und VMXNET3 Adapter gelistet.

Get-vm | ?{Get-networkadapter $_ | where-object {$_.type -like "VMX*" }}

 

 

VM Diskfiles mit mehr als 4 TB unter vSphere 5.5 erstellen

 

Gelegentlich gibt es Anwendungen, die große virtuelle Disks in einer VM erfordern. Seit vSphere 5.5 ist die 2 TB (minus 512 Byte) Grenze für vDisks gefallen. So steht es zumindest in den Configuration Maximums von vSphere 5.5:

Virtual Disk Size 62TB

Wer aber im vSphere Client (mea culpa, ich benutze den noch häufig) die Eigenschaften einer VM öffnet, um dort beispielsweise eine 5 TB Disk zu erstellen, wird mit einer Fehlermeldung konfrontiert:

The disk capacity entered was not a properly formed number or was out of range. It has been replaced with the nearest acceptable value DiskCapControl : value 5497558138880 is out of range (1048576,4398046511104)

Betrachtet man die letzte Zahl der Meldung (in Byte) so stellt man fest, daß es genau 4 TB sind. Auch die erzeugte vDisk ist genau 4 TB groß und nicht 5 TB wie gewünscht.

“Use the webclient, Luke!”

Wiederholt man die selbe Prozedur mit dem Webclient anstatt dem vSphere Client, so wird die vDisk in der gewünschten Größe erstellt. Offensichtlich möchte uns VMware schrittweise den vSphere Client abgewöhnen. Dass dies kein Bug ist, zeigt der Artikel KB 2054952.

Hier ist jedoch Vorsicht geboten. Mit der Konfiguration der großen vDisk nimmt man sich einige Konfigurations-Optionen wie zum Beispiel:

  • Virtual SAN
  • Fault Tolerance
  • Betrieb der VM nur auf ESXi 5.5 (auch bei HW Version 8)
  • Verwendung von Buslogic virtual SCSI Adapter

Die genauen Einschränkungen beschreibt VMware unter KB 2058287.

Links

  • VMware KB 1003497 – ESXi/ESX Configuration Maximums
  • VMware – vSphere 5.5 Configuration Maximums (PDF)
  • VMware KB 2054952 – Value out of range error message when adding disks larger than 4TB in vSphere Client
  • VMware KB 2058287 – Support for virtual machine disks larger than 2 TB in VMware ESXi 5.5

Syslog Collector Troubleshooting

Syslog Collector logt nicht

ESXi Hosts, welche vom Flashmedium booten haben keinen permanenten Logspeicher. Das bedeutet, dass alle Logmeldungen nach einem Host Neustart verloren gehen. Aus diesem Grund gibt es den Syslog Collector Dienst, welcher bei der vCenter Installation (Win) zusätzlich installiert werden kann. Die Konfiguration auf habe ich in einem früheren Blogeintrag geschildert. Dieser empfängt Logeinträge von den ESXi Hosts und speichert sie lokal in rotierenden Logfiles ab.

Der VMware Support bat mich kürzlich, diese Logs für einen ESXi Host bereit zu stellen. Zunächst musste ich das Logverzeichnis auf dem Server mit Syslog Collector finden. Es liegt bei Standard Installationen unter:

%ALLUSERSPROFILE%\VMware\VMware Syslog Collector\Data

Beziehungsweise:

"C:\ProgramData\VMware\VMware Syslog Collector\Data"

Dort hat jeder überwachte ESXi Host ein Verzeichnis mit der jeweiligen IP des Hosts. Das Verzeichnis war schnell gefunden, jedoch staunte ich nicht schlecht, als ich den Zeitstempel der Logs sah.

syslogTrouble01

Seit über zwei Jahen gab es keinen Logeintrag mehr! Wie kann das sein?

Firewall

Auf dem Syslog Collector sah alles gut aus und der Dienst war aktiv. Danach warf ich einen Blick auf die ESX Firewall (Host > Configuration > Security Profile > Firewall > Settings). Damit wurde die Ursache schnell klar. (Thanks to Ivo Beerens, whose article gave me a hint to the solution)

syslogTrouble02Die Firewall des ESXi blockierte Verbindungen über UDP 514. Kein Kontakt – keine Logs – so einfach. :-)

Der Haken bei syslog muss unbedingt gesetzt sein.

syslogTrouble03Schon wenige Augenblicke nach Übernahme der Regel füllte sich das Logverzeichnis auf dem Syslog Collector mit neuen Einträgen.

syslogTrouble04

Das half zwar nicht bei der Lösung einer anderen Fragestellung mit dem VMware Support, jedoch können in Zukunft die Logs ausgelesen werden.

Links

Ivo Beerens Blog – vSphere Syslog Collector troubleshooting

 

Fujitsu Eternus DX: Readonly LUN Mapping

Im Storage Area Network SAN gibt es mehrere Wege, den Zugriff auf Speichervolumes zu steuern. Zunächst kann man über Zoning festlegen, welche Initiatoren welche Targets sehen dürfen. Unterhalb des Targets werden Zugriffe auf LUNs in der Regel mittels LUN-Mapping gesteuert. Meist gibt es drei Optionen:

  • readonly
  • read / write
  • no access

Auf diese Weise lässt sich der Zugriff unterschiedlicher Hosts kanalisieren. Beispielsweise Lese- und Schreibzugriff (RW) für ESXi Hosts und reinen Lesezugriff (readonly) für den Backupserver. Somit kann verhindert werden, daß dieser versehentlich Signaturen auf VMFS LUNs schreibt. Man kann dies zwar unterbinden, aber ein readonly LUN Mapping ist da die bessere Wahl.

Readonly Eternus DX ?

Zur Erhöhung der Sicherheit wollte ich kürzlich Volumes auf einem Eternus DX Storage System als readonly einem Host bereitstellen. In der GUI fand ich keine Einstellung hierfür (was nichts heissen muss), auch das Handbuch hatte keinen Hinweis darauf. Letztlich blieb mir nur die Anfrage beim FTS Support. Der Storage Support in Paderborn teilte mir mit, was ich bereits befürchtete:

Ein Readonly Zugriff ist für ausgewählte LUNs und Hosts nicht möglich.

Schade. Dies ist ein Rückschritt im Vergleich zu den ausgemusterten Storages der SX Serie.

ESXi Hostfehler: Unable to apply DRS resource settings on Host

Eine etwas seltsame DRS Fehlermeldung kann angezeigt werden, obwohl DRS auf dem Cluster nicht aktiviert ist.

Unable to apply DRS resource settings on Host. Another task is already in progress. This can significantly reduce the effectiveness of DRS

Ursache ist dann sehr wahrscheinlich eine VMware Tools Installation die nicht ordentlich beendet wurde.

  • VM markieren
  • Kontextmenü “Guest”
  • End VMware Tools Install

Nach Abbruch der Tools Installation verschwindet die Meldung.

ESXi root Password Recovery

Warum es wichtig ist, den physischen Zugang zum Server und zu IPMI / iRMC zu sichern

Der Titel des Artikels ist nicht ganz korrekt, denn bei der beschriebenen Technik handelt es sich nicht wirklich um ein Recovery, sondern um ein Passwort Rücksetzung auf ein leeres Passwort des root Kontos. Eine detaillierte Anleitung schrieb Autor Lingeswaran auf Unixarena, die ich an einem Testsystem ausprobierte. Der Ablauf ist im Artikel unten dokumentiert.

Schwachstelle ?

Ich würde diese Möglichkeit nicht als Schwachstelle oder Sicherheitslücke von VMware ESXi betrachten, denn man benötigt zur Durchführung physischen Zugang zum Server bzw. zu dessen Remotekonsole (iRMC). Dass ein Rechenzentrum entsprechend gesichert sein muss, versteht sich im Grunde von selbst. Aber auch Remote Management Konsolen müssen geschützt sein und vor allem Defaultpasswörter müssen geändert werden. Für die unten beschriebene Prozedur benötigte ich keinen Zutritt zum Rechenzentrum. Alles wurde remote mittels iRMC durchgeführt. Das gilt auch für das virtuell eingelgte Ubuntu ISO. Weiterlesen

FTS Custom ESXi Image ohne Heartbleed Bug

Fujitsu (FTS) hat ein aktualisiertes Custom ESXi Image (5.5.0 U1) bereitgestellt, welches den SSL Heartbleed Bug nicht mehr enthält. Die Datei mit der Bezeichnung “FTS_FujitsuCustomImageESXi55Update1_31111746018_1108239.zip” ist seit dem 22.4.2014 im FTS Support-Portal erhältlich.

ESXi 5.5 update 1 build 1623387 is vulnerable to the actual openSSL heartbleed
security bug. To solve this issue VMware provides the Patch ESXi550-201404001
which is base of this ISO-Image.
If an upgrade on ESXi5.5 is done with this image, you also need to replace
certificates and change passwords.
See VMware KB-Article http://kb.vmware.com/kb/2076665

Links