Le manuel du parfait plombier des snapshots VMWare (maj continue)

EDIT: 25/06/2020 – Ajout sur les “consolidated needed” backups
EDIT: 10/06/2016 – Ajout du KB dédié aux problèmes de snapshots avec VSS Windows

Ceux qui travaillent au quotidien sur les environnements VMWare le savent : les snapshots sont une technologie très utile mais qui peut s’avérer sensible et assez pénible à débugguer si d’aventure quelque chose se passe mal pendant la phase de création/suppression. De plus, la plupart des outils de sauvegarde d’images de VM utilisent désormais le Change Block Tracking et les snapshots pour réaliser des backups. Ce sont donc des centaines d’instantanés qui sont quotidiennement créés et supprimés via les API vCenter.

Je vous propose ici de compiler les 3/4 problèmes les plus courants qu’on peut rencontrer lorsque les disques d’une VM sont dans un état précaire après une une phase de snap qui s’est mal passée, ainsi que les différentes méthodes que nous utilisons au quotidien.

Virtual Machine disks consolidation is needed

La première chose qu’on rencontre régulièrement est la fameuse alerte “consolidation needed” qui peut survenir lors de la tentative de suppression d’un snapshot : si l’opération de consolidation qui est normalement automatique, n’arrive pas à son terme (I/O importantes sur la VM interdisant la consolidation par exemple). Dans ce cas, le snapshot est supprimé logiquement, mais les disques associées restent “online” et ne sont pas détruits. La chose à faire et qui, finalement, fonctionne la plupart du temps est de lancer manuellement une consolidation dans les menus associées sur la VM :

Voici le KB#2003638 qui vous explique tout ça en vidéo : ICI.

N’oubliez pas aussi éventuellement vos proxies de sauvegardes, un disque résiduel monté sur ces machines de backup va provoquer souvent des “consolidation needed”. Il suffit dans ce cas de démonter ledit disque sur le proxy en cause et vous pouvez consolider correctement ensuite.

Le symptôme du “maximum consolidate retries was exceeded for scsix:x”

Si vous tentez une consolidation manuelle, il peut arriver que celui-ci échoue avec une erreur de type “maximum consolidate retries”. Cette erreur ne concerne que les versions ESXi 5.5 et 6.0. La plupart du temps, cette erreur est liée au fait que l’activité I/O de la VM est incompatible avec le “mini quiesce” nécessaire pour modifier les fichiers de config et re-basculer la VM sur ses disques vmdk principaux. Deux possibilités s’offre à vous dans ce cas, soit retenter la consolidation à un moment plus calme pour la VM, soit changer le mode de consolidation pour “passer outre” les problèmes d’I/O.

Voici le KB#2082886 qui détail les méthodes disponibles pour réaliser ce changement de mode de consolidation : ICI.

Consolidation error : msg.fileio.lock

La ça commence à bidouiller pas mal :) . A la fin d’une consolidation, si vous êtes confrontés à ce type d’erreur, du à des fichiers lockés et donc non supprimables, vous allez devoir jouer de la ligne de commande. En fait, il s’agit d’identifier le ou les fichiers verrouillés sur la machine virtuelle puis faire en sorte de libérer les locks en question.

Vous pouvez commencer à essayer la manipulation décrite sur plusieurs blogs et désormais assez connue qui consiste à utiliser, sur chaque fichier vmdk de la machine, la commande magique vmkfstools -D . Celle-ci vous donne des détails sur le fichier en question, son numéro de descripteur, quelques infos internes mais surtout la liste des locks ainsi qu’une des mac-address de chaque serveur ayant posé un verrou sur le fichier. Vous obtenez une réponse de ce type :

La mac-address qui vous permettra de retrouver le serveur qui a verrouillé le fichier se trouve sur la 3ème ligne dans l’exemple : aaaaaaaaaaaa. Repérez le serveur en question et essayez dans un premier temps de faire un vmotion sur celui-ci, si c’est possible. Cela peut suffire pour débloquer la situation. Je vous conseille d’aller voir le billet sur VroomBlog qui détaille la manipulation à réaliser.

Vous pouvez aussi obtenir une sortie de ce type :

Dans ce cas, vmkfstools indique qu’il s’agit d’un verrou en lecture seule. Si cela ne suffit pas, regardez d’abord du coté de vos proxys de sauvegarde, c’est souvent eux qui attachent les snap pour réaliser un backup, et vérifiez qu’il ne reste pas ce disque dans la liste des disques connectés à un de ces proxys.

Ensuite on rentre dans un mode plus aléatoire où il faut progresser pas à pas. Là, c’est difficile de proposer une procédure systématique, car c’est très lié à l’incident initial ayant causé le rpoblème et à l’état actuelle de la VM concernée. Vous pouvez, par exemple, tentez de relancer complètement les services de management du serveur ayant posé un lock sur un des fichiers en utilisant la commande services.sh restart. Nous avons rencontré un certain succès avec cette méthode, assez radicale malgré tout. Faites bien attention à désactiver le HA du cluster dans lequel le serveur se trouve avant de faire cette manipulation.

Si le lock est posé sur un fichier de type “ctk” assurant le logging du Change Block Tracking, Vous pouvez aussi, machine éteinte, supprimer le disque de la configuration (sans le supprimer physiquement évidemment ^^), déménager la VM sur le serveur où le lock se trouve, supprimer le fichier locké (en général, ça marche) et enfin rattacher le disque.

Problèmes avec le VSS Windows

Généralement, en environnement Windows, Un snapshot utilise le système VSS pour réaliser un instantané cohérent au niveau applicatif (SQL Server, Sharepoint, Exchange etc. …). Dans certains cas, ça se passe mal et le snap tombe en erreur. Pour remédier à la situation, il est possible de débrayer le VSS et de se contenter d’un Quiesce “File system”, autrement dit un flush des I/O juste avant le snap. Pour se faire, vous avez la KB1031298 dédiée chez VMware.

Quelques infos complémentaires

Voici une petite commande en PowerCLI qui vous permettra d’avoir la liste exhaustive de tous les snapshots en cours sur l’ensemble des machines virtuelles d’un vCenter. C’est simple, rapide, et ça vous permettra de taper sur les doigts de vos collègues qui laissent des snaps en route pendant des mois :) .
get-vm | get-snapshot | select-object vm, @{Name="Go";Expression={[int]$_.SizeGB}} , name, description, created | format-table

Vous pouvez aussi créer une alerte spécifique sur vCenter pour qu’un warning ou un critical soit levé en cas de snap sur une VM. Pour se faire, rendez-vous sur votre web client, dans la section “Manage-Alarm definitions” de votre vCenter, puis créez une nouvelle alarme comme suit :

Enfin, n’hésitez pas à me proposer d’autres méthodes ou astuces que vous utilisez au quotidien pour résoudre vos propres problèmes liés aux snapshots, pour la communauté !