2026 : pourquoi l’espace n’augmente-t-il pas après l’extension du disque d’une machine virtuelle Proxmox VE 9.2 ?

Le communiqué officiel indique que Proxmox VE 9.2 a été publié le 21 mai 2026 (annonce de version de Proxmox). Cette date situe la version, mais ne prouve pas à elle seule le comportement d’un disque donné : après l’extension du disque d’une machine virtuelle Proxmox VE 9.2, l’espace ne devient pas automatiquement disponible dans le système invité. Cette semaine, vérifiez d’abord la marge du stockage hôte, puis suivez la capacité du disque jusqu’à la partition et au système de fichiers ; ne relancez pas une extension avant d’avoir localisé le niveau qui bloque.

Cet article s’adresse aux administrateurs d’un hôte Proxmox VE 9.2 qui voient une capacité inchangée après une extension.
Il concerne aussi les équipes MSP qui intègrent les opérations de stockage à leur processus de changement.
Les petites équipes informatiques qui veulent agrandir une VM sans la reconstruire y trouveront une méthode de diagnostic et des conditions d’arrêt.

La chaîne de capacité, du stockage hôte au système invité

Une capacité affichée dans l’interface de Proxmox ne signifie pas nécessairement que l’espace est disponible dans un répertoire Linux ou dans un volume Windows. Il faut distinguer quatre niveaux : le stockage de l’hôte, le disque virtuel attribué à la VM, les partitions ou volumes logiques du système invité, puis son système de fichiers. La documentation de gestion de Proxmox VE décrit les stockages et leurs usages ; elle constitue le point de départ pour vérifier où réside le disque virtuel.

Pour commencer, utilisez les contrôles en lecture seule. Sur l’hôte, pvesm status donne un aperçu des stockages enregistrés et de leur capacité disponible. Selon le type de stockage, vérifiez aussi l’outil correspondant : par exemple, l’espace d’un système de fichiers ou l’état d’un pool ZFS. Dans la VM Linux, lsblk montre les disques et partitions, findmnt les systèmes de fichiers montés et df -h l’espace reconnu par ceux-ci. Ces commandes ne sont pas interchangeables : df -h ne décrit pas à lui seul la taille brute du disque.

Cette comparaison évite deux erreurs fréquentes. D’abord, demander davantage d’espace à la VM alors que le stockage hôte est déjà plein. Ensuite, confondre l’espace non alloué dans la partition avec l’espace libre disponible pour une application. Une extension de disque peut avoir réussi au premier niveau et rester inachevée aux suivants.

Le disque virtuel et la VM ciblée

Avant d’intervenir, vérifiez l’identifiant de la VM, le disque concerné et son emplacement dans la configuration. Une extension appliquée au mauvais identifiant ou au mauvais périphérique peut modifier une autre machine ou un autre disque. Sur l’hôte, qm config <VMID> permet de consulter la configuration de la machine virtuelle. Comparez-y le nom du disque avec celui de l’opération prévue, puis vérifiez l’état du stockage auquel il est rattaché.

La commande qm resize agit sur le disque virtuel : elle ne redimensionne pas à elle seule les partitions ni les systèmes de fichiers du système invité. La référence officielle de la commande qm documente sa syntaxe et ses paramètres. Une taille relative telle que +10G peut illustrer une demande d’augmentation ; ce n’est pas une recommandation de capacité. Choisissez une valeur à partir des besoins et de la marge réellement disponibles, et confirmez la syntaxe adaptée à votre installation avant de l’exécuter.

Si Proxmox indique une taille supérieure, mais que l’invité ne détecte pas la nouvelle capacité, ne passez pas immédiatement à la modification des partitions. Vérifiez d’abord que vous examinez le bon disque dans la bonne VM, que l’opération s’est terminée et que le système invité a actualisé son inventaire matériel. Si l’écart persiste, arrêtez-vous et consultez la documentation correspondant à la version et au système invité : un redémarrage ou une rescan peut dépendre du contexte, et il ne faut pas le présenter comme une garantie générale.

Partition, LVM et système de fichiers

Lorsque le système invité voit un disque plus grand, lsblk aide à comparer la capacité du disque à celle de chaque partition. Un écart entre les deux signale que l’espace ajouté n’est pas encore attribué à une partition. Avant de modifier la table de partitions, sauvegardez les données et vérifiez que vous savez restaurer la VM ou son disque. Le placement de l’espace non alloué compte : s’il ne jouxte pas la partition concernée, une extension directe peut ne pas être possible.

Pour une VM Linux, le chemin dépend ensuite de la disposition. Avec une partition simple, la partition doit d’abord être étendue selon un outil et une procédure compatibles avec la table de partitions utilisée. Il faut ensuite agrandir le système de fichiers correspondant. Pour ext4, la page de manuel de resize2fs précise les conditions d’emploi ; elle ne remplace pas l’identification préalable du périphérique correct. Ne lancez pas cette commande sur un volume choisi au hasard et ne supposez pas que le nom du périphérique sera identique d’une VM à l’autre.

Avec LVM, plusieurs étapes peuvent séparer le disque du système de fichiers : partition, volume physique, groupe de volumes, volume logique, puis système de fichiers. Le guide de gestion des volumes logiques publié par Red Hat détaille les commandes et les prérequis LVM. Après l’extension de la partition qui porte le volume physique, pvresize peut être requis ; il faut ensuite vérifier l’espace libre du groupe de volumes et décider si le volume logique concerné doit être agrandi. La commande et le chemin du périphérique dépendent de votre configuration réelle.

Le système de fichiers vient ensuite, pas avant. Pour ext4, consultez les conditions de resize2fs. Pour XFS, l’outil xfs_growfs agit sur un système de fichiers monté ; sa page de manuel précise les paramètres pertinents. Le fait qu’une opération soit réalisable en ligne dans certaines conditions ne signifie pas qu’elle soit sans risque pour toutes les configurations. Vérifiez le point de montage, le type du système de fichiers et les conditions propres à votre VM.

Sous Windows, la capacité du disque détectée ne garantit pas que le volume ait été agrandi. Dans la Gestion des disques, vérifiez la présence d’un espace non alloué adjacent au volume concerné et les éventuelles limites liées à la disposition des partitions. La documentation Microsoft sur l’extension d’un volume de base décrit ces conditions. Si l’espace requis n’est pas disponible à côté du volume, ne supprimez pas une partition pour « faire de la place » sans plan de sauvegarde et de restauration validé.

Avant une modification de partition : sauvegardez la VM, vérifiez que la sauvegarde est exploitable et prévoyez une fenêtre de maintenance adaptée. Si vous ne pouvez pas confirmer le disque visé, la disposition du stockage ou le chemin de retour arrière, suspendez l’opération.

Les décisions selon les symptômes observés

Appliquez ces branches après avoir recueilli les informations en lecture seule :

• Si le stockage hôte est proche de sa limite, n’augmentez pas le disque virtuel. Vérifiez l’occupation et la marge du stockage concerné, puis réévaluez la capacité globale avant de modifier la VM.
• Si la configuration de la VM affiche la nouvelle taille, mais pas le système invité, confirmez l’ID de la VM, le périphérique examiné et la détection du disque. N’effectuez pas de changement de partition tant que l’invité ne reconnaît pas la taille attendue.
• Si le disque invité est plus grand que ses partitions, identifiez la partition qui doit bénéficier de l’espace et vérifiez la position de l’espace non alloué. Si vous ne pouvez pas confirmer qu’il est utilisable par cette partition, arrêtez-vous.
• Si la partition est déjà agrandie, mais que l’espace disponible n’a pas changé, déterminez si la couche suivante est LVM ou un système de fichiers direct. Consultez la procédure propre au type observé plutôt que d’appliquer une suite de commandes générique.
• Si la VM est sous Windows, vérifiez la disposition dans Gestion des disques et la contiguïté de l’espace non alloué avant d’utiliser l’action d’extension.
• Si une sauvegarde restaurable, la marge de stockage ou la procédure de retour arrière manque, reportez le changement. Une capacité supplémentaire ne justifie pas un risque de perte de données mal maîtrisé.

Cette logique distingue aussi une demande de capacité à l’échelle d’une VM d’un problème de capacité de l’hôte. La première peut justifier une extension du disque virtuel. Le second exige d’abord une révision du stockage disponible pour l’ensemble des machines, notamment si plusieurs VM partagent le même espace.

Questions fréquentes sur l’espace qui n’apparaît pas

Pourquoi df ne montre-t-il pas l’espace ajouté ?

df affiche l’espace reconnu par les systèmes de fichiers montés, pas la taille brute du disque virtuel. Si le disque a grandi, mais pas la partition, le volume logique ou le système de fichiers, df peut donc rester inchangé. Comparez df -h à lsblk et findmnt ; le premier niveau dont la taille n’a pas suivi indique où poursuivre le diagnostic.

Que faut-il encore faire dans Linux après l’extension du disque ?

Il n’existe pas une opération unique valable pour toutes les VM. Vérifiez d’abord la taille du disque, puis l’état de la partition. Avec LVM, examinez aussi le volume physique et l’espace libre du groupe de volumes ; enfin, adaptez l’extension du système de fichiers à ext4, XFS ou au type réellement utilisé. Consultez la documentation appropriée avant chaque modification.

Comment savoir si le blocage vient de la partition ou du système de fichiers ?

Comparez la capacité du disque et des partitions avec lsblk, puis confrontez ces informations aux points de montage de findmnt et à la capacité utilisable de df -h. Une partition plus petite que le disque signale de l’espace encore hors partition. Si partition et disque ont la taille attendue, mais que df ne suit pas, recherchez une étape LVM manquante ou un système de fichiers non agrandi.

Quelles vérifications faire avant d’agrandir une VM ?

Confirmez le stockage hôte et sa marge, l’identité de la VM, le disque concerné et la disposition interne du système invité. Assurez-vous qu’une sauvegarde peut être restaurée et que vous avez défini une procédure de retour arrière. En cas de stockage presque plein, de volume inconnu ou de sauvegarde non vérifiée, reportez l’intervention : augmenter un disque virtuel ne résout pas un manque d’espace sur l’hôte.

La vérification après changement

À la fin, contrôlez séparément chaque niveau. Sur l’hôte, assurez-vous que le stockage conserve une marge cohérente avec l’usage prévu. Dans la configuration de la VM, confirmez la taille du disque virtuel. Dans Linux, comparez à nouveau lsblk, findmnt et df -h ; avec LVM, vérifiez aussi que l’espace ajouté a rejoint le volume logique attendu. Sous Windows, confirmez que Gestion des disques affiche le volume agrandi et que le système peut utiliser l’espace.

Ne validez pas le changement sur la seule base d’une valeur affichée dans l’interface de Proxmox. Une application peut également conserver son propre quota ou sa propre limite : si le système de fichiers présente la capacité attendue, mais que le service ne l’utilise pas, poursuivez le diagnostic au niveau de l’application plutôt que de réagrandir le disque.

Conservez les informations relevées avant et après l’opération, avec l’identifiant de la VM, le disque concerné et les résultats des vérifications. Pour une équipe MSP ou un parc de VM, cette trace permet de distinguer une erreur de dimensionnement de l’hôte d’une étape invitée oubliée, et d’éviter de répéter des modifications inutiles lors du prochain changement.

Quand revoir le stockage de l’hôte

Si une seule VM manque d’espace alors que le stockage partagé conserve une marge suffisante, l’extension de son disque peut être pertinente après vérification de son partitionnement et de sa sauvegarde. Si plusieurs VM approchent simultanément de leurs limites ou si le stockage hôte est contraint, le besoin est différent : il faut revoir la capacité de l’ensemble du serveur et les conséquences d’une modification sur les autres machines.

Un environnement mutualisé peut convenir à un usage léger, temporaire ou élastique. En revanche, une charge stable répartie entre plusieurs VM peut être gênée par la concurrence pour les ressources, les limites de configuration imposées par la plateforme ou des règles de facturation qui compliquent la prévision. Un serveur physique AMD dédié mérite alors d’être comparé si vous avez besoin de maîtriser durablement la répartition des ressources et le choix du stockage. Cela ne supprime pas le besoin de sauvegardes, et ne garantit pas qu’un disque précis soit disponible : vérifiez d’abord les options affichées par AmdMetal.

Pour éviter une décision d’achat fondée sur une hypothèse, consultez les tarifs et options actuellement indiqués par AmdMetal, puis comparez-les à la capacité que votre parc de VM consomme réellement. Si une solution dédiée correspond à votre charge permanente, vérifiez également les informations de provisionnement avant de planifier votre migration. Tant que la marge de l’hôte et le niveau bloquant ne sont pas identifiés, ne commandez pas davantage de stockage pour corriger un problème qui pourrait se trouver uniquement dans le système invité.

Questions fréquentes