vCenter Phantom Alarm

In einem vSphere5 Cluster (vCenter 5.0.0) zeigten viele VMs ein rotes Alarm Symbol, jedoch war im Alarm-Tab der VM keine Information zu finden. Alle VMs waren online und verhielten sich normal. Wir haben es offensichtlich mit einem Phantom Alarm zu tun.

Was zuvor geschah

Der Cluster hatte einige Tage zuvor einen harten Absturz infolge eines Stromausfalls und einer zu schwachen Unterbrechungsfreien Stromversorgung (UPS), die ihrem Namen keine Ehre machte. Nach Wiederherstellung der Stromversorgung starteten die ESX Server zunächst ohne Storage. Wie dies genau erfolgte, entzieht sich meiner Kenntnis. Danach zeigten alle VM die rätselhaften Alarme.

Erste Hilfe

Das Alarm Symbol verschwand, wenn man die VM mittels vMotion auf einen anderen ESX Host verschob. Eine spätere geplante Abschaltung des Clustern und ein kontrollierte Neustart ließ ebenfalls alle Phantom Alarme verschwinden.

Eine vergleichbare Beobachtung wird auch in den VMware Communities berichtet.

Bug

Hierbei handelt es sich um einen Bug in vCenter. Durch Zufall fand ich eine Beschreibung dieses Verhaltens in den Releasenotes von vCenter 5.0 Update1. Die Beschreibung findet sich im Kapitel “Known Issues” unter  “Storage“. Hier ein Auszug aus den VMware Releasenotes:

vCenter Server 5.0 virtual machines might display a red warning icon in the inventory

In vCenter Server 5.0, some VMs might display a red warning icon in the inventory, however the alarms tab for the VM does not indicate any alarm was triggered. This can appear for powered on and powered off VMs.

Workaround: Possible workarounds. Note that these are all temporary solutions.

  • Restart the management agents on the affected ESX/ESXi host
  • Restart the vCenter Server Server service
  • Remove the ESX/ESXi host from inventory, and register the host back with vCenter or remove and re-register affected VMs.

Warten wir auf U2…… 🙂

Backup-Exec 2012 Fehler LU1825

Live Update von Backup-Exec 2012 scheitert mit Fehler LU1825.

Im Live-Update Fenster wird ein Servicepack oder Hotfix für das installierte Produkt angezeigt. Nach dem Download bricht Live-Update mit der Fehlermeldung LU1825 ab.

LU1825: Dieses Update hat versucht, eine zu seiner Installation erforderliche Anwendung auszuführen. Die Ausführung der Anwendung ist jedoch fehlgeschlagen. Das Update ist dadurch möglicherweise beschädigt. Versuchen Sie, dieses Update bei der nächsten Ausführung von LiveUpdate abzurufen. Klicken Sie hier, um weitere Informationen zu diesem Fehler zu erhalten „Backup-Exec 2012 Fehler LU1825“ weiterlesen

DRS Cluster im Ungleichgewicht

Versetzt man einen ESXi Host im DRS Cluster in den Wartungsmodus, so wird die Last (VMs) auf die verbleibenden Hosts verteilt. Wird der Wartungsmodus beendet, kann man häufig beobachten, daß der jetzt frei ESXi Host nicht mit VMs befüllt wird. Auch nach Stunden, oder gar Tagen ist die Last immer noch stark ungleich verteilt. Ich habe mich schon oft gefragt, ob das DRS vielleicht falsch konfiguriert, oder gar defekt ist.

Es ist alles in Ordnung

Die Aufgabe von DRS besteht nicht darin, alle Hosts gleichmäßig auszulasten, sondern VMs die Ressourcen zu bieten, die sie benötigen. Das bedeutet: Wenn ein einziger Host genügend Ressourcen bereit stellt, um die Bedürfnisse aller VMs im Cluster zu bedienen, so besteht kein Grund VMs auf andere Hosts zu verschieben. Denn jede vMotion-Aktion kostet Ressourcen. Steht am Ende der Verschiebung kein Gewinn für die VMs, so ist dies als Verschwendung zu betrachten. Frank Denneman, der als Spezialist in DRS Fragen gilt, erklärt in seinem Artikel “Disabling MinGoodness and CostBenefit” dieses Phänomen und warum man die Parameter MinGoodness und CostBenefit besser nicht manipulieren sollte.

MinGoodness und CostBenefit

Ein VMware KB Artikel erklärt, wie man die obigen Parameter außer Betrieb setzen kann. Doch was ist deren Aufgabe?

CostBenefit

vCenter überwacht das Verhalten aller VMs. Es berechnet, wieviele Ressourcen notwendig sind eine VM von HostA nach HostB zu verschieben. Je nach Last dieser VM können hierfür erhebliche CPU Ressourcen während des Verschiebevorgangs von Nöten sein. Das ist der “Cost” Anteil in CostBenefit. Dem gegenüber steht der Nutzen durch frei werdenden Ressourcen auf dem Quell-Host nach der Verschiebung.

MinGoodness

vCenter wird normalerweise nur VMs auf Hosts verschieben, wenn diese eine geringere mittlere Auslastung haben als der urprüngliche Host. MinGoodness gibt DRS Auskunft, inwieweit die Verschiebung sich auf die Auslastung des Clusters auswirkt.

Setzt man beide Parameter in den erweiterten Eigenschaften des DSR Clusters auf Null, so vermittelt man dem DRS Algorithmus, vMotion Aktionen seien “kostenfrei” und nach dem Umzug muss der Nutzen für Host und VM nicht signifikant höher sein als zuvor.

vCenter neu starten?

Ein billiger Trick, um vCenter zum Ausgleich des Clusters zu bewegen, war bisher der Neustart von vCenter. Der Grund, warum DRS danach bereitwilliger vMotion Aktionen auslöst ist recht einfach erklärt. Durch den Neustart “vergisst” vCenter wie teuer ein vMotion einer bestimmten VM sein könnte, da historische Daten früherer Migrationen dieser VM verloren gehen. Man kann sagen, vCenter lässt sich nur aus Unwissenheit auf eine teure Verschiebung ein.

VMs mit ROK Key installieren

ROK Grundlagen

Microsoft Betriebsysteme können von Serverherstellern als sogenanntes Reseller Option Kit (ROK) bezogen werden. Dabei handelt es sich um speziell auf die jeweilige Hardware angepasste Versionen des entsprechenden Beriebsystems. Faktisch entspricht diese Version der Microsft System Builder Version, ist aber preislich deutlich günstiger und kann getrennt von der Hardware eingekauft werden. In der Regel sind diese Versionen mit einem BIOS Lock ausgestattet, so daß man sie nur auf der Original Hersteller Hardware installieren kann. D.h. ein Windows Server 2008R2 ROK von IBM kann auch nur auf IBM Hardware installiert werden. Das gleiche gilt für Fujitsu, HP, Dell etc. ROK Versionen werden als eigenständige Produkte vom Kunden erworben und von diesem auch selbst installiert. Der mitgelieferte Key muß auf der Hardware durch den Kunden angebracht werden. Nur dann gilt das System als korrekt lizenziert. Ein verlorener Key kann nicht bei Microsoft angefragt werden, da er dort nicht hinterlegt ist.

ROK und virtuelle Systeme

Soweit alles ganz einfach. Interessant wird die Sache aber wenn ROK Versionen in virtuellen Umgebungen eingesetzt werden sollen. Beispielsweise soll eine Windows Server 2008 R2 Datacenter Edition (Fujitsu ROK) in einer VM installiert werden, die auf einem Fujitsu ESXi Server läuft. Rechtlich ist das in Ordnung, wenn für jeden Knoten im Cluster eine Datacenter Lizenz vorhanden ist (notwendig für vMotion).

„VMs mit ROK Key installieren“ weiterlesen