Guide

Comment diagnostiquer VMware CBT

Ce guide montre comment diagnostiquer VMware CBT à partir de vérifications ciblées et d’une validation explicite, sans multiplier les changements inutiles. Un datastore peut se remplir à cause de snapshots, thin provisioning, logs ou croissance invité ; capacité provisionnée et espace réellement consommé diffèrent.

ThématiqueVMware →
⌚ Environ 3 min de lecture
Voir mes favoris
VMware Intermédiaire 15-30 min

Ce guide montre comment diagnostiquer VMware CBT à partir de vérifications ciblées et d’une validation explicite, sans multiplier les changements inutiles. Un datastore peut se remplir à cause de snapshots, thin provisioning, logs ou croissance invité ; capacité provisionnée et espace réellement consommé diffèrent.

Avant de commencer : adaptez toujours les commandes et manipulations à votre environnement. Sur un système de production, prévoyez une sauvegarde ou un retour arrière lorsque l’action peut modifier la configuration.

Étapes à suivre

  1. 1

    Identifier les critères déterminants

    Un datastore peut se remplir à cause de snapshots, thin provisioning, logs ou croissance invité ; capacité provisionnée et espace réellement consommé diffèrent.

  2. 2

    Recouper le contexte technique

    vMotion dépend du VMkernel

  3. 3

    Contrôles ciblés

    Pour vMotion, tester le VMkernel source → destination avec la taille MTU réelle ; pour stockage, identifier les snapshots et fichiers croissants.

  4. 4

    Écarter les erreurs de diagnostic

    Supprimer un snapshot depuis le datastore browser peut casser la chaîne ; utiliser Snapshot Manager/Consolidate.

  5. 5

    Valider le résultat

    Le datastore retrouve une marge et aucun snapshot/consolidation anormal ne persiste. vMotion aboutit avec les VMkernel/MTU attendus et les sauvegardes CBT redeviennent cohérentes.

Commandes utiles

vmkping -I vmkX -d -s 8972 <peer>
esxcli storage filesystem list

À retenir

  • CBT accélère les sauvegardes incrémentales mais une corruption/invalidité doit être traitée selon la procédure de l’outil de sauvegarde, pas en supprimant arbitrairement les fichiers ctk.
  • Une migration qui fonctionne en petit MTU peut encore échouer avec jumbo frames mal alignées.
  • vMotion aboutit avec les VMkernel/MTU attendus et les sauvegardes CBT redeviennent cohérentes.
Complément technique

VMware : stockage, réseau vMotion et CBT doivent être validés par couche

Repères techniques

  • Un datastore peut se remplir à cause de snapshots, thin provisioning, logs ou croissance invité ; capacité provisionnée et espace réellement consommé diffèrent.
  • vMotion dépend du VMkernel, du routage/VLAN, MTU et parfois de la compatibilité CPU/EVC ; le réseau management seul ne suffit pas.
  • CBT accélère les sauvegardes incrémentales mais une corruption/invalidité doit être traitée selon la procédure de l’outil de sauvegarde, pas en supprimant arbitrairement les fichiers ctk.

Contrôles ciblés

Pour vMotion, tester le VMkernel source → destination avec la taille MTU réelle ; pour stockage, identifier les snapshots et fichiers croissants.

vmkping -I vmkX -d -s 8972 <peer>
esxcli storage filesystem list

Pièges spécifiques

  • Supprimer un snapshot depuis le datastore browser peut casser la chaîne ; utiliser Snapshot Manager/Consolidate.
  • Une migration qui fonctionne en petit MTU peut encore échouer avec jumbo frames mal alignées.

Comment valider

  • Le datastore retrouve une marge et aucun snapshot/consolidation anormal ne persiste.
  • vMotion aboutit avec les VMkernel/MTU attendus et les sauvegardes CBT redeviennent cohérentes.

Références de validation

Source primaire : Broadcom Knowledge Base — Changed Block Tracking.

♡ 0