Détail de la fonction “fallback” d’ESXi

MAJ 22/10/2009 : Nous ne l’avions pas exprimé clairement mais le fallback fonctionne évidement lors d’une migration 3.5 > 4.0 (bootloader & bootbank).

Au détour du vSphere Upgrade Guide (lecture hautement recommandée pour ceux qui sont concernés) nous avons remarqué la procédure de “roll back” d’une update/upgrade ou d’un patch. Cette procédure correspond bien au détail d’architecture d’ESXi :

You can also intervene manually at boot time to choose which image to use for that boot, so you can back out of an update if necessary.

C’est un peu vague, nous vous proposons donc un détail du process :


  1. build “principale”
  2. SHIFT + R pendant le bootloader
  3. confirmation du fallback avec SHIFT + Y
  4. Fallback réussi (l’opération est instantanée)
  5. build “précédente”

Cette opération est possible sur toute les version d’ESXi, y compris la 3.5 :

Pour information, la fonction de fallback n’est pas disponible pendant le reboot qui suit une update :

Si l’on souhaite faire la manipulation inverse (totalement inutile donc indispensable de savoir comment), on obtient ce message (le même que lorsqu’il n’y a jamais eu d’update sur l’ESXi) :

Logique car si roll back il y a eu, c’est bien pour résoudre un problème ou appliquer une update plus récente. En admettant qu’on veuille VRAIMENT faire un roll back du roll back, il suffit de fouiller dans les fichiers boot.cfg des 2 partitions (bootbank et altbookbank) pour trouver la réponse :

Il faut repositionner la variable “bootstate” à “0″ pour que le bootloader repasse en mode “normal”.

Tags: ,

One Response to “Détail de la fonction “fallback” d’ESXi”

  1. [...] 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…. Compte tenu du fait qu’ESXi est un OS stateless, le fait d’écraser la [...]

Leave a Reply