Technologie / Analyses et perspectives pratiques

VM suspendue, datastore plein : ne supprimez pas le VMDK

Récupérer une VM ESXi lorsque le datastore est plein : freiner la croissance, créer de la capacité et préserver la chaîne de snapshots.

ADArdeshir Daryani··3 min de lecture
Schéma conceptuel d’un disque virtuel, d’un manque de capacité et d’une récupération contrôlée
Illustration conceptuelle originale générée par IA ; elle ne représente pas fidèlement un produit commercial ou une architecture réelle.

Situation critique : L’application principale de l’entreprise est indisponible. Dans vCenter, la VM semble toujours allumée, mais affiche There is no more space for virtual disk. Le système invité indique encore de l’espace libre ; cette différence peut détourner le diagnostic.

Délimiter le problème

Ce guide traite du manque de capacité sur un datastore VMFS ou NFS dans ESXi. Panne de disque, verrouillage de fichier et saturation vSAN nécessitent des diagnostics distincts. Relevez le datastore du disque touché, sa capacité libre, les snapshots et la tâche de sauvegarde active. L’espace libre dans l’invité ne prouve pas que la couche de stockage hôte dispose de place.

Empêcher l’aggravation

Arrêtez de créer de nouveaux snapshots et de lancer des tâches non essentielles consommant ce datastore. Si une sauvegarde est en cours, arrêtez-la ou annulez-la selon la procédure du produit ; ne tuez pas aveuglément son processus. Pensez aux autres VM partageant le même stockage.

Ne supprimez pas manuellement les fichiers VMDK, delta ou sesparse dans Datastore Browser. Un snapshot peut appartenir au disque actuellement utilisé. Un petit fichier ou un nom ancien ne prouve pas qu’il soit inutile.

Un chemin de récupération concret

Créez d’abord une capacité réellement utilisable : agrandissez le stockage sous-jacent, puis le datastore, ou déplacez ailleurs des fichiers vérifiés et non attachés, comme un ancien ISO. Avant de supprimer un ISO, vérifiez ses connexions aux VM et son utilité opérationnelle. Storage vMotion peut également être étudié si la destination et l’environnement le permettent ; sa réussite sur un stockage entièrement plein n’est pas garantie.

Une fois une marge suffisante obtenue, relisez le message et utilisez Retry pour cette même erreur de capacité. Si le message change ou si les erreurs I/O persistent, changez de piste. Un Retry réussi ne termine pas l’intervention : trouvez la cause de la croissance.

La suppression ou consolidation des snapshots par les outils de gestion constitue une étape ultérieure planifiée. Elle peut demander de l’espace de travail supplémentaire ; ne la lancez pas sur un datastore entièrement plein. Delete et Revert ne sont pas équivalents : Revert ramène le disque à un état antérieur.

Confirmer le rétablissement

Avec un compte autorisé, effectuez une opération applicative peu intrusive et vérifiez lecture et écriture. Surveillez en parallèle capacité, sauvegardes et erreurs de stockage. Je recommande d’attribuer les alertes de capacité et d’ancienneté des snapshots à un responsable nommé ; une alerte sans propriétaire aide peu la nuit d’un incident.

La décision utile : Créer d’abord de la capacité utilisable, puis gérer la chaîne de disques avec les outils pris en charge. Redémarrer l’hôte ne libère pas la capacité du datastore.

Références techniques: Broadcom / Disk space · Broadcom / Snapshots.

Des analyses technologiques pour éclairer les décisions.Toutes les publications →