Conséquences du bug CBT sur ESXi 6.0

MAJ : Jean-Charles et Erwan, lecteurs de vBlog, viennent de publier chacun un commentaire très intéressant au sujet de l’opération de reset des CBT (lisez l’article d’abord pour info) : Veeam propose un script Powershell qui permet de procéder à cette réinitialisation systématique sur toute VM allumée (sauf en cas de présence d’un snapshot). C’est déjà beaucoup plus léger à réaliser que la méthode préconisée actuellement par VMWare … Un grand merci à eux pour l’info.

Le fameux bug CBT d’ESXi 6.0/6.0u1 n’en finit pas de refuser d’abdiquer ! En effet, la page du KB correspondant a été mise à jour à plusieurs reprises depuis la date de sortie du patch spécifique livré par VMWare fin Novembre. Aujourd’hui, encore, VMWare apporte des compléments d’information concernant les conséquences post-patch et les méthodes de correction définitives. Le moins que l’on puisse dire c’est que les productions concernées ne sont pas sorties d’affaire …

VMWare indique qu’une fois le patch spécifique passé, il faut malgré tout refaire des sauvegardes totales pour pouvoir repartir sur des bonnes bases. Le principe est de ne plus utiliser les IDs CBT corrompus dans les sauvegardes VM. Ca n’a l’air de rien, mais ce n’est pas forcément facile à faire, suivant le type d’outil de backup. Par exemple, pour nous, Avamar utilise systématiquement le CBT et considère que chaque sauvegarde est en fait une “totale” (les incrémentales ou différentielles n’existent pas dans la terminologie Avamar) ; difficile dans ces conditions de savoir si le produit en question continue à faire référence à des vieux IDs CBT corrompus ou non.

Et ce n’est pas tout ! En effet, si vous utilisez autre chose que du vmdk en mode “thick Eager Zeroed” (autant dire la majorité des productions vSphere, de mon point de vue… qui n’utilise pas le mode thin en vmdk aujourdh’ui, sauf cas particulier ?) vous devez réinitialiser complètement le CBT de chaque VM pour être tranquille ! Une page spécifique existe pour réaliser cette opération, le KB #2139574. Vous le verrez, en gros, il faut arrêter complètement la VM, supprimer tous les snapshots éventuels et “bidouiller” la config de la machine, avant de tout relancer.

En substance : pour tous ceux qui sont passé leurs hyperviseurs sur ESXi 6.0/6.0u1 AVANT que le patch ne soit sorti et qui ont réalisé des sauvegardes en mode CBT … je le dit sans ambages, c’est la GROSSE MELASSE.

Nul doute que ce bug spécifique, à lui seul, risque de causer des sueurs froides à l’ensemble des clients vSphere 6 pendant encore de longues semaines. De plus, il est visiblement impossible de savoir avec précision si une sauvegarde est cohérente ou non, en tout cas pour l’instant. Il faudrait pour cela disposer d’un outil spécifique – un pour chaque logiciel de sauvegarde – permettant de lister les IDs CBT référencés dans l’ensemble des sauvegardes VM dont la date de référencement est antérieure au passage du patch correctif… sauf très bonne volonté de l’éditeur, je ne vois pas comment cela pourrait être proposé.

Est-ce que certains d’entre vous sont concernés par ce problème ? Quelle stratégie avez-vous adoptée (avant et après la sortie du patch) ?

Pour rappel, la page VMWare traitant du bug CBT : KB2136854.
La page décrivant la procédure pour réinitialiser complètement le CBT pour une VM donnée : KB2139574.
La page décrivant la méthode spécifique de Veeam permettant de réinitialiser le CBT sur toute VM en fonctionnement : KB1113.