Virtualisation sous Linux : KVM, QEMU et libvirt

KVM est l’hyperviseur intégré au noyau Linux : c’est lui qui fait tourner une grande partie du cloud mondial, d’OpenStack à de nombreuses offres d’hébergement. Associé à QEMU pour l’émulation du matériel et à libvirt pour la gestion, il transforme n’importe quelle machine Linux en plateforme de virtualisation complète, sans licence ni produit tiers. Dans ce guide, nous partons de la vérification du support matériel pour aboutir à des machines virtuelles provisionnées automatiquement avec cloud-init, en passant par virt-install, virsh, les disques qcow2 et la configuration réseau.

Clarifions d’abord les rôles de chaque composant : KVM est le module noyau qui donne accès aux instructions de virtualisation du processeur ; QEMU émule le matériel (disques, cartes réseau, BIOS/UEFI) et s’appuie sur KVM pour exécuter le code invité à vitesse quasi native ; libvirt est la couche de gestion (API, démon, CLI virsh) qui uniformise le pilotage de l’ensemble.

1. Vérifier le Support Matériel

La virtualisation matérielle exige les extensions Intel VT-x ou AMD-V, activées dans le BIOS/UEFI.

# Compter les drapeaux de virtualisation dans /proc/cpuinfo
# vmx = Intel VT-x, svm = AMD-V ; un résultat > 0 est bon signe
grep -Ec '(vmx|svm)' /proc/cpuinfo

# Sur Ubuntu/Debian, l'outil dédié donne un verdict clair
sudo apt install cpu-checker
kvm-ok
# Résultat attendu :
# INFO: /dev/kvm exists
# KVM acceleration can be used

# Vérifier que les modules noyau sont chargés
lsmod | grep kvm
# kvm_intel (ou kvm_amd) et kvm doivent apparaître

# Vérifier le périphérique KVM
ls -l /dev/kvm

Si kvm-ok signale que la virtualisation est désactivée, redémarrez et activez VT-x/AMD-V dans le firmware. Pour la virtualisation imbriquée (une VM dans une VM, utile pour les labs) :

# Vérifier le support de la virtualisation imbriquée (Intel)
cat /sys/module/kvm_intel/parameters/nested
# Y ou 1 = activé

2. Installer KVM, QEMU et libvirt

Debian/Ubuntu

# Installer l'hyperviseur, la couche de gestion et les outils
sudo apt install qemu-kvm libvirt-daemon-system libvirt-clients \
  virtinst bridge-utils qemu-utils

# Démarrer et activer le démon libvirt
sudo systemctl enable --now libvirtd

# Ajouter votre utilisateur aux groupes nécessaires
# (déconnexion/reconnexion requise pour prise en compte)
sudo usermod -aG libvirt,kvm "$USER"

Rocky Linux/Fedora

# Le groupe de paquets virtualization installe tout le nécessaire
sudo dnf install @virtualization
sudo systemctl enable --now libvirtd
sudo usermod -aG libvirt "$USER"

Valider l’installation

# Diagnostic complet de l'hôte de virtualisation
virt-host-validate
# Toutes les lignes QEMU doivent être PASS (les WARN IOMMU sont
# acceptables si vous ne faites pas de passthrough PCI)

# Vérifier la connexion à libvirt
virsh -c qemu:///system list --all

Deux URI de connexion coexistent : qemu:///system (VM gérées par le démon système, recommandé pour les serveurs) et qemu:///session (VM de l’utilisateur, sans privilèges). Pour éviter toute ambiguïté :

# Forcer virsh à utiliser la connexion système par défaut
echo 'export LIBVIRT_DEFAULT_URI=qemu:///system' >> ~/.bashrc

3. Créer une VM avec virt-install

Préparer l’image et le stockage

# Le répertoire standard des images libvirt
ls /var/lib/libvirt/images/

# Télécharger une ISO Debian (exemple)
sudo wget -P /var/lib/libvirt/images/ \
  https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-13.1.0-amd64-netinst.iso

Installation interactive depuis une ISO

# Créer une VM : 2 vCPU, 4 Go de RAM, disque qcow2 de 20 Go
sudo virt-install \
  --name debian-test \
  --memory 4096 \
  --vcpus 2 \
  --disk path=/var/lib/libvirt/images/debian-test.qcow2,size=20,format=qcow2 \
  --cdrom /var/lib/libvirt/images/debian-13.1.0-amd64-netinst.iso \
  --os-variant debian12 \
  --network network=default \
  --graphics vnc,listen=127.0.0.1

# Lister les identifiants d'OS reconnus (optimise les pilotes virtio)
virt-install --osinfo list | grep -i debian

L’installateur s’affiche via VNC (utilisez virt-viewer debian-test ou un tunnel SSH). Pour un serveur sans interface graphique, l’approche cloud-init de la section 8 est nettement plus efficace.

4. Gérer les VM avec virsh

Cycle de vie

# Lister les VM (actives et arrêtées)
virsh list --all

# Démarrer une VM
virsh start debian-test

# Arrêt propre (envoie un signal ACPI, l'invité doit le gérer)
virsh shutdown debian-test

# Arrêt brutal (équivalent de débrancher la prise)
virsh destroy debian-test

# Redémarrage
virsh reboot debian-test

# Démarrage automatique avec l'hôte
virsh autostart debian-test

# Console série texte (si configurée dans l'invité)
virsh console debian-test

# Supprimer une VM et ses disques définitivement
virsh undefine debian-test --remove-all-storage

Inspection et ressources

# Informations détaillées
virsh dominfo debian-test

# Adresses IP obtenues par la VM
virsh domifaddr debian-test

# Modifier la mémoire à chaud (dans la limite du maximum défini)
virsh setmem debian-test 2048M --live

# Éditer la définition XML de la VM
virsh edit debian-test

Snapshots

# Créer un snapshot avant une opération risquée
virsh snapshot-create-as debian-test avant-migration \
  --description "Avant montée de version PostgreSQL"

# Lister les snapshots
virsh snapshot-list debian-test

# Revenir à un snapshot
virsh snapshot-revert debian-test avant-migration

# Supprimer un snapshot devenu inutile
virsh snapshot-delete debian-test avant-migration

Les snapshots internes exigent le format qcow2. Attention : un snapshot n’est pas une sauvegarde, il vit sur le même disque que la VM et dégrade légèrement les performances s’il s’accumule.

5. Disques qcow2 avec qemu-img

Le format qcow2 (QEMU Copy-On-Write) supporte l’allocation fine (le fichier ne grossit qu’avec les données réelles), les snapshots internes et les images de base.

# Créer un disque de 50 Go (n'occupe que quelques Ko au départ)
qemu-img create -f qcow2 /var/lib/libvirt/images/data.qcow2 50G

# Inspecter une image : taille virtuelle vs taille réelle sur disque
qemu-img info /var/lib/libvirt/images/debian-test.qcow2

# Agrandir un disque (il faudra ensuite étendre la partition dans l'invité)
qemu-img resize /var/lib/libvirt/images/debian-test.qcow2 +20G

# Convertir une image VMware/VirtualBox vers qcow2
qemu-img convert -f vmdk -O qcow2 machine.vmdk machine.qcow2

# Compacter une image (VM arrêtée obligatoirement)
qemu-img convert -O qcow2 ancienne.qcow2 compactee.qcow2

Images de base et clones légers

# Créer un clone qui ne stocke que les différences avec l'image de base
qemu-img create -f qcow2 -F qcow2 \
  -b /var/lib/libvirt/images/base-debian.qcow2 \
  /var/lib/libvirt/images/clone-01.qcow2

# Vérifier la chaîne de dépendance
qemu-img info --backing-chain /var/lib/libvirt/images/clone-01.qcow2

Ne modifiez et ne déplacez jamais une image de base tant que des clones en dépendent : tous les clones seraient corrompus.

6. Réseaux libvirt : NAT et Bridge

Le réseau NAT par défaut

À l’installation, libvirt crée le réseau default : un pont interne virbr0 en 192.168.122.0/24 avec DHCP intégré (dnsmasq). Les VM sortent vers Internet via NAT mais ne sont pas joignables depuis le réseau physique.

# Lister les réseaux libvirt
virsh net-list --all

# Démarrer et rendre persistant le réseau par défaut
virsh net-start default
virsh net-autostart default

# Voir les baux DHCP attribués aux VM
virsh net-dhcp-leases default

Bridge : des VM citoyennes du réseau local

Pour que les VM obtiennent une adresse IP du réseau physique (comme des machines à part entière), créez un pont sur l’hôte. Exemple avec Netplan (Ubuntu Server), dans /etc/netplan/01-bridge.yaml :

network:
  version: 2
  ethernets:
    enp3s0:
      dhcp4: false
  bridges:
    br0:
      interfaces: [enp3s0]
      dhcp4: true

# Appliquer avec une fenêtre de retour arrière automatique en cas de coupure
sudo netplan try

# Vérifier le pont
ip addr show br0

Puis rattachez les VM au pont :

# À la création
virt-install ... --network bridge=br0 ...

# Ou modifiez une VM existante : dans virsh edit, remplacez
# <source network='default'/> par <source bridge='br0'/>

Mode	Adresse IP de la VM	Joignable depuis le LAN	Cas d’usage
NAT (default)	192.168.122.x privée	Non	Postes de dev, labs isolés
Bridge (br0)	Adresse du LAN	Oui	Serveurs de production
Isolated	Privée, sans sortie	Non	Tests de sécurité, bacs à sable

7. Conteneurs LXC ou Machines Virtuelles ?

LXC exécute des conteneurs système : des espaces isolés qui partagent le noyau de l’hôte, là où KVM démarre un noyau complet par machine. Les deux approches coexistent souvent sur le même hôte (Proxmox en est l’illustration).

Critère	LXC (conteneur système)	KVM (machine virtuelle)
Noyau	Partagé avec l’hôte	Propre à chaque VM
Isolation	Namespaces et cgroups	Matérielle (VT-x/AMD-V)
Densité	Très élevée (centaines par hôte)	Limitée par la RAM dédiée
Démarrage	Environ 1 seconde	10 à 60 secondes
Surcoût mémoire	Quasi nul	RAM réservée par VM
OS invité	Linux uniquement	Linux, Windows, BSD
Noyau ou modules personnalisés	Impossible	Oui
Sécurité multi-locataires	Correcte, surface plus large	Forte, référence du cloud public

# Aperçu rapide de LXC sur Ubuntu
sudo apt install lxc
sudo lxc-create -n conteneur-test -t download -- -d debian -r bookworm -a amd64
sudo lxc-start -n conteneur-test
sudo lxc-attach -n conteneur-test

Règle de décision : LXC pour de nombreux environnements Linux légers sur une même machine ; KVM dès qu’il faut un autre OS, un noyau spécifique ou une isolation forte entre locataires.

8. cloud-init : Automatiser le Provisionnement

cloud-init est le standard d’initialisation des images cloud : à son premier démarrage, la VM lit une configuration (utilisateurs, clés SSH, paquets, commandes) et s’auto-configure. Combiné aux images cloud officielles, il élimine complètement l’installation manuelle.

Récupérer une image cloud

# Image cloud Ubuntu 24.04 (qcow2 prêt à l'emploi, environ 600 Mo)
sudo wget -P /var/lib/libvirt/images/ \
  https://cloud-images.ubuntu.com/noble/current/noble-server-cloudimg-amd64.img

Écrire la configuration user-data

# /tmp/user-data.yaml
#cloud-config
hostname: vm-web-01
users:
  - name: admin
    sudo: ALL=(ALL) NOPASSWD:ALL
    shell: /bin/bash
    ssh_authorized_keys:
      - ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA... admin@poste-travail
package_update: true
packages:
  - nginx
  - htop
runcmd:
  - systemctl enable --now nginx

Créer la VM provisionnée

# Créer le disque de la VM à partir de l'image cloud (clone léger agrandi)
sudo qemu-img create -f qcow2 -F qcow2 \
  -b /var/lib/libvirt/images/noble-server-cloudimg-amd64.img \
  /var/lib/libvirt/images/vm-web-01.qcow2 20G

# virt-install génère l'ISO cloud-init automatiquement avec --cloud-init
sudo virt-install \
  --name vm-web-01 \
  --memory 2048 \
  --vcpus 2 \
  --disk path=/var/lib/libvirt/images/vm-web-01.qcow2,format=qcow2 \
  --import \
  --os-variant ubuntu24.04 \
  --network network=default \
  --cloud-init user-data=/tmp/user-data.yaml \
  --noautoconsole

# Deux minutes plus tard : récupérer l'adresse IP et se connecter
virsh domifaddr vm-web-01
ssh admin@192.168.122.53

La VM démarre, crée l’utilisateur, installe nginx et active le service sans aucune intervention. Ce processus se scripte et s’industrialise ensuite avec Terraform (provider libvirt) ou Ansible.

Bonnes pratiques

• Vérifiez virt-host-validate après toute installation ou mise à niveau de l’hôte.
• Travaillez systématiquement sur qemu:///system pour les serveurs et fixez LIBVIRT_DEFAULT_URI pour éviter les VM « disparues » créées sur la mauvaise connexion.
• Précisez toujours --os-variant dans virt-install : les pilotes virtio sélectionnés font une différence majeure de performances.
• Préférez virsh shutdown à virsh destroy : un arrêt brutal peut corrompre les systèmes de fichiers invités.
• Traitez les snapshots comme des points de retour temporaires, jamais comme des sauvegardes : sauvegardez les fichiers qcow2 (VM arrêtée ou via un snapshot externe cohérent).
• Ne touchez jamais à une image de base référencée par des clones.
• Réservez le NAT aux environnements de test ; utilisez un bridge pour tout service devant être joignable.
• Standardisez le provisionnement avec cloud-init dès la deuxième VM : la configuration manuelle ne passe pas à l’échelle.
• Surveillez l’espace disque de /var/lib/libvirt/images : les qcow2 en allocation fine grossissent silencieusement jusqu’à remplir le volume.

Conclusion

La pile KVM, QEMU et libvirt offre une virtualisation de niveau production avec les seuls outils du monde libre : KVM apporte les performances quasi natives, QEMU l’émulation du matériel, et libvirt une interface de gestion cohérente du poste de développement au cluster. Vous savez maintenant vérifier le support matériel, installer la pile, créer des VM avec virt-install, les piloter avec virsh, gérer les disques qcow2, choisir entre NAT et bridge, arbitrer entre conteneurs LXC et machines virtuelles, et automatiser le provisionnement avec cloud-init.

L’étape suivante consiste à industrialiser : décrivez vos VM dans Terraform avec le provider libvirt, configurez-les avec Ansible, et votre infrastructure de virtualisation devient reproductible, versionnée et auditables comme du code.