Contexte

Environnement de production VMware vSphere. Une nouvelle VM est créée et on lui rattache un disque virtuel provenant d’une ancienne VM — pour récupérer des données ou réutiliser un volume existant. Suite à cette opération et à une extension de la taille du disque, la VM refuse de démarrer.

Symptômes

Depuis vSphere Client, au démarrage de la VM :

  • La VM reste bloquée à l’état “Starting”
  • Erreur dans les événements vSphere :
  Cannot open the disk 'datastore/NouvelleVM/disque.vmdk' or one of
  the snapshot disks it depends on.
  Reason: The parent virtual disk has been modified since the child
  was created.
  • Impossible de monter le disque
  • La VM ne démarre pas

Cause racine

Un disque VMware contient dans son descriptor .vmdk deux identifiants critiques :

1
2

CID=a1b2c3d4          ← Content ID du disque (change à chaque écriture)
parentCID=ffffffff    ← ID du disque parent (ffffffff = pas de parent)

Quand un disque est détaché d’une ancienne VM puis rattaché à une nouvelle, VMware peut créer un nouveau descriptor qui référence l’ancien comme parent — créant une chaîne de dépendance fantôme. Si en plus le disque a été étendu, l’index de taille en secteurs dans le descriptor devient incohérent avec la taille réelle du fichier -flat.vmdk.

Le résultat : VMware considère le disque comme corrompu ou invalide et refuse de démarrer la VM.

Diagnostic

Étape 1 — Accéder au datastore via SSH

1
2
3
4
5
6
7
8

# Connexion SSH sur l'hôte ESXi
ssh root@ip-esxi

# Aller dans le dossier de la nouvelle VM
cd /vmfs/volumes/datastore/NouvelleVM/

# Lister les fichiers
ls -lh

On doit voir deux fichiers pour le disque rattaché :

1
2

disque.vmdk          ← descriptor (fichier texte)
disque-flat.vmdk     ← données brutes

Étape 2 — Lire le descriptor

1

cat disque.vmdk

Exemple de contenu problématique :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=a1b2c3d4
parentCID=e5f6a7b8      ← référence l'ancienne VM !
createType="vmfs"

# Extent description
RW 41943040 VMFS "disque-flat.vmdk"    ← taille potentiellement incorrecte

ddb.uuid = "xx xx xx xx xx xx xx xx-xx xx xx xx xx xx xx xx"

Deux problèmes visibles :

  • parentCID=e5f6a7b8 — le disque pense dépendre d’un parent qui n’existe plus
  • RW 41943040 — la taille en secteurs peut être incorrecte si le disque a été étendu

Étape 3 — Vérifier la taille réelle du flat

1
2
3
4
5

# Taille réelle en octets
ls -l disque-flat.vmdk

# Calculer la taille correcte en secteurs
# Exemple : 85899345920 octets / 512 = 167772160 secteurs

Résolution

Corriger le descriptor manuellement

1

vi disque.vmdk

Apporter les corrections suivantes :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

# 1. Couper la dépendance avec l'ancienne VM
parentCID=ffffffff     ← ffffffff = disque indépendant, pas de parent

# 2. Corriger la taille en secteurs si nécessaire
# Avant :
RW 41943040 VMFS "disque-flat.vmdk"
# Après (taille réelle du flat divisée par 512) :
RW 167772160 VMFS "disque-flat.vmdk"

# 3. Corriger la géométrie si la taille a changé
ddb.geometry.cylinders = "20886"   ← secteurs / (255 × 63)
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"

Calcul des cylindres :

1

cylinders = 167772160 / (255 × 63) = 10443  (arrondi à l'entier)

Valider le descriptor

1
2

# Vérifier que VMware accepte le disque corrigé
vmkfstools -v 10 -t 0 disque.vmdk

Aucune erreur = le descriptor est valide.

Démarrer la VM

Depuis vSphere Client, démarrer la VM. Elle doit passer en “Running” immédiatement.

Vérification post-incident

Une fois la VM démarrée, vérifier que le système d’exploitation voit bien la bonne taille de disque :

Linux :

1
2
3
4
5
6

lsblk
df -h

# Si la partition n'a pas été étendue automatiquement
growpart /dev/sda 1
resize2fs /dev/sda1

Windows :

Gestion des disques → clic droit sur le volume → Étendre le volume

Leçons retenues

Ne jamais réutiliser un disque d’une ancienne VM directement — toujours cloner le disque proprement via vmkfstools plutôt que de le rattacher tel quel :

1
2
3

# Cloner proprement un disque existant (crée un nouveau descriptor sans parentCID)
vmkfstools -i /vmfs/volumes/datastore/AncienneVM/disque.vmdk \
           /vmfs/volumes/datastore/NouvelleVM/disque-clone.vmdk

Cette commande génère un nouveau descriptor propre, sans référence à l’ancienne VM, et avec la bonne taille.

Étendre un disque avant de le rattacher — étendre le disque pendant qu’il est encore attaché à l’ancienne VM (ou via vmkfstools hors ligne) évite les incohérences de descriptor.

Toujours valider avec vmkfstools avant de démarrer — un simple vmkfstools -t 0 disque.vmdk prend 5 secondes et évite un incident.

Conclusion

Un disque VMware réutilisé d’une ancienne VM embarque avec lui son historique — CID, parentCID, UUID, taille indexée. Rattacher ce disque à une nouvelle VM sans nettoyer le descriptor crée des incohérences que VMware refuse de tolérer au démarrage.

La résolution est chirurgicale : deux lignes à corriger dans un fichier texte. Mais encore faut-il savoir où regarder — et comprendre que le .vmdk descriptor n’est pas un fichier binaire opaque mais un fichier texte lisible et modifiable directement.

C’est ce type de connaissance bas niveau qui fait la différence entre un incident résolu en 45 minutes et une VM restée éteinte pendant des heures.