Objectif
Identifier pourquoi une réplication ou un job de protection considère qu’un disque VMDK source a une capacité inférieure à celle attendue, sans agrandir ou éditer aveuglément les fichiers de disque, puis choisir entre correction de configuration, consolidation supportée ou recréation de la base de réplication.
- Ne modifiez pas la capacité d’un VMDK ou son descripteur pour faire disparaître le message sans avoir identifié le disque source de référence et la chaîne de snapshots.
- Ne supprimez aucun fichier -flat, -delta, -sesparse ou descriptor directement depuis le datastore browser pendant l’analyse.
- Une réplication peut comparer la source actuelle à une cible plus ancienne créée avant une restauration, un remplacement de disque ou une modification de topologie. Vérifiez l’historique avant de conclure à une corruption.
- Si des fichiers de snapshot sont manquants ou si la chaîne est incohérente, privilégiez restauration, clone supporté ou support éditeur avant toute édition manuelle de CID/parentCID.
Prérequis
- Nom de la VM, disque concerné et message exact du logiciel de réplication ou de sauvegarde.
- Accès vCenter/ESXi et au produit de réplication concerné.
- Sauvegarde récente et validée de la VM avant toute modification de stockage.
- Historique des restaurations, Storage vMotion, changements de taille et remplacements de disque récents.
- Espace libre suffisant sur le datastore source et la cible de réplication.
Procédure pas à pas
Suspendre le job et geler les changements de stockage
Arrêtez temporairement les tentatives automatiques de réplication afin d’éviter qu’un job en échec ne modifie encore la cible. Ne redimensionnez pas le disque, ne créez pas de snapshot et n’effectuez pas de Storage vMotion pendant la collecte. Notez l’heure de suspension et le dernier restore point valide.
- L’état source et cible reste stable pendant l’analyse.
Identifier précisément le disque signalé
Dans vCenter, relevez la capacité de chaque disque virtuel, son datastore et le fichier VMDK associé. Comparez ces informations au journal du job afin de confirmer qu’il s’agit du même disque. Une VM peut avoir plusieurs VMDK de tailles proches ; corriger le mauvais disque est plus dangereux que l’erreur initiale.
- Le disque source, son contrôleur et son fichier sont identifiés sans ambiguïté.
Comparer la capacité logique côté vSphere et côté réplication
Vérifiez la taille déclarée dans la configuration de la VM et la taille connue par la cible de réplication. Recherchez un scénario où le disque source a été remplacé par un disque plus petit, restauré depuis une sauvegarde antérieure ou recréé. Une solution de réplication peut refuser de continuer une chaîne incrémentale si sa base correspond à une géométrie différente.
vim-cmd vmsvc/getallvmsvmkfstools -P "<DATASTORE-PATH>"- La différence de capacité est soit confirmée et expliquée, soit exclue.
Inventorier les snapshots et les fichiers associés
Consultez Snapshot Manager puis listez les fichiers du dossier de la VM. La présence de snapshots anciens, de fichiers delta orphelins ou d’une consolidation nécessaire peut modifier la façon dont le produit de réplication voit le disque. Ne vous fiez pas uniquement à l’interface : comparez également les fichiers présents et la configuration VMX.
ls -lah /vmfs/volumes/<DATASTORE>/<VM-DIR>/grep -E "fileName|scsi|sata|nvme" /vmfs/volumes/<DATASTORE>/<VM-DIR>/<VM>.vmx- La chaîne de fichiers attendue est cartographiée avant toute action.
Vérifier la cohérence de la chaîne VMDK
Utilisez les outils VMware en lecture pour vérifier si la chaîne est ouvrable. vmkfstools -e peut signaler une chaîne cassée. Si un CID mismatch ou un parent absent apparaît, ne corrigez pas le descripteur à partir d’une simple supposition. Broadcom documente certains cas de CID/parentCID, mais une restauration depuis une sauvegarde récente reste préférable lorsque des fichiers parents sont réellement manquants.
vmkfstools -e /vmfs/volumes/<DATASTORE>/<VM-DIR>/<CURRENT-DISK>.vmdk- La chaîne est déclarée cohérente ou l’erreur exacte de chaîne est connue.
Contrôler l’espace et l’état du datastore
Un datastore saturé ou un incident de stockage peut avoir interrompu une consolidation ou une copie et laissé une base incohérente. Vérifiez capacité, alarmes, erreurs d’I/O et événements autour de l’heure du changement. Créez une marge suffisante avant toute consolidation ou clone.
df -hesxcli storage filesystem list- Le stockage possède une marge suffisante et aucune erreur majeure n’est ignorée.
Choisir la correction la moins destructive
Si la source est saine mais que la cible de réplication correspond à une ancienne géométrie, le plus sûr est souvent de créer une nouvelle base complète ou une nouvelle réplique plutôt que de forcer la continuation incrémentale. Si la source a une chaîne de snapshots valide mais nécessite consolidation, utilisez les fonctions vSphere supportées après avoir créé de la marge. Ne mélangez pas correction source et recréation cible dans la même étape.
- Une seule stratégie de correction est retenue avec un retour arrière clair.
Recréer la base de réplication si nécessaire
Conservez l’ancienne réplique jusqu’à validation de la nouvelle. Créez un nouveau full, reseed ou job selon le produit de protection et sa documentation. Évitez de mapper manuellement une ancienne cible dont la géométrie diffère. Surveillez la première synchronisation complète jusqu’à la fin.
- Le nouveau job construit une cible cohérente sans message de capacité réduite.
Tester un démarrage isolé de la réplique ou restauration
Dans un réseau isolé, démarrez la nouvelle réplique ou restaurez la VM afin de confirmer que les disques, partitions et applications sont lisibles. Vérifiez la capacité depuis l’OS invité et l’intégrité des services. Une simple session de réplication réussie n’est pas suffisante si la cible ne démarre pas.
- La VM de test démarre et le disque concerné présente la capacité attendue.
Documenter la cause et prévenir la récidive
Conservez l’événement qui a changé la géométrie : restauration, remplacement de VMDK, shrink, clone ou mauvaise cible. Ajoutez une règle d’exploitation exigeant la recréation ou le contrôle de la réplication après tout changement de disque. Supprimez l’ancienne chaîne seulement après validation complète.
- L’incident est relié à une cause ou une hypothèse documentée et la nouvelle base est protégée.
Validation
La procédure est validée lorsque :
- La capacité source correspond à la configuration vSphere et à la nouvelle cible de réplication.
- vmkfstools ne signale pas de chaîne VMDK incohérente sur le disque utilisé.
- Le job de réplication repart sur une base complète sans erreur de capacité.
- Un test de démarrage ou restauration isolée valide la VM et le disque.
Retour arrière
- Conserver l’ancienne réplique ou sauvegarde jusqu’à validation de la nouvelle base.
- Si une consolidation ou un clone échoue, ne supprimez aucun fichier et revenez au dernier état stable avant nouvelle tentative.
- Réactiver l’ancien job uniquement si sa source et sa cible correspondent encore et qu’il était fonctionnel avant le changement.
Dépannage / erreurs fréquentes
- Erreur apparaît après restauration d’une VM : comparer la géométrie du disque restauré à celle de la cible de réplication et recréer la base si nécessaire.
- vmkfstools -e signale une chaîne cassée : arrêter les écritures et traiter la chaîne avant toute reprise de réplication.
- Datastore presque plein : libérer ou étendre la capacité avant consolidation ou clone.
- La cible est saine mais le produit continue de comparer une ancienne base : supprimer/recréer proprement le mapping ou le job selon la documentation de l’éditeur.
Références officielles
- Broadcom KB — CID mismatch during disk consolidation
- Broadcom KB — Snapshot chain missing disk / parent modified
Adaptez les noms, adresses, chemins et paramètres à votre environnement. Sauvegardez la configuration et testez d’abord sur un périmètre limité.