VMware vSphere : pic d’espace disque après copie de fichiers — diagnostic, défrag/trim, compactage VMDK (thin provisioning)

Après une copie massive de fichiers vers un VMDK “thin”, votre datastore VMware peut gonfler brutalement. Voici pourquoi cela arrive, comment diagnostiquer la vraie cause, et la méthode pas‑à‑pas pour récupérer l’espace sans risque.

Sommaire

Pic d’espace disque après la copie de fichiers

Le symptôme

Vous transférez environ 200 Go de données (images ISO et gros fichiers) depuis un serveur physique vers une VM hébergée sur vSphere. À l’intérieur de Windows tout a l’air cohérent, mais le datastore VMware grimpe de ~200 Go à ~320 Go utilisés, frôlant la saturation.

	Ancien serveur	Nouveau serveur (VM)
Taille	202 Go	202 Go
Taille sur le disque	202 Go	169 Go

Pourtant, côté vSphere, le volume passe presque à saturation (ex. : 320 Go utilisés sur 400 Go).

Pourquoi le datastore grossit‑il plus que les chiffres Windows ?

“Taille” vs “Taille sur le disque” dans Windows

Taille : poids logique de la somme des fichiers.
Taille sur le disque : blocs réellement alloués dans le système de fichiers de l’invité (NTFS), après effets du cluster, de la compression NTFS, de la déduplication et/ou des fichiers clairsemés (sparse).

Ces valeurs décrivent l’intérieur de l’OS invité. Elles ne reflètent pas la place occupée par le .vmdk sur le datastore. Un VMDK “thin” s’agrandit lorsqu’il reçoit des écritures sur des blocs qu’il n’a jamais alloués auparavant, indépendamment de ce qu’NTFS fera plus tard (suppression, compression, etc.).

Thin provisioning et écritures éparses

Un VMDK “thin” alloue des segments (grains) à la première écriture. Lors d’une grosse copie réalisée par glisser‑déposer via un partage réseau, les blocs écrits peuvent arriver dans le désordre ou en multiples flux parallèles. Le résultat :

Beaucoup de segments alloués sur le VMDK, parfois non contigus.
Des “trous” logiques apparaissent quand Windows supprime/déplace/compresse : l’espace redevient libre dans Windows, mais le VMDK est déjà gonflé et ne rétrécira pas tout seul.

Fragmentation interne du VMDK

Même si NTFS reste peu fragmenté, la granularité d’allocation d’un disque thin peut provoquer une fragmentation interne. Plus le nombre d’écritures dispersées est élevé, plus le VMDK grossit, parfois au‑delà de la somme logique des fichiers visibles dans l’invité.

Compression, déduplication et fichiers “sparse” dans l’invité

Si la compression NTFS ou la déduplication est activée, Windows peut rapporter une “Taille sur le disque” inférieure à la “Taille”. C’est normal côté OS, mais cela n’empêche pas la croissance du VMDK, puisque l’hyperviseur a déjà dû allouer des blocs pour satisfaire les écritures initiales. Les fichiers “sparse” (certains formats de bases ou images disque) accentuent aussi ce décalage entre vue invité et vue datastore.

Autres contributeurs souvent oubliés

Élément	Impact sur l’espace datastore	Où vérifier	Remarque
Snapshots (`-0000x.vmdk`)	Peuvent grossir très vite pendant la copie	Gestion des snapshots de la VM	Consolider/supprimer après l’opération
Fichier de swap de la VM (`.vswp`)	≈ Mémoire allouée – réserve	Dossier de la VM sur le datastore	Existe seulement VM allumée; varie avec la réservation
Fichiers log/CBT	Faible à moyen	Dossier de la VM	Augmente en présence de sauvegardes/CBT
Overhead VMFS/vSAN	Faible	Datastore	Incompressible; à prendre en compte

Diagnostic avancé et vérifications utiles

1) Vérifier les vrais occupants de l’espace dans l’invité

Lancer un inventaire en mode Système pour éviter les dossiers protégés :
psexec -s -i cmd.exe "C:\Program Files\JAM Software\TreeSize Free\TreeSizeFree.exe" (Ou tout autre outil d’inventaire compatible.)
Contrôler compression NTFS et déduplication (si rôle installé).
Vérifier la fragmentation NTFS : defrag C: /A /U /V

2) Audit côté hyperviseur

Comparer Provisioned Space vs Used Space de chaque disque dans l’interface vSphere.
Reporter les disques durs d’une VM en PowerCLI : Get-VM -Name "MaVM" | Get-HardDisk | Select Parent,FileName,CapacityGB,StorageFormat,Persistence
Lister la taille réelle sur le datastore (ESXi) : ls -lh /vmfs/volumes/<datastore>/<VM>/ du -h /vmfs/volumes/<datastore>/<VM>/
Contrôler la présence de snapshots et leur taille cumulée.

3) Écarter les “faux‑positifs”

Pas de dossiers cachés anormaux : l’inventaire TreeSize en session Système permet d’exclure les fichiers fantômes.
Pas de processus de sauvegarde en cours maintenant (qui maintiendrait un snapshot ouvert).
Vérifier que la VM n’a pas copié de gros fichiers temporaires (.tmp) toujours ouverts.

Solution éprouvée : récupérer l’espace du VMDK

La remédiation combine défragmentation logique (NTFS), TRIM/UNMAP dans l’invité, puis compactage du VMDK. Suivez l’ordre :

Consolider/supprimer les snapshots avant toute chose (et idéalement après la copie). Attendez la fin complète.
Défragmenter NTFS pour regrouper les fichiers et maximiser les zones vides contiguës : defrag C: /U /V # alternative PowerShell Optimize-Volume -DriveLetter C -Defrag -Verbose
Envoyer un TRIM (ReTrim) depuis Windows pour annoncer les blocs libres au dessous : Optimize-Volume -DriveLetter C -ReTrim -Verbose Si la version/stack ne relaie pas correctement TRIM, une alternative consiste à “zéro‑remplir” l’espace libre avant le compactage (ex. : sdelete -z C:). Attention : cette méthode écrit temporairement beaucoup de données.
Compacter le VMDK (punch‑zero) côté ESXi pour rendre les blocs inutilisés au datastore : # VM éteinte recommandé pour accélérer et éviter les conflits vmkfstools -K /vmfs/volumes/<datastore>/<VM>/<disque.vmdk> Sur vSphere Client : Edit Settings → Virtual Disk → Compact (selon l’édition).
Restituer l’espace au stockage (si votre datastore lui‑même est thin au niveau SAN/vSAN) : # Lancer une campagne d'UNMAP VMFS si nécessaire esxcli storage vmfs unmap -l <NomDuDatastore>

Après ces étapes, la taille physique du .vmdk revient proche de la valeur attendue (~200 Go dans l’exemple), libérant immédiatement de l’espace.

Bonnes pratiques pour éviter la récidive

Action préventive	Pourquoi ?	Outils / Commandes	Conseils d’exploitation
Choisir thick quand l’espace est prévisible	Pas de croissance imprévue, performance stable	Sélection du format disque à la création	Eager‑zeroed pour workloads sensibles à la latence
Limiter le glisser‑déposer pour les gros transferts	Réduit les écritures éparses	`robocopy \\src \\dst /E /R:0 /W:0 /J /MT:4 /COPY:DAT /DCOPY:T`	`/J` (I/O non mis en cache), `/MT:4` modéré pour préserver la séquentialité
Planifier des défragmentations périodiques	Moins d’allocation dispersée dans le VMDK	`defrag C: /U /V Optimize-Volume -DriveLetter C -Defrag`	Mensuel ou après des opérations massives
Compactage régulier des VMDK	Récupère l’espace libéré dans l’OS invité	vSphere : “Compact”, ESXi : `vmkfstools -K`	Toujours après un ReTrim (ou `sdelete -z`)
Surveiller la croissance	Alerte précoce avant saturation	`Get-VM \| Get-HardDisk \| Select Parent,FileName,CapacityGB,StorageFormat \| Sort-Object Parent \| Format-Table -Auto`	Créer des alertes vCenter sur “Used vs Provisioned”
Nettoyer les snapshots rapidement	Évite les delta qui enflent	“Consolidate/Remove Snapshots”	Jamais de snapshot “longue durée”
Propager UNMAP jusqu’au SAN	Libère l’espace physiquement	`esxcli storage vmfs unmap`	Utile sur datastores thin ou vSAN

Checklist rapide avant d’agrandir un datastore

J’ai supprimé/consolidé tous les snapshots récents.
J’ai calculé l’espace total provisionné vs utilisé pour la VM cible.
J’ai choisi un mode de copie séquentiel (Robocopy avec /J et /MT modéré).
Je prévois un ReTrim + compactage après l’opération.
Je tiens compte du .vswp (mémoire non réservée).

FAQ

Pourquoi “Taille sur le disque” peut être inférieure à “Taille” dans l’invité ?

Compression NTFS, déduplication ou fichiers sparse. C’est bénéfique pour l’OS mais sans effet immédiat sur la taille physique du VMDK déjà alloué.

Un VMDK “thin” peut‑il rétrécir automatiquement ?

Non. Un disque thin grossit à la demande, mais pour récupérer l’espace il faut une action explicite (TRIM/ReTrim dans l’invité, puis compactage/punch‑zero côté hyperviseur).

Faut‑il éteindre la VM pour compacter ?

Selon les versions et outils, le compactage peut nécessiter une VM éteinte pour aller plus vite et éviter les fichiers en mouvement. En pratique, programmez l’opération lors d’un créneau de maintenance pour minimiser les risques.

Les gros fichiers ISO aggravent-ils le problème ?

Ils ne sont pas spéciaux en soi, mais un transfert multi‑flux ou une copie répétée/supprimée crée des écritures éparses qui allouent beaucoup de grains thin. Le résultat est un VMDK plus gros que la somme logique des fichiers.

Je vois 320 Go utilisés sur le datastore alors que Windows annonce 169 Go “sur le disque”. Qui croire ?

Ce sont deux vues différentes. Le datastore montre l’espace réellement occupé par les fichiers de la VM (VMDK, snapshots, logs, swap). Windows ne voit que l’intérieur de son système de fichiers. Pour libérer l’écart, appliquez la séquence Défrag → ReTrim → Compact.

Procédure complète (pas‑à‑pas reproductible)

Stabiliser l’environnement
- Mettre en pause les sauvegardes de la VM et supprimer/consolider les snapshots existants.
- Vérifier l’espace libre résiduel du datastore et prévoir une marge (≥ 20 % recommandé).
Défragmenter l’invité defrag C: /U /V Optimize-Volume -DriveLetter C -Defrag -Verbose
Informer le dessous des blocs libres (TRIM) Optimize-Volume -DriveLetter C -ReTrim -Verbose Alternative si TRIM non supporté de bout en bout : sdelete -z C:
Compacter le VMDK vmkfstools -K /vmfs/volumes/<Datastore>/<VM>/<Disque.vmdk>
Restituer au stockage (si datastore thin/vSAN) esxcli storage vmfs unmap -l <Datastore>
Vérifier et consigner
- Comparer la taille Used du VMDK avant/après.
- Archiver les captures (vSphere, PowerCLI) pour capitaliser.

Commandes d’observation et de reporting

Lister la croissance des disques d’une ferme de VMs

# Disques par VM avec tailles et format
Get-VM | Get-HardDisk |
  Select @{N="VM";E={$_.Parent.Name}},
         @{N="VMDK";E={$_.FileName}},
         CapacityGB, StorageFormat |
  Sort-Object VM | Format-Table -Auto

Comparer “Provisioned” vs “Used” d’un datastore

Get-Datastore |
  Select Name, CapacityGB, FreeSpaceGB,
         @{N="UsedGB";E={"{0:N1}" -f (($_.CapacityGB - $_.FreeSpaceGB))}}

Trouver les snapshots oubliés (dangereux pour l’espace)

Get-VM | Get-Snapshot |
  Select VM, Name, Created, SizeGB |
  Sort-Object SizeGB -Descending

Points d’attention et limites

VMDK thin : croissance irréversible sans action. L’allocation s’accumule jusqu’à compactage.
Fragmentation et “trous” logiques : si les blocs libres sont très morcelés, le compactage récupèrera moins d’espace. D’où l’importance de défragmenter avant.
Stack complet TRIM/UNMAP : l’efficacité dépend que le TRIM invité soit bien propagé (matériel & version). Sinon, utilisez la stratégie “zéro puis compact”.
Temps d’exécution : défrag, ReTrim et compactage peuvent durer. Planifiez des fenêtres adaptées.
Performance : multiplier les copies parallèles augmente les écritures éparses. Privilégiez la séquentialité pour les gros volumes.

Exemple réaliste et résultat

Contexte : après avoir transféré ~200 Go d’ISO depuis un serveur physique, la VM présentait 202 Go de “Taille”, 169 Go “sur le disque”, mais le datastore affichait 320 Go utilisés (snapshots inclus). Après défrag + ReTrim dans Windows, puis vmkfstools -K sur le VMDK et un vmfs unmap au niveau du datastore, la taille physique du VMDK est revenue au voisinage des 200 Go, rendant plus de 100 Go au datastore.

Modèle d’operating playbook interne

Avant la copie : vérifier snapshots, swap, espace libre, choisir Robocopy.
Pendant la copie : surveiller la file d’attente disque et la croissance du VMDK.
Après la copie : consolidation snapshots, défrag, ReTrim, compactage, UNMAP, validation.
En continu : tableau de bord vCenter + rapport hebdo PowerCLI.

Modèles de commandes “copie propre”

Copie réseau moins fragmentante (séquentielle, journaux, reprise sur erreur désactivée) :

robocopy \\srv-source\share D:\cible /E /R:0 /W:0 /J /MT:4 /NFL /NDL /NP /LOG+:C:\Logs\copy.log
# /J : I/O non mis en cache (réduit l'impact mémoire)
# /MT:4 : multi-thread modéré, typiquement plus séquentiel que /MT:64 par défaut

Conclusion

Le “mystère” d’un datastore qui grossit plus que la somme des fichiers visibles dans Windows provient du fonctionnement même des VMDK thin et des écritures éparses. La recette fiable est toujours la même : défragmenter pour rassembler, ReTrim pour informer la couche inférieure, puis compacter pour récupérer réellement l’espace. En industrialisant ce cycle et en adoptant des habitudes de copie plus séquentielles, vous évitez les alertes de saturation et maintenez vos datastores sous contrôle.

Récapitulatif des bonnes pratiques (mémo)

Disques thick quand l’espace est stable/prévisible, thin sinon mais avec surveillance.
Éviter les copies multi‑flux agressives pour des lots géants : préférer Robocopy avec /J et un /MT modéré.
Planifier défrag → ReTrim → compact après toute ingestion massive de données.
Supprimer les snapshots dès que possible, jamais en “longue durée”.
Automatiser le reporting PowerCLI et les alertes vCenter (usage, tendance de croissance).