Stockage KVM/libvirt : pools, volumes et formats

Où sont stockés les disques de vos VMs ? Quel format choisir entre RAW et QCOW2 ? Ce guide explique le modèle de stockage libvirt : les pools (conteneurs) et les volumes (disques), pour que vous sachiez toujours où sont vos données.

Concept	Ce que c'est	Exemple
Pool	Conteneur de disques	`/var/lib/libvirt/images/`
Volume	Un disque individuel	`ubuntu-test.qcow2`

Prérequis

KVM/libvirt installé (guide installation)
LIBVIRT_DEFAULT_URI configuré pour qemu:///system

Ce que vous allez apprendre

La différence entre storage pool et volume
Les types de pools (directory, LVM, ZFS...)
Choisir entre RAW et QCOW2
Créer et gérer des pools et volumes avec virsh

Le modèle de stockage libvirt

libvirt abstrait le stockage avec deux niveaux :

Architecture stockage libvirt : un Storage Pool contient plusieurs volumes (disques qcow2/raw)

Pourquoi cette abstraction ?

Uniformité : mêmes commandes quel que soit le backend (fichier, LVM, ZFS)
Gestion : libvirt sait où trouver les disques, leur taille, leur disponibilité
Portabilité : les VMs référencent des volumes, pas des chemins absolus

Types de pools

Le type de pool se choisit au moment de sa définition et ne se change plus ensuite : pour en changer, il faut redéfinir le pool. Lisez la colonne « Cas d'usage » avant la colonne « Complexité », c'est elle qui tranche. La colonne « Type » donne le mot-clé exact attendu par virsh, qui ne colle pas toujours au nom courant de la technologie : un pool LVM se déclare logical, un partage NFS se déclare netfs. Écrire lvm ou nfs fait échouer la commande sur Invalid value for attribute 'type' in element 'pool'. dir, zfs et iscsi, eux, s'écrivent tels quels. La liste complète des types reconnus par votre version est donnée par virsh pool-define-as --help.

Type	Backend	Cas d'usage	Complexité
dir	Répertoire	Lab, homelab	Simple
logical	Volume Group LVM	Production, performance	Moyen
zfs	Dataset ZFS	NAS, snapshots natifs	Moyen
iscsi	Target iSCSI	SAN, datacenter	Avancé
netfs	Partage NFS ou CIFS	Stockage partagé	Moyen

Le pool "default"

Après installation de libvirt, le pool default pointe vers /var/lib/libvirt/images/.

Vérifier le pool default

C'est la première commande à lancer en cas de problème de stockage. L'option --all est importante : sans elle, virsh masque les pools inactifs, et un pool défini mais non démarré passe inaperçu. Deux colonnes comptent, State doit valoir active pour que les volumes soient utilisables, et Autostart doit valoir yes pour que le pool revienne après un redémarrage de l'hôte.

virsh pool-list --all

Sortie réelle :

 Name      State    Autostart
-------------------------------
 default   active   yes

Voir les détails

pool-info répond à la question qui provoque le plus d'échecs de création de VM : reste-t-il assez de place ? Regardez Available avant toute création de volume. Ces chiffres reflètent le système de fichiers sous-jacent, pas une réservation propre à libvirt : sur un pool de type répertoire, ils bougent dès que quoi que ce soit d'autre écrit sur la même partition.

virsh pool-info default

Sortie réelle :

Name:           default
UUID:           20e70471-c81e-484a-9b5f-dac1e4c856a5
State:          running
Persistent:     yes
Autostart:      yes
Capacity:       294,73 GiB
Allocation:     177,23 GiB
Available:      117,50 GiB

Décryptage :

Champ	Signification
State: running	Le pool est actif et utilisable
Persistent: yes	Défini de façon permanente
Autostart: yes	Démarre automatiquement au boot
Capacity	Taille totale du stockage
Allocation	Espace utilisé
Available	Espace libre

Voir la configuration XML

Le XML est la source de vérité du pool, celle qui est écrite sur disque et rejouée au démarrage de libvirt. On le consulte pour deux raisons : retrouver le chemin réel derrière un nom de pool, et vérifier les permissions appliquées au répertoire cible, qui expliquent la plupart des erreurs Permission denied au démarrage d'une VM.

virsh pool-dumpxml default

Sortie réelle :

<pool type='dir'>
  <name>default</name>
  <uuid>20e70471-c81e-484a-9b5f-dac1e4c856a5</uuid>
  <capacity unit='bytes'>316464824320</capacity>
  <allocation unit='bytes'>190303780864</allocation>
  <available unit='bytes'>126161043456</available>
  <source>
  </source>
  <target>
    <path>/var/lib/libvirt/images</path>
    <permissions>
      <mode>0711</mode>
      <owner>0</owner>
      <group>0</group>
    </permissions>
  </target>
</pool>

Points clés :

type='dir' : pool de type répertoire
<path>/var/lib/libvirt/images</path> : emplacement des fichiers disque

Créer un pool personnalisé

Le pool default vit sur la partition système, ce qui devient un problème dès que les disques de VM pèsent des dizaines de gigaoctets. Créer un pool dédié sur un autre disque isole cette croissance. La séquence est toujours la même quel que soit le type : définir, construire, démarrer, activer au boot. Sauter l'étape pool-autostart est l'oubli classique, le pool disparaît alors au redémarrage et les VMs refusent de démarrer.

Pool de type directory

Pour stocker les VMs ailleurs (par exemple sur un disque dédié) :

Créer le répertoire

sudo mkdir -p /data/vms
sudo chown root:root /data/vms
sudo chmod 711 /data/vms

Définir le pool
Fenêtre de terminal
```
virsh pool-define-as vms dir --target /data/vms
```
Sortie : Pool vms defined
Construire le pool (initialise le répertoire si nécessaire)
Fenêtre de terminal
```
virsh pool-build vms
```
Démarrer le pool
Fenêtre de terminal
```
virsh pool-start vms
```
Activer le démarrage automatique
Fenêtre de terminal
```
virsh pool-autostart vms
```

Vérifier

virsh pool-list --all

 Name      State    Autostart
-------------------------------
 default   active   yes
 vms       active   yes

Pool de type LVM

Pour utiliser un Volume Group LVM existant :

# Supposons un VG nommé "vg_vms"
virsh pool-define-as lvm-pool logical --source-name vg_vms --target /dev/vg_vms
virsh pool-start lvm-pool
virsh pool-autostart lvm-pool

Formats de disque : RAW vs QCOW2

Le format se choisit à la création du volume et conditionne les fonctionnalités disponibles pour toute la vie du disque. La ligne de partage est nette : QCOW2 apporte les snapshots et l'allocation à la demande, RAW ne fait rien d'autre que stocker des octets, et va donc légèrement plus vite. Un changement d'avis reste possible après coup avec qemu-img convert, mais impose d'arrêter la VM et de disposer du double de l'espace le temps de la conversion.

Format	Avantages	Inconvénients	Cas d'usage
RAW	Performance maximale, simple	Pas de snapshots, taille fixe	Production I/O intensif
QCOW2	Snapshots, thin provisioning, compression	Légère overhead	Lab, dev, la plupart des cas

RAW

Le fichier RAW ne contient aucune métadonnée : chaque octet du fichier correspond à un octet vu par la machine virtuelle. C'est ce qui explique à la fois sa vitesse et son absence de fonctionnalités. Conséquence pratique, un disque RAW se monte directement sur l'hôte avec losetup sans outillage particulier, ce qui aide au dépannage d'une VM qui ne démarre plus.

Fichier = image bit-à-bit du disque
Taille du fichier = taille du disque (pas de thin provisioning par défaut)
Aucune fonctionnalité avancée

QCOW2 (QEMU Copy-On-Write v2)

Thin provisioning : le fichier grandit à la demande
Snapshots : points de sauvegarde intégrés
Compression : optionnelle, réduit l'espace
Chiffrement : support natif (LUKS)
Backing files : chaînage pour les clones

Voir les informations d'un disque

qemu-img info /chemin/vers/disque.qcow2

Exemple de sortie :

image: ubuntu-test.qcow2
file format: qcow2
virtual size: 20 GiB (21474836480 bytes)
disk size: 2.1 GiB
cluster_size: 65536
Format specific information:
    compat: 1.1
    compression type: zlib
    lazy refcounts: false
    refcount bits: 16
    corrupt: false
    extended l2: false

Décryptage :

Champ	Signification
virtual size	Taille vue par la VM (20 GiB)
disk size	Espace réellement utilisé sur le disque (2.1 GiB)
cluster_size	Taille des blocs d'allocation
compat: 1.1	Version du format QCOW2

Le ratio disk size / virtual size montre le thin provisioning en action.

Gérer les volumes

Les commandes vol-* manipulent les disques à l'intérieur d'un pool. Toutes exigent de savoir dans quel pool chercher, soit en argument positionnel, soit via --pool. C'est la source d'erreur la plus fréquente de cette famille de commandes : un volume introuvable signifie presque toujours qu'on interroge le mauvais pool.

Lister les volumes d'un pool

Cette commande lit l'état connu de libvirt, pas le contenu réel du répertoire. Si vous avez copié un fichier .qcow2 à la main dans le répertoire du pool, il n'apparaîtra pas ici tant que vous n'aurez pas exécuté virsh pool-refresh <pool>. La colonne Path donne le chemin absolu, utile pour enchaîner sur qemu-img.

virsh vol-list default

Sortie exemple (pool avec des VMs) :

 Name                 Path
-----------------------------------------------------
 ubuntu-test.qcow2    /var/lib/libvirt/images/ubuntu-test.qcow2
 debian-srv.qcow2     /var/lib/libvirt/images/debian-srv.qcow2

Créer un volume

Créer un volume par virsh plutôt que par qemu-img présente un avantage : libvirt applique automatiquement le propriétaire et les permissions attendus par le pool, ce qui évite les erreurs d'accès au démarrage de la VM. La taille annoncée est une capacité maximale, pas une réservation : en QCOW2, le fichier ne pèse que quelques centaines de kilooctets juste après sa création.

virsh vol-create-as default test-disk.qcow2 10G --format qcow2

Options :

Paramètre	Signification
`default`	Nom du pool
`test-disk.qcow2`	Nom du volume
`10G`	Taille (G = GiB)
`--format qcow2`	Format du disque

Voir les informations d'un volume

Deux champs à comparer dans la sortie : Capacity est la taille vue par la machine virtuelle, Allocation l'espace réellement consommé sur l'hôte. Sur un volume QCOW2 fraîchement créé de 10 GiB, l'allocation tient dans quelques centaines de kilooctets. C'est le contrôle le plus rapide pour savoir si le provisionnement fin fonctionne comme prévu.

virsh vol-info test-disk.qcow2 --pool default

Supprimer un volume

virsh vol-delete test-disk.qcow2 --pool default

Redimensionner un volume

Pour agrandir un disque QCOW2 :

# Avec qemu-img (VM arrêtée)
qemu-img resize /var/lib/libvirt/images/vm.qcow2 +10G

# Ou avec virsh
virsh vol-resize vm.qcow2 30G --pool default

Emplacements des fichiers

Savoir où libvirt range ses fichiers sert dans deux situations : sauvegarder une configuration avant une manipulation risquée, et comprendre pourquoi un pool supprimé réapparaît après un redémarrage. Retenez la séparation : /etc/libvirt/ contient les définitions XML, /var/lib/libvirt/images/ contient les données. N'éditez jamais ces XML à la main pendant que le service tourne, libvirt les réécrit et vos modifications sont perdues ; passez par virsh edit ou par les commandes pool-define.

Fichier	Emplacement	Contenu
Définitions des pools	`/etc/libvirt/storage/`	XML des pools
Pool default	`/var/lib/libvirt/images/`	Disques des VMs
Définitions des VMs	`/etc/libvirt/qemu/`	XML des domains

# Voir les définitions de pools
ls /etc/libvirt/storage/

# Sortie :
# autostart/
# default.xml

Commandes virsh essentielles

Les trois tableaux ci-dessous suivent la découpe de l'outillage : virsh pool-* pour les conteneurs, virsh vol-* pour les disques, qemu-img pour tout ce qui touche au contenu d'un fichier disque en dehors de libvirt.

Pools

Deux paires de commandes se ressemblent et ne font pas du tout la même chose. pool-destroy arrête le pool sans rien effacer, pool-undefine supprime sa définition mais laisse les fichiers en place. Aucune des deux ne détruit de données. pool-refresh est celle qu'on oublie : elle resynchronise la vue de libvirt avec le contenu réel du répertoire.

Commande	Description
`virsh pool-list --all`	Lister tous les pools
`virsh pool-list --details`	Lister avec capacité/allocation
`virsh pool-info <pool>`	Détails d'un pool
`virsh pool-dumpxml <pool>`	Configuration XML
`virsh pool-define-as <nom> <type> --target <path>`	Créer un pool
`virsh pool-start <pool>`	Démarrer
`virsh pool-autostart <pool>`	Activer au boot
`virsh pool-destroy <pool>`	Arrêter
`virsh pool-undefine <pool>`	Supprimer la définition
`virsh pool-refresh <pool>`	Rafraîchir (rescan)

Volumes

Ici, en revanche, vol-delete efface le fichier immédiatement, sans confirmation ni corbeille. Notez aussi la position de --pool : elle varie d'une commande à l'autre, vol-list prend le pool en argument positionnel alors que vol-info et vol-delete attendent l'option nommée.

Commande	Description
`virsh vol-list <pool>`	Lister les volumes
`virsh vol-info <vol> --pool <pool>`	Infos d'un volume
`virsh vol-create-as <pool> <nom> <taille> --format <fmt>`	Créer
`virsh vol-delete <vol> --pool <pool>`	Supprimer
`virsh vol-resize <vol> <taille> --pool <pool>`	Redimensionner
`virsh vol-clone <src> <dst> --pool <pool>`	Cloner

qemu-img

qemu-img travaille directement sur les fichiers, en dehors de toute notion de pool. Règle de sécurité qui vaut pour les quatre commandes : la machine virtuelle doit être arrêtée. Modifier un disque pendant que QEMU l'utilise corrompt l'image de façon irrécupérable. qemu-img info reste sans danger en lecture seule, mais peut afficher des valeurs périmées sur un disque en cours d'écriture.

Commande	Description
`qemu-img info <fichier>`	Informations du disque
`qemu-img create -f qcow2 <fichier> <taille>`	Créer un disque
`qemu-img resize <fichier> +10G`	Agrandir
`qemu-img convert -O qcow2 <src> <dst>`	Convertir le format

Erreurs fréquentes

Ces cinq messages couvrent la quasi-totalité des blocages sur le stockage libvirt. Trois d'entre eux se diagnostiquent avec la même commande, virsh pool-list --all : un pool absent, arrêté ou plein produit des symptômes différents pour une cause voisine. Le Permission denied est le plus trompeur, il vient rarement de l'utilisateur qui lance virsh mais des droits du répertoire cible, que le processus QEMU doit pouvoir traverser.

Erreur	Cause	Solution
`Pool not found`	Pool inexistant ou pas démarré	`virsh pool-list --all`, `virsh pool-start`
`Vol not found`	Volume inexistant	`virsh vol-list <pool>`
`Permission denied`	Droits insuffisants sur le répertoire	Vérifier permissions (`chmod 711`)
`Not enough space`	Pool plein	Libérer de l'espace ou utiliser un autre pool
`Volume is in use`	VM utilise le disque	Arrêter la VM avant suppression

Checklist stockage

À parcourir avant de déclarer un hôte prêt, et surtout après toute manipulation de pool. Les deux premières lignes sont celles qui provoquent réellement des pannes : un pool sans autostart ne remonte pas au redémarrage et toutes ses machines refusent alors de démarrer, et un pool plein fait échouer les écritures d'un disque en provisionnement fin alors que virsh affichait une taille confortable.

Pool default actif et autostart (virsh pool-list --all)
Espace suffisant disponible (virsh pool-info default)
Format QCOW2 pour la plupart des VMs
Permissions correctes sur le répertoire du pool
Sauvegardes des disques importants planifiées

À retenir

Pool = conteneur de disques (répertoire, LVM, ZFS...). Volume = un disque individuel.
Le pool default (/var/lib/libvirt/images/) suffit pour débuter.
QCOW2 = le format recommandé (thin provisioning, snapshots). RAW = performance max mais pas de fonctionnalités.
virsh pool-* pour gérer les pools, virsh vol-* pour les volumes.
qemu-img info pour voir les vraies infos d'un disque (taille virtuelle vs réelle).
Redimensionner le fichier disque ≠ étendre le filesystem (à faire dans la VM).

Pour aller plus loin

Cloud-init avec KVM : Les images cloud déposées dans un pool donnent une VM configurée dès le premier démarrage.
Les 15 commandes virsh essentielles : Le pendant en ligne de commande de virsh pool-* et virsh vol-* pour piloter les domaines.
Snapshots, clones et backups : Ce que le format QCOW2 rend possible, et la limite entre snapshot et sauvegarde.

Références

libvirt - Storage Management, Documentation officielle des pools
libvirt - Storage Pool XML, Format XML des pools
QEMU - QCOW2, Documentation du format QCOW2
Red Hat - Managing storage, Guide officiel RHEL