VMtools silent upgrade

Werden die VMware Tools in einer Windows VM automatisch installiert, erfolgt direkt nach der Installation ein Reboot der VM. Es gibt prinzipiell zwei Methoden, um ein sogenanntes Silent Upgrade der VMtools ohne Reboot zu machen.

CLI

  • Login in VM
  • im vSphereClient die VM markieren und im Kontextmenü (rechte Maustaste) Guest > Install/Upgrade VMware Tools wählen.
  • Im Windows Gast System einen Command Prompt (CMD) öffnen. Bei Systemen ab Windows Vista / Server 2008 und neuer muss eine Administrative Commadshell ausgeführt werden (run as Administrator / als Administrator ausführen).
  • cd zum CDROM
setup.exe /S /v"/qn REBOOT=R"

oder

setup.exe /S /v"/qn REBOOTPROMPT=S"

Der Schalter /S entpackt die EXE ohne Rückfrage. Schalter /v übergibt das folgende Kommando an die entpackte MSI. Der Schalter /qn bedeutet Silent Install .MSI ohne Fortschrittsbalken. REBOOT=R verbietet den Neustart. REBOOTPROMPT ist eine Property des Windows Installers ab Version 4.5. Wird der Wert “S” gesetzt, unterdrückt der Installer den Reboot.

vSphereClient

Eine noch einfachere Methode ohne Login und Commandprompt, ist die Übergabe der Parameter im Upgrade Dialog des vSphereClient. Die zu übergebenden Parameter für das automatische Tools Upgrade sind unten dargestellt (vgl. Bild).

/S /v"/qn REBOOT=R"

Links

  • VMware KB1018377 – Installing VMware Tools in a Windows virtual machine
  • VMware KB2004754 – Installing VMware Tools in vSphere

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…… 🙂

VM Phantom LUN

Die Detailinformationen zu einer VM liefern eine Übersicht über alle mit dieser VM assoziierten Ressourcen wie z.B. Netzwerk, Datenspeicher etc.

Phantom Jagd

Mir ist aufgefallen, dass einige VMs nach einem Upgrade auf vSphere5 zwei LUNs unter Resources anzeigen.

Die VM hat aber nur ein einzelnes VMDK File und dieses liegt gemeinsam mit den Konfigurationsdaten auf einer LUN. Ein DVD-ROM ISO ist auch nicht eingebunden, wie man im Bild unten sehen kann. Woher kommt also die Phantom LUN? „VM Phantom LUN“ weiterlesen

Resourcepools und VMs auf einer Ebene

Zu meiner regelmäßigen vSphere Lektüre gehört der Blog von Frank Denneman. Oft findet man dort sehr gute Grundlagenartikel mit übersichtlichen Illustrationen.

In einem seiner aktuellen Beiträge schreibt er über VMs, die sich zusammen mit Resourcepools auf einer Hierarchie-Ebene befinden. Diese Vorgehensweise findet man immer wieder bei Kunden im produktiven Einsatz. Meist aus Unachtsamkeit, oder mangels tieferem Verständnis der Thematik. In seinem Artikel schildert er die Auswirkungen eines solchen Umfelds, wenn es zu akuter Ressourcenknappheit innerhalb des Clusters kommt.

Weitere Artikel zum Thema

ElasticSky: Das Resourcepool Paradoxon (Deutsch)
Yellow-Bricks: Resource Pool Pie Paradox (Originalartikel)
Yellow-Bricks: Resource Pools and Shares