Boîte à Outils Informatique
Procédure

Traiter une VM VMware avec chaîne de snapshots incohérente

Traiter une chaîne de snapshots VMware incohérente sans modifier les descripteurs au hasard : gel des écritures, inventaire VMDK, vmkfstools, logs, clone/restauration supportée et validation complète.

Virtualisation
ThématiqueVMware →
⌚ Environ 6 min de lecture
Voir mes favoris
DomaineVirtualisationNiveauExpertDurée1-4 hRisqueÉlevé

Objectif

Sécuriser une VM VMware dont la chaîne de snapshots ne peut plus être ouverte ou consolidée, préserver les données avant manipulation, identifier le maillon manquant ou incohérent et privilégier une méthode de récupération supportée telle que restauration ou clone lorsque la chaîne ne peut pas être réparée sans risque.

Prérequis

  • Sauvegarde récente ou copie intégrale du dossier VM sur un stockage disposant de suffisamment d’espace.
  • Accès vCenter et SSH ESXi pour les commandes de diagnostic en lecture.
  • Nom de la VM, datastore
  • Fenêtre permettant d’arrêter les écritures ou éteindre la VM lorsque nécessaire.
  • Capacité suffisante pour créer un clone ou restaurer une nouvelle VM.

Procédure pas à pas

1

Arrêter les opérations automatiques

Désactivez temporairement sauvegarde, réplication, snapshots automatiques et tâches de consolidation sur la VM. Si la VM peut être arrêtée sans impact majeur, éteignez-la pour figer l’état. Notez l’heure et la dernière opération réussie. Le premier objectif est de ne plus modifier la chaîne avant d’avoir compris sa structure.

Résultat attendu
  • Aucune tâche automatique ne modifie les VMDK pendant l’analyse.
2

Préserver une copie avant toute édition

Si l’espace le permet, copiez le dossier complet de la VM ou assurez-vous qu’une sauvegarde récente est restaurable. Une copie partielle des seuls descripteurs ne protège pas les données si une erreur de manipulation touche les fichiers delta ou flat. Vérifiez que le support de secours est réellement indépendant du datastore en incident.

Résultat attendu
  • Une voie de récupération existe avant toute manipulation de chaîne.
3

Lister tous les fichiers et repérer les ruptures

Affichez les fichiers par nom, taille et date. Recherchez une séquence -000001, -000002, etc. qui saute un niveau, des fichiers descriptor sans delta associé ou inversement. Ne concluez pas qu’un numéro manquant est forcément l’erreur : comparez avec la configuration et les descripteurs.

ls -lah /vmfs/volumes/<DATASTORE>/<VM-DIR>/
find /vmfs/volumes/<DATASTORE>/<VM-DIR>/ -maxdepth 1 -name "*.vmdk" -type f -print
Résultat attendu
  • L’inventaire physique du dossier est disponible avant analyse logique.
4

Identifier le disque réellement attaché à la VM

Consultez le fichier VMX ou les informations vCenter pour savoir quel descriptor est actuellement référencé. Une VM peut avoir plusieurs contrôleurs et plusieurs chaînes indépendantes. Vérifiez chaque disque séparément afin de ne pas reconstruire une chaîne qui n’est pas utilisée.

grep -E "scsi[0-9]+:[0-9]+.fileName|sata[0-9]+:[0-9]+.fileName|nvme[0-9]+:[0-9]+.fileName" /vmfs/volumes/<DATASTORE>/<VM-DIR>/<VM>.vmx
Résultat attendu
  • Le point d’entrée actuel de chaque chaîne de disque est connu.
5

Lire les descripteurs sans les modifier

Utilisez cat ou less sur les petits fichiers descriptor VMDK et notez CID, parentCID et parentFileNameHint. Construisez la chaîne du disque courant vers ses parents jusqu’au base disk. Les valeurs doivent se correspondre. Si le parent indiqué n’existe plus, recherchez d’abord une sauvegarde ou une copie avant toute reconstruction manuelle.

grep -E "^(CID|parentCID|parentFileNameHint)" /vmfs/volumes/<DATASTORE>/<VM-DIR>/<DISK>.vmdk
Résultat attendu
  • La relation parent-enfant est documentée et le premier maillon incohérent est identifié.
6

Valider la chaîne avec vmkfstools

Lancez vmkfstools -e sur le descriptor actuellement attaché. Cette vérification permet de savoir si VMware peut ouvrir la chaîne. Conservez le message exact. Un CID mismatch, parent introuvable ou paramètre invalide doit être rapproché des fichiers réellement présents et des logs avant toute correction.

vmkfstools -e /vmfs/volumes/<DATASTORE>/<VM-DIR>/<CURRENT-DISK>.vmdk
Résultat attendu
  • L’état de cohérence VMware est connu et le message exact est conservé.
7

Analyser vmware.log et les tâches vCenter

Recherchez la première erreur au moment où le problème est apparu : snapshot delete, consolidation, Storage vMotion, datastore plein ou copie manuelle. vmware.log peut préciser le fichier que DISKLIB n’arrive pas à ouvrir. Cette chronologie aide à distinguer un parent réellement manquant d’un descripteur mal aligné.

grep -Ei "DISKLIB|CID|parent|consolidat|snapshot" /vmfs/volumes/<DATASTORE>/<VM-DIR>/vmware.log | tail -n 100
Résultat attendu
  • L’erreur de chaîne est corrélée à une opération ou un fichier précis.
8

Choisir restauration ou clone avant édition manuelle

Si un snapshot indispensable est absent, restaurez une sauvegarde récente dans une nouvelle VM. Si la chaîne est complète mais la consolidation vSphere échoue, un clone supporté peut reconstruire une chaîne propre selon le cas. N’éditez manuellement les descripteurs que sur une copie et lorsque la cause est parfaitement comprise ou avec le support VMware.

Résultat attendu
  • La méthode retenue minimise le risque de corruption des données originales.
9

Consolider ou cloner avec une marge suffisante

Avant une consolidation, vérifiez l’espace libre et les I/O. Une consolidation peut être longue et générer une charge importante. Broadcom recommande de ne pas annuler arbitrairement une consolidation en cours. Surveillez la tâche et conservez les anciens fichiers jusqu’à la fin et à la validation de la VM.

df -h
esxcli storage filesystem list
Résultat attendu
  • La tâche de récupération se termine sans saturation du datastore.
10

Valider la VM récupérée puis refaire une sauvegarde complète

Démarrez la VM récupérée sur un réseau adapté, contrôlez les volumes, services et applications puis vérifiez l’absence de Needs Consolidation. Lancez ensuite une sauvegarde complète et, si possible, un test de restauration. Ne supprimez l’ancienne copie de sécurité qu’après cette validation.

Résultat attendu
  • La VM démarre depuis une chaîne propre et une nouvelle sauvegarde complète réussit.

Validation

La procédure est validée lorsque :

  • vmkfstools peut ouvrir la chaîne de disque finale sans erreur.
  • La VM démarre et ses volumes/applications sont cohérents.
  • vCenter ne signale plus de consolidation nécessaire.
  • Une nouvelle sauvegarde complète et un test de restauration réussissent.

Retour arrière

  • Revenir à la copie intégrale du dossier ou à la sauvegarde si une tentative de récupération échoue.
  • Ne supprimer aucun fichier de snapshot d’origine tant que la nouvelle VM n’est pas validée.
  • Si un clone ne termine pas, arrêter la tentative et préserver source et logs avant de changer de stratégie.

Dépannage / erreurs fréquentes

  • CID mismatch avec tous les fichiers présents : comparer précisément les descriptors ; toute correction manuelle doit se faire sur une copie ou avec support.
  • Numéro de snapshot manquant et fichier réellement absent : privilégier la restauration depuis sauvegarde ; la chaîne peut être irréparable.
  • Consolidation très longue : surveiller l’espace, la latence et les I/O avant de conclure à un blocage.
  • Snapshot Manager vide mais delta présents : utiliser vmkfstools, VMX et logs pour déterminer la chaîne réelle au lieu de supprimer les fichiers.

Références officielles

À consulter : Snapshot Consolidation.

♡ 0