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 !
Depuis 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 :
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 :
|
1 2 3 4 5 6 |
/vmfs/volumes # vmkfstools -D vplex_tstvmfs01/vm/fichier-ctk.vmdk Lock [type 10c00001 offset 196114432 v 33, hb offset 3268608 gen 9, <strong>mode 1</strong>, owner 5327db0f-aaaadddd-690f-0127474744 mtime 8006613 num 0 gblnum 0 gblgen 0 gblbrk 0] Addr <4, 200, 23>, gen 32, links 1, type reg, flags 0, uid 0, gid 0, mode 600 len 5243392, nb 6 tbz 0, cow 0, newSinceEpoch 6, zla 1, bs 1048576 |
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.