vmware image customization is in progress – Boot Problem

Bei der Ableitung einer VM vom Template kam es zu einer Störung mit der Windows Aktivierung. Dadurch konnte das Sysprep nicht vollständig beendet werden. Beim Neustart der VM erscheint kurz die von Sysprep bekannte Meldung:

vmware image customization in progress

Die Meldung verschwindet und das System bootet. Beim nächsten Neustart wiederholt sich der Vorgang. Möchte man die abgeleitete VM dennoch verwenden (ich rate davon ab), so kann man die Sysprep Versuche abstellen, indem man einen Eintrag der Registry verändert.

Regedit

HKEY_LOCAL_MACHINE > SYSTEM > CurrentControlSet > Control > Session Manager

ImgCust02

Unter Session Manager den Eintrag BootExecute suchen und ändern.

ImgCust01Entfernt man den Wert “sysprepDecrypter.exe” und startet danach das System neu, so erscheint keine Sysprep Meldung mehr.

Nur zum Testen

Das oben beschriebene Verfahren funktioniert zwar, aber eine VM, die bei der Ableitung ein unvollständiges Sysprep durchlaufen hat, würde ich auf keinen Fall für den produktiven Einsatz verwenden! Besser die Ursache der Störung suchen und erneut ableiten. In meinem Fall war es ein Problem mit der Windows-Aktivierung. Nach dessen Beseitigung machte die VM nach der Ableitung einen ordentlichen Sysprep.

ESXi Maintenance Mode via PowerCLI und vMA

PowerCLI

Bevor die Kommandos abgesetzt werden können, muss eine Verbindung mit dem Host oder den VCenter hergestellt werden.

Verbindung mit einem ESXi herstellen:

Connect-viserver -server <Servername> -user root -password <myPass>

Verbindung mit einem vCenter herstellen:

Connect-viserver -server <vCenter> -user <domain\user> -password <myPass>

Start Maintenance Mode

Set-VMHost -VMHost <Hostname> -State maintenance

Host wechselt in den Wartungsmodus. Fall er sich schon im Wartungsmodus befindet passiert nichts.

Maintenance Mode beenden

Set-VMHost -VMHost -State connected

Host beendet den Wartungsmodus. Wenn der Host nicht antwortet wird die Verbindung neu hergestellt.

Reboot Host

Restart-VMHost -VMHost <Hostname> [-Force] [-Evacuate] [-RunAsync] [-Whatif] [-Confirm]

Parameter in eckigen Klammern [ ] sind optional.

  • Force: Host wird neu gestartet, auch wenn er nicht im Wartungsmodus ist
  • Evacuate: (funktioniert nur bei Connect zu vCenter!). Ausgeschaltete VMs werden automatisch auf anderen ESX Servern registriert. Wenn diese nicht möglich sit, bleiben sie auf dem Host und sind für die Dauer des Reboots nicht erreichbar (grau). Aktive VMs werden migriert. Falls dies nicht möglich ist wartet der Prozess, bis diese manuell abgeschaltet werden.
  • RunAsync: Kommando kehrt sofort zur Konsole zurück, ohne den Abschluss des Vorgangs abzuwarten.
  • Whatif: Ausgabe erfolgt nur auf der Konsole. es werden keine Aktionen ausgeführt. Dient der Simulation.
  • Confirm: Default = true. Ist der Parmeter gesetzt erwartet das Kommando eine Bestätigung durch den Nutzer.

vMA / vSphereCLI

Von der vMA bzw. der vSphereCLI gibt es drei Komanndos für den Wartungsmodus:

vicfg-hostops --server <ESX-Host> --operation enter|exit|reboot

Der Befehl kann entweder mit dem Parameter enter oder exit oder reboot ausgeführt werden.

ESXi Upgrade 5.0 – 5.1: Host incompatible

Der Versuch einen ESXi Host mittels Updatemanager von Version 5.0 auf Version 5.1 zu aktualisieren scheitert mit der Fehlermeldung:

Software of system configuration of host ESX01 is incompatible. Check scan results for details.

Ursache ist nicht etwa eine Hardware Inkompatibilität, sondern es ist einfach nur ein fehlender Reboot. Zuvor wurde vCenter auf Version 5.1.0a aktualisiert. Dabei wurde der neue HA-Agent automatisch auf die ESX Hosts verteilt und dieser benötigt einen Neustart des Hosts. Nur wird der fehlende Neustart nicht angezeigt. Statt dessen scheitert das Upgrade mit obigem Fehler.

Nach Neustart funktioniert das Upgrade problemlos.

Links

VMware Knowledgebase 2034945

VMware Update Manager 5.1 Release Notes