The upgrade contains conflicting VIBs. Remove the conflicting VIBs or use Image Builder to create a custom upgrade ISO image that contains the newer versions of the conflicting VIBs, and try to upgrade again.

Il nous a fallu fouiller au fin fond des logs d’ESXi pour identifier les VIB en question :

Si vous lisez attentivement les release notes, vous savez déjà que depuis ESXi 5.1 il est possible d’upgrader avec la commande esxcli directement depuis le vib depot de VMware (William Lam a d’ailleurs écrit un post à ce sujet pour détailler le process) :

You can upgrade and apply patches to ESXi 5.0.x hosts by using the esxcli command-line utility for ESXi to upgrade to ESXi 5.1 from a download depot on vmware.com or from a downloaded ZIP file of a depot that is prepared by a VMware partner.

Nous avons donc tenté la même opération en ssh et l’erreur retournée par ESXCLI est nettement plus précise que celle de VUM :

Au passage, on attend toujours un plugin VUM digne de ce nom pour le webclient…

Nous savions que c’était techniquement envisageable compte tenu du fait qu’un patch pour ESXi se résume à la copie d’une nouvelle build dans la “bootbank” après avoir copier la build courante dans la “altbootbank“ la “bootbank” inactive. Compte tenu du fait qu’ESXi est un OS stateless, le fait d’écraser la “bootbank” et la “altbootbank” pendant le fonctionnement ne pose pas de problème. Malgré tout, il nous a fallu chercher un peu pour trouver le bon paramètre à passer à “esxupdate” pour forcer la mise à jour (qui nécessite le “maintenance mode” par défaut) avec des vm en fonctionnement.

Voici un petit oneliner qui vous permettra de reproduire cet exploit (oubliez le support vmware naturellement) :

(get-view (get-vmhost vsp41esx01*|get-view).configmanager.PatchManager).InstallHostPatchV2($null, "http://www.hypervisor.fr/img/ESXi410-201206001.zip", $null, ((new-object Vmware.Vim.HostPatchManagerPatchManagerOperationSpec -Property @{cmdOption = "--maintenancemode"})))

Comme le détail le SDK, il est possible de choisir entre 3 sources de patch : metaUrls, bundleUrls ou vibUrls, tout dépendra du format du patch. Concernant le “maintenance mode”, toute la magie réside dans le paramètre ”–maintenancemode” qui fait parti des “hidden options” d’esxupdate (malheureusement pas toutes commentées) :

–HA
–vib-view
–maintenancemode
–force
–test ‘Test update transaction only–do not change sytem.’
–all ‘Display all bulletins. Default is to display only the applicable updates.’
–long ‘Produce more detailed response in query or info output.’
–noobsoletes ‘Ignore obsoletions during update. (Enables downgrading to older bundles.)’
–reinstall ‘Re-install a bundle that is already installed.’
–nodeps
–nosigcheck
–nocache
–olderversion
–cachesize
–cleancache
–compliant

A l’opposé, il est aussi possible de désinstaller un patch (à chaud toujours), ce qui est malheureusement impossible à faire avec VUM :

(get-view (get-vmhost vsp41esx02*|get-view).configmanager.PatchManager).UninstallHostPatch("ESXi410-201101223-UG",((new-object Vmware.Vim.HostPatchManagerPatchManagerOperationSpec -Property @{cmdOption = "--maintenancemode"})))

Bien sur, le tableau sera mis à jour au fil des version mais n’hésitez à nous dire si non avons zappé une build.

Le problème c’est que LE serveur qui empêche le Remediate bloque la mise à jour de l’ensemble du cluster ou pire fait échouer la tache en cours de route car il n’existe pas d’option “skip” en GUI, mais en PowerCLI (+VUM cmdlets) on fait ce qu’on veut ! Voici un petit onliner qui va mettre à jour chaque serveur du cluster l’un après l’autre même si l’une des mises à jour échoue, vous pourrez ainsi troubleshooter après coup :

Get-Cluster "mon_beau_cluster"|Get-VMHost|%{$_|Remediate-Inventory -baseline (Get-Baseline "ESXi 4.1 U1 Up") -HostFailureAction FailTask -ClusterDisableDistributedPowerManagement 1 -ClusterDisableHighAvailability 1 -ClusterDisableFaultTolerance 1 -HostDisableMediaDevices 1 -Confirm:$false}

Naturellement, vous obtiendrez la liste de vos baselines avec la comment “Get-Baseline”. Et voila le résultat :

On peut refaire un petit scan derrière :

Get-Cluster "mon_beau_cluster"|Get-VMHost|%{$_|Remediate-Inventory}
 

En appliquant la mise à jour ESXi410-201104401-SG dispo depuis le 28/04/2011 (la première update depuis l’Update 1 de la 4.1)  sur notre lab à l’aide de VUM, nous nous sommes retrouvés avec cette erreur : “The host returns esxupdate error codes: 10“. Plus précisément, en utilisant la fonction “Scan…” de VUM directement sur un des ESXi d’un cluster car l’erreur retournée lorsque nous avons tenté un “Scan for Updates” sur ce cluster était beaucoup trop vague.

Heureusement, la réponse à ce problème a été particulièrement bien détaillée par un membre de VMware dans un thread sur le forum de l’éditeur :

[...]/tmp was added in 4.1U1 to the list of directories “cleaned” by /sbin/tmpwatch.sh.  (tmpwatch.sh is run by root’s crontab /var/spool/cron/crontabs/root).  tmpwatch is not aware that /tmp/scratch is special and needs to be left alone.

[...] On ESXi Installable, /scratch is a symlink to some /vmfs/volumes/… place, not assaulted by tmpwatch.

[...] So only Embedded is affected, and then only a subset (diskless machines), and then a subset of those (without suitable scratch space on the boot USB key).

Pour résoudre le problème en attendant un prochain patch, plusieurs solutions sont à votre disposition (merci aux membres du forum ainsi qu’à filbo pour les détails) :

• Utiliser des supports USB/SD supérieurs à 5Go (pour la partition scratch soit bien créée à l’install)
• Rediriger la scratch vers un volume vmfs via les advanced settings (ScratchConfig.ConfiguredScratchLocation)
• Modifier le script /sbin/tmpwatch.sh (la pire des solutions pour des raisons évidentes)
• Recréer le répertoire manquant via mkdir -p /tmp/scratch/var/tmp (la solution la plus rapide car ne nécessite pas de reboot mais non durable)

If any problem is detected during the boot process, the system automatically boots from the previously used bank of memory.

Suite à une update, le serveur reboot et fini en PSOD :

Après un hard reset, le serveur à booté sur la version précédente du firmware et nous avons pu constaté la cause du problème (aussi corrigé automatiquement d’ailleurs) en relançant une update avec VUM :

Après reboot, le nouveau firmware est opérationel :

Respect !