Host Upgrade scheitert mit Fehler “Cannot execute upgrade script on host”

Kürzlich hatte ich das Vergnügen, einen älteren ESXi 6.0 Host auf Version 6.7U3 zu aktualisieren. Kurz nachdem ich im Update-Manger auf “Standardisieren” klickte, brach der Prozess mit folgender Fehlermeldung ab:

Cannot execute upgrade script on host

Diese Fehlermeldung ist nicht wirklich spezifisch. Wenn man sie googelt, findert man etwa ein Dutzend möglicher Usachen für das Scheitern. Diese können z.B. sein:

  • inkompatible Treiberpakete
  • volle vfat Partitionen
  • /bootbank/state.XXXXXXXX Verzeichnis ist nicht leer
  • Custom ISOs mit falscher Signatur für intel i40en Treiber Paket
  • Probleme mit FDM Agent (HA)

Keiner der oben genannten Punkte passte zu dem von mir beobachteten Problem. Ein guter Ausgangspunkt sollte ein Blick in vua.log auf dem betroffenen Host sein.

less /var/log/vua.log

Leider half das auch nicht weiter. Also schauten wir (nochmals) in die VMware Upgrade Matrix. Ein direktes Upgrade von ESXi 6.0 auf auf ESXi 6.7 U3 ist erlaubt, aber mit Einschränkung in einer kleinen Fussnote.

KB 76555 besagt, dass es ein Problem mit veralteten VIB Zertifikaten auf Hosts unterhalb einer bestimmten Buildnummer gibt.

  • ESXi 6.0 GA vor Build 9239799
  • ESXi 6.5 GA vor Build 8294253

Tatsächlich hatte unser ESXi Host eine Buildnummer von 7967664 (U3e), die sich im kritischen Bereich befand. Wir mussten also einige Patches nachinstallieren bis zum Stand Juni 2018 (ESXi600-201807001). Danch funktioniete das Upgrade problemlos.

Was war schiefgelaufen?

Natürlich hatten wir die Matrix während der Planungsphase Anfang März 2020 überprüft. Das ist eine Standardprozedur. Leider hat sich in der Zwischenzeit an der Matrix etwas geändert (die Fußnote wurde hinzugefügt). KB 76555 wurde im Mai 2020 aktualisiert, und das Problem betrifft Upgrades auf ESXi 6.7 Versionen nach dem 28. April 2020.

Was kann man daraus lernen? Unmittelbar vor Beginn der praktischen Arbeiten an einem Projekt nochmals alle Abhängigkeiten überprüfen.

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 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.

Windows Update Fehler 80243004

 

Wenn Windows Update mit einem Fehler 80243004 scheitert, dann gibt es hierfür eine sehr unkonventionelle, aber funktionierende Problemlösung, die Todd4Tech seinem Blogartikel beschreibt. Auch wenn die Lösung zunächst nach blankem Unfug aussieht, so funktioniert sie doch erstaunlicherweise. 🙂

Links