Photo-2016-06-20-10-20-06_8646

Un nouveau bug “CBT” d’ESXi sur la dernière build :(

Bon Lundi à tous … enfin, façon de parler :( . En effet, en consultant ma timeline Twitter ce matin, je suis tombé sur un tweet de Didier Wenger faisant mention d’un nouveau bug “CBT like” (voir ce billet et sa résolution sur le précédent, qui a fait couler beaucoup d’encre).

En effet, la dernière build “Express Patch 6” d’ESXi 6.0, build 3825889, semble être de nouveau affectée par un bug relatif à la gestion du CBT (j’ai envie d’hurler, là, ça se sent ou pas ?). Seules les machines de type Windows 2008 ou supérieures semblent touchées. Comme indiqué dans le billet du blog Running System (excellent blog au passage), globalement, vous avez deux symptômes potentiels qui vous confirmeront que vous êtes effectivement touchés par ce bug : un message d’erreur récurrent dans le vmware.log des VMs (sympa de se palucher des milliers de VM à la recherche du problème) et/ou plus sûrement une augmentation importante du volume de vos sauvegardes incrémentales de VMs (qui s’apparentent plus à de la totale déguisée).

La meilleure parade pour tous ceux qui ont déjà des ESXi en build 3825889 est de revenir très très vite dans la build “Update 2”, à savoir la 3620759. Et comme c’est visiblement ENCORE lié au CBT, si vous voulez être sûr de vos backups, il faut réinitialiser le log CBT de toutes vos VMs et relancer des totales, une fois les ESXi à la bonne version. Chouette, je me demandais ce qu’on allait faire ces prochains jours, tellement on avait pas de boulot … Ca mériterait un “Rognotudju”, FRANCHEMENT.

En général je suis assez magnanime voire compréhensif avec VMware, mais là, c’est complètement inadmissible qu’un type de bug pareil portant sur une fonction aussi essentielle du fonctionnement des VMs ressorte encore.

1

MAJ : Contourner une erreur de vMotion “the source detected that the destination failed to resume”

Mise à jour le 09/07/2013 : une méthode plus simple (pas de ligne de commande), effectuez tout simplement un STORAGE vMotion de votre VM sur un autre datastore de votre environnement, ensuite, l’ESXi “lache le lock”. Merci à Mikael (qui se reconnaitra) pour l’info !

tipDepuis quelques semaines/mois, nous sommes confrontés sporadiquement à des erreurs de vMotion sur certaines VM de production. La VM en question commence son vMotion et termine en erreur aux alnentour de 65/75% avec l’erreur générique “A general system error occurred: The source detected that the destination failed to resume”. Si l’on regarde le détail de l’erreur, on découvre en fait un problème de lock au niveau des disques vmdk :

Capture

Après pas mal de recherches et quelques cheveux arrachés, il se trouve que le problème est lié à nos outils de backup de VM utilisant la fonction CBT. Cette fonction activée en standard sur les VM disposant d’un profil hardware 7+ génère des fichiers trace permettant de suivre les blocs modifiés entre chaque sauvegarde afin d’optimiser grandement le temps de parcours des vmdk. Pour une raison encore obscure, certains fichiers CBT sont lockés pendant la phase de sauvegarde, mais pas libérés.

Ceci étant, il existe une solution de contournement pour pouvoir s’en sortir. Il s’agit de déplacer les fichier de tracking de la VM dans un répertoire temporaire. Ces fichiers n’étants pas très gros (quelques Mo) cela ne pose pas de souci en terme de consommation d’espace disque. D’autre part, ces locks sont libérés au fur et à mesure que vous “entretenez” votre ferme VMWare via des reboots d’ESXi lors de remediations par exemple.

Voici la méthode : la VM “machine” est concernée par ce blocage de vMotion. Connectez vous en SSH (ou en mode console) sur le serveur ESXi sur lequel est hébergée la machine, placez vous à la racine du datastore qui contient la VM :
cd /vmfs/volumes/DATASTORE

Ensuite, créez un répertoire temporaire (qui va accueillir les fichiers lockés) :
mkdir temp_lockfiles

Maintenant, placez vous dans le répertoire de la machine virtuelle, en général identique à son nom lors de sa création :
cd machine

Enfin, déplacez les fichier “ctk” vers le répertoire temporaire précédemment créé :
mv *ctk.vmdk ../temp_lockfiles

Normalement, à l’issue de cette opération, vous devriez à nouveau pouvoir déplacer votre machine d’un ESXi à l’autre. Evidemment, le déplacement des fichiers de tracking et leur disparition du répertoire de la vm obligera votre outil de sauvegarde, à la prochaine échéance, à parcourir l’ensemble des disques.

Une autre petite astuce qui vous permet de savoir, avant d’utiliser cette solution de contournement, quels sont les fichiers lockés. Vous pouvez utilisez cette commande sur un fichier quelconque du datastore :
vmkfstools -D NOMDUFICHIER

Vous allez obtenir un listing de ce type :

Suivant le “mode”, vous pouvez savoir si le fichier est locké ou non : mode 0, le fichier n’est pas locké ; mode 1, il l’est.

En somme, il y a sans doute des problèmes purement VMWare par rapport à la gestion des locks sur ces fichiers de tracking et il va falloir investiguer plus avant avec notre cher éditeur de solutions de virtualisation.