Formation KVM/libvirt : VM, réseau, Terraform et projet final

Q: Pourquoi ma VM KVM n'est pas joignable depuis le réseau local (LAN) ?

Par défaut, libvirt crée un réseau NAT isolé (192.168.122.x). Les VMs peuvent sortir vers Internet mais ne sont pas accessibles depuis le LAN. Solution : créer un bridge réseau (br0) relié à l'interface physique de l'hôte.

Q: Comment éviter de perdre l'IP de l'hôte lors de la création d'un bridge KVM ?

L'interface physique perd son IP quand elle rejoint un bridge. Configurez le bridge AVANT de retirer l'IP de l'interface. Utilisez Netplan ou nmcli avec l'IP assignée au bridge (br0), pas à l'interface physique.

Q: Pourquoi Cloud-Init ne s'exécute pas sur ma VM KVM ?

Cloud-Init ne se ré-exécute pas si /etc/machine-id existe. Pour réutiliser une image, videz ce fichier avec truncate -s 0 /etc/machine-id puis arrêtez la VM. Au prochain boot, Cloud-Init détectera une nouvelle instance.

Q: Pourquoi le disque de ma VM KVM grossit après chaque snapshot ?

Les snapshots QCOW2 créent une chaîne de fichiers backing. Chaque snapshot est un delta, et la chaîne s'allonge. Solution : consolider régulièrement avec virsh blockcommit pour fusionner les couches.

Q: Quelle est la différence entre un snapshot et un backup KVM ?

Un snapshot est un point de retour rapide mais dépend du disque original (chaîne QCOW2). Un backup est une copie indépendante exportable. Utilisez les snapshots pour les tests courts, les backups pour la protection des données.

Q: Comment récupérer l'adresse IP d'une VM KVM avec virsh ?

Utilisez virsh domifaddr nom-vm pour les VMs avec qemu-guest-agent, ou virsh net-dhcp-leases default pour voir les baux DHCP du réseau NAT. Sans agent, inspectez la table ARP avec arp -n après un ping broadcast.

Q: Pourquoi j'ai l'erreur 'failed to connect to the hypervisor' avec virsh ?

Cette erreur signifie que libvirtd n'est pas démarré ou que l'utilisateur n'a pas les permissions. Vérifiez avec systemctl status libvirtd, puis ajoutez l'utilisateur au groupe libvirt avec usermod -aG libvirt $USER.

Q: Quand utiliser virtio vs IDE/SATA pour les disques KVM ?

Utilisez toujours virtio pour les performances (paravirtualisation). IDE/SATA sont émulés et beaucoup plus lents. Virtio nécessite des drivers dans le guest OS : inclus dans Linux, à installer manuellement sur Windows.

Q: Comment accéder à libvirt à distance via SSH ?

Utilisez l'URI qemu+ssh://user@host/system avec virsh ou virt-manager. L'authentification se fait par clé SSH. Assurez-vous que l'utilisateur distant est dans le groupe libvirt sur le serveur.

Q: Pourquoi Terraform affiche une IP vide pour ma VM libvirt ?

Le provider libvirt récupère l'IP via qemu-guest-agent. Si l'agent n'est pas installé ou démarré dans la VM, l'IP reste vide. Installez qemu-guest-agent via Cloud-Init et ajoutez un wait_for_lease ou un délai.

KVM (Kernel-based Virtual Machine) est l'hyperviseur de référence sous Linux. Intégré au noyau depuis 2007, il transforme n'importe quel serveur Linux en plateforme de virtualisation performante. Cette formation vous accompagne de la compréhension des concepts jusqu'à l'automatisation avec Terraform.

Contrairement à une documentation classique, cette formation suit une progression pédagogique : chaque module s'appuie sur les précédents, avec des prérequis explicites, des commandes testées et un quiz qui ferme chaque leçon.

Ce que vous allez apprendre

À la fin de cette formation, vous serez capable de :

Comprendre l'architecture KVM/QEMU/libvirt et leur interaction
Installer KVM proprement sur Ubuntu, Debian, Rocky ou Fedora
Créer des VMs avec virsh, virt-install et virt-manager
Configurer le réseau (NAT par défaut, bridge pour accès externe)
Gérer le stockage (pools, volumes, formats QCOW2)
Automatiser l'initialisation avec Cloud-Init
Protéger vos VMs (snapshots vs backups, comprendre la différence)
Sauvegarder une machine allumée avec virsh backup-begin, puis la restaurer
Régler les performances : mode CPU, cache disque, IOThreads
Vérifier ce que le confinement libvirt bloque vraiment, et ce qu'il observe
Migrer une VM à chaud, et comprendre pourquoi le défaut l'en empêche
Administrer à distance via SSH ou TCP
Déployer en Infrastructure as Code avec Terraform

Format et méthode pédagogique

La formation s'adresse aux administrateurs Linux, DevOps, SRE et développeurs qui veulent faire tourner leurs propres machines virtuelles. Le tableau ci-dessous fixe le cadre technique, et la ligne Version compte plus que les autres : les exemples sont testés sur libvirt 10.x tel que livré par Ubuntu 24.04, et fonctionnent sur les versions plus récentes. Si votre distribution fournit une version plus ancienne, la plupart des commandes restent valables, mais certaines options récentes de virsh peuvent manquer.

Élément	Détail
Public	Administrateurs Linux, DevOps, SRE, développeurs
Version	libvirt 9.x et suivantes (dernière 12.x ; exemples testés sur 10.x, Ubuntu 24.04)
Prérequis matériel	CPU avec virtualisation (Intel VT-x / AMD-V activé dans le BIOS)
Prérequis logiciel	Ubuntu 24.04, Debian 12+ ou Rocky 9+ (bare-metal ou nested virt)
Prérequis connaissances	Terminal Linux de base, notions réseau (IP, DHCP, DNS)
Pédagogie	Commandes testées avec sorties réelles + validations
Validation	Un quiz de 6 questions par leçon, plus un examen final de 30 questions
Durée	De 14 à 60 minutes par leçon selon la pratique demandée ; le plan de formation affiche le total à jour

Environnement de lab recommandé

Cette formation a été testée sur plusieurs configurations. Voici nos recommandations :

Configuration recommandée pour des performances optimales :

Composant	Minimum	Recommandé
CPU	4 cœurs avec VT-x/AMD-V	8+ cœurs
RAM	8 Go	16-32 Go
Stockage	100 Go HDD	256 Go SSD NVMe
OS	Ubuntu 24.04 / Debian 12 / Rocky 9	Ubuntu 24.04 Server

Avantage : Performances natives, pas de limite de virtualisation.

Si vous n'avez pas de serveur dédié, vous pouvez utiliser une VM :

Hyperviseur hôte	Comment activer l'imbrication
KVM / Proxmox	`kvm_intel.nested=1` ou `kvm_amd.nested=1`, vérifiable dans `/sys/module/`
VMware	Case « Virtualize Intel VT-x/EPT » dans les paramètres processeur
Hyper-V	`Set-VMProcessor -ExposeVirtualizationExtensions $true`
VirtualBox	Support limité selon la version : vérifiez sur votre version avant de compter dessus

Prérequis VM : 4 vCPU, 8 Go de RAM et 80 Go de disque permettent de suivre le parcours sans gêne.

Le contrôle qui tranche est le même que sur du matériel réel : virt-host-validate qemu doit rendre PASS sur la ligne d'accélération. La perte de performance en imbriqué est réelle mais très variable selon l'hyperviseur, la charge et le stockage : mesurez la vôtre plutôt que de retenir un pourcentage, la formation vous donne pour cela qemu-img bench et virsh domstats.

Certains providers cloud supportent la nested virtualization :

Type d'offre	Ce qu'il faut chercher
Serveur dédié	Le cas le plus simple : l'accélération matérielle est disponible d'office
Instance bare-metal	Proposée par les grands fournisseurs, facturée à l'heure
Instance à virtualisation imbriquée	Disponible chez plusieurs fournisseurs, mais la liste des gammes change

Les gammes et les tarifs évoluent trop vite pour être cités ici sans induire en erreur : vérifiez la page nested virtualization de votre fournisseur au moment où vous montez le lab. Le test reste virt-host-validate qemu sur l'instance, une fois qu'elle tourne.

Démonstration rapide : votre première VM en 5 commandes

Voici ce que vous saurez faire après les leçons Installation et Créer une VM :

# 1. Vérifier que KVM est fonctionnel
$ virsh -c qemu:///system version
Using library: libvirt 10.0.0
Running hypervisor: QEMU 8.2.2

# 2. Lister les réseaux disponibles
$ virsh net-list
 Name      State    Autostart   Persistent
--------------------------------------------
 default   active   yes         yes

# 3. Créer une VM Ubuntu avec virt-install
$ virt-install --name test-vm --memory 2048 --vcpus 2 \
    --disk size=20 --cdrom ubuntu-24.04-live-server.iso \
    --network network=default --graphics vnc
Starting install...

# 4. Vérifier que la VM tourne
$ virsh list
 Id   Name      State
-------------------------
 1    test-vm   running

# 5. Obtenir l'IP de la VM
$ virsh domifaddr test-vm
 Name       MAC address          Protocol     Address
-------------------------------------------------------
 vnet0      52:54:00:ab:cd:ef    ipv4         192.168.122.45/24

Cette séquence fonctionne sur toute installation libvirt correctement configurée. Les leçons Installation et Créer une VM expliquent chaque étape en détail, y compris les messages d'erreur que vous verrez quand l'une d'elles échoue.

Vue d'ensemble de la formation

La formation se lit dans l'ordre, et elle est découpée en modules pour que vous situiez votre progression et repériez où reprendre. Les deux premiers posent les bases et n'exigent aucun prérequis KVM ; la difficulté monte avec la création des VM, où l'on manipule de vraies machines, et culmine avec la migration et l'automatisation. Repérez la colonne Public : elle indique le niveau attendu pour aborder chaque module sereinement. Les intitulés et les durées sont ceux du plan de formation, dans la colonne de gauche.

Module	Leçons	Durée	Public
Comprendre KVM et installer l'hyperviseur	2	1 h 15	Débutant
Préparer l'hôte : réseau et stockage	5	2 h 18	Débutant à intermédiaire
Créer des VM et les exploiter au quotidien	8	5 h 30	Intermédiaire
Automatiser avec Terraform et dépanner	4	3 h 05	Intermédiaire à avancé

Le parcours de formation

Comprendre KVM et installer l'hyperviseur

Le modèle mental, puis les paquets

Comment KVM, QEMU et libvirt collaborent, puis une installation propre sur Debian, Ubuntu ou RHEL, permissions comprises.

Commencer par les concepts →

Préparer l'hôte : réseau et stockage

Ce que vos machines pourront joindre

Le choix entre NAT et bridge, trois recettes réseau courtes, puis les pools et les volumes.

Réseau NAT vs Bridge →

Créer des VM et les exploiter au quotidien

Le cœur du parcours, huit leçons

Création, cloud-init, virsh, agent invité, performances, confinement, snapshots et sauvegarde à chaud, accès distant.

Créer une VM →

Automatiser avec Terraform et dépanner

Déplacer, décrire en code, diagnostiquer

Migration à chaud, passthrough PCI, provider Terraform libvirt et arbre de décision réseau.

Migration live →

Détail des leçons, module par module

Les durées ci-dessous viennent du parcours lui-même, pas d'une estimation, et le plan de formation en tient le total à jour. Chaque module se referme sur les pièges qu'il désamorce, parce que c'est souvent eux que l'on vient chercher.

Comprendre KVM et installer l'hyperviseur

1 h 15, deux leçons. Ce module existe parce que la moitié des difficultés rencontrées ensuite viennent d'un modèle mental faux. Savoir qui fait quoi entre le module noyau, le processus QEMU et le démon libvirt rend lisibles toutes les commandes du reste du parcours.

Leçon	Durée	Ce que vous en retirez
Concepts fondamentaux	25 min	La relation KVM, QEMU et libvirt, et pourquoi aucun des trois ne remplace les deux autres
Installation	50 min	Les paquets réels sur Debian/Ubuntu et sur RHEL/Rocky, le service, les permissions de groupe et polkit

Les pièges de ce module : croire qu'« installer KVM » se limite à charger un module du noyau ; taper qemu-kvm sur Debian ou Ubuntu, où ce n'est pas un paquet mais un nom virtuel ; se croire dans le groupe libvirt alors que la session n'a pas été rouverte ; chercher une panne logicielle quand c'est la virtualisation qui est désactivée dans le firmware.

Préparer l'hôte : réseau et stockage

2 h 18, cinq leçons. C'est le module qui décide de ce que vos machines pourront joindre, et celui où se concentrent les pannes. Les trois recettes sont des pas-à-pas courts, chacun répondant à une demande précise plutôt qu'à un tour d'horizon.

Leçon	Durée	Ce que vous en retirez
Réseau NAT vs Bridge	50 min	Le tableau de décision entre les deux modes, et l'IPv6 qui ne vient pas tout seul
Port forwarding NAT	16 min	Exposer un service d'une VM en NAT, DNAT et FORWARD compris
Bridge ifupdown	18 min	Monter un bridge sur une machine sans NetworkManager
Réseau libvirt custom	14 min	Un réseau NAT sur mesure, isolé ou routé, avec sa plage DHCP
Stockage pools et volumes	40 min	Les pools, les volumes, et le choix entre QCOW2 et raw

Les pièges de ce module : une VM injoignable depuis le LAN parce que le NAT ne route pas vers elle ; une interface physique non libérée avant la création du bridge ; une règle DNAT posée sans le FORWARD qui va avec, qui produit un blocage silencieux et non un refus ; un pool inactif après redémarrage ; la taille annoncée à la création d'un volume, qui est une capacité maximale et non une réservation.

Créer des VM et les exploiter au quotidien

5 h 30, huit leçons. Le cœur du parcours. On y passe de la machine créée à la main à la machine provisionnée, interrogeable, réglée, confinée et sauvegardée. C'est aussi le module le plus long : prévoyez de le lire en plusieurs fois.

Leçon	Durée	Ce que vous en retirez
Créer une VM	50 min	`virt-install` et virt-manager, et les options qui comptent vraiment
Cloud-init	50 min	Une VM utilisable dès le premier boot, clés SSH et paquets compris
Commandes virsh	50 min	Le cycle de vie complet d'un domaine, et la différence entre `destroy` et `undefine`
QEMU Guest Agent	30 min	Ce que l'hôte sait d'une VM avec l'agent et sans lui, mesuré des deux côtés
Performances	35 min	Les modes CPU, les six modes de cache, l'attribut `io` et les IOThreads
Sécurité	35 min	Les couches de confinement réellement actives, Secure Boot, vTPM et nwfilter
Snapshots, clones et sauvegardes	45 min	Les trois techniques distinguées, et la sauvegarde à chaud par `virsh backup-begin`
Accès distant	35 min	`qemu+ssh`, l'activation par socket et le rôle de virtproxyd

Les pièges de ce module : un cloud-init qui ne rejoue pas parce qu'il retrouve le même instance-id ; un undefine qui laisse les disques sur l'hôte ; une console VNC sans mot de passe, d'où l'importance de listen=127.0.0.1 ; un profil AppArmor chargé mais en mode complain, donc qui n'interdit rien ; io='native' que QEMU refuse sans cache.direct=on ; et le plus coûteux de tous, confondre un snapshot avec une sauvegarde.

Automatiser avec Terraform et dépanner

3 h 05, quatre leçons. Les sujets que l'on aborde une fois que les machines tournent : les déplacer, leur donner du matériel réel, les décrire en code, et savoir quoi regarder quand le réseau tombe.

Leçon	Durée	Ce que vous en retirez
Migration live	35 min	Vérifier la compatibilité processeur avant de tenter, et traiter une migration qui ne converge pas
Passthrough PCI	30 min	Savoir si votre machine en est capable, lire les groupes IOMMU, déclarer le périphérique
KVM et Terraform	60 min	Le provider libvirt, les templates cloud-init et le déploiement de plusieurs machines
Dépannage réseau	60 min	L'arbre de décision, le test en escalier, et le conflit avec Docker

Les pièges de ce module : virt-install qui pose host-passthrough par défaut, ce qui rend vos machines non migrables sans que personne l'ait décidé ; un groupe IOMMU qui se donne entier et emporte le contrôleur USB avec la carte graphique ; une IP vide dans les sorties Terraform faute d'agent invité ; et le mythe selon lequel Docker désactiverait ip_forward, que le guide démonte mesure à l'appui.

Valider la formation

1 h 10, deux leçons. La validation se fait dans cet ordre, et l'ordre compte : on prouve d'abord, on mesure ensuite.

Le projet final enchaîne toute la formation sur deux hôtes : une machine naît par cloud-init, sert une application, se fait sauvegarder à chaud, perd son disque, revient de sa sauvegarde, puis se déplace sans être arrêtée. Chaque étape rend un chiffre, et le vôtre se compare au nôtre.

L'examen final tire ensuite 30 questions dans les leçons de cours, à proportion de ce que chaque module pèse dans une exploitation réelle. Chaque question renvoie vers la section précise du guide qui traite le point : un score devient ainsi une liste de choses à relire.

Ce que cette formation couvre (et ne couvre pas)

Couvert
Non couvert

Installation : Ubuntu, Debian, Rocky, Fedora
Réseau : NAT (default), bridge, réseaux isolés, routés, IPv6
Stockage : Pools dir/LVM, volumes QCOW2/raw
Création VMs : virt-install, virt-manager, Cloud-Init
Opérations : virsh, QEMU Guest Agent, snapshots, clones
Sauvegarde : à chaud avec virsh backup-begin, complète et incrémentale
Performances : modes CPU, six modes de cache disque, io, IOThreads
Sécurité : sVirt, AppArmor et SELinux, seccomp, Secure Boot, vTPM, nwfilter
Migration : à chaud entre hôtes, compatibilité processeur, convergence
Passthrough PCI : diagnostic IOMMU, groupes, vfio-pci
Accès distant : SSH, activation par socket, virtproxyd, TCP en héritage
IaC : Terraform/OpenTofu avec provider libvirt 0.9.x
Troubleshooting : arbre de décision réseau, test en escalier, conflit avec Docker

Scénarios d'incidents couverts

Tout au long de la formation, vous apprendrez à diagnostiquer et résoudre les problèmes courants :

#	Symptôme	Cause probable	Où c'est traité
1	`failed to connect to the hypervisor`	libvirtd arrêté, ou groupe `libvirt` pas encore actif	Installation
2	VM sans accès réseau externe	Réseau NAT par défaut, qui isole	Réseau NAT vs Bridge
3	Disque plein après snapshots	Chaîne QCOW2 non consolidée	Snapshots et sauvegardes
4	Cloud-init ne s'exécute pas	Instance-id identique au boot précédent	Cloud-init
5	IP vide dans les sorties Terraform	QEMU Guest Agent absent de l'invité	QEMU Guest Agent
6	Permission denied sur le pool	Confinement AppArmor ou SELinux	Sécurité
7	Sauvegarde inutilisable	Confusion entre snapshot et sauvegarde	Snapshots et sauvegardes
8	VM lente sans que le CPU sature	Bus disque ou mode de cache inadapté	Performances
9	Connexion SSH impossible	Clé non injectée par cloud-init	Cloud-init
10	Bridge qui ne fonctionne pas	Interface physique non libérée	Bridge ifupdown
11	Migration refusée par la destination	Mode CPU `host-passthrough` posé par défaut	Migration live
12	Aucun groupe IOMMU sur l'hôte	Virtualisation d'E/S désactivée dans le firmware	Passthrough PCI

Par où commencer ?

Suivez les leçons dans l'ordre, en commençant par les concepts. Prenez le temps de comprendre l'architecture avant d'installer : c'est ce qui rend lisibles les commandes qui suivent, et ce qui évite la confusion entre KVM, QEMU et libvirt.

Première leçon : Concepts KVM/libvirt

Mon retour d'expérience, pour ceux qui veulent comprendre

Jusqu'ici cette page est restée factuelle. La suite est plus personnelle : pourquoi je continue de miser sur KVM plutôt que sur les solutions propriétaires, et les pièges que je vois revenir en production.

Je déploie des machines virtuelles sur KVM/libvirt depuis des années, du homelab jusqu'à des serveurs de production. Dès qu'il y a un Linux sous la main, c'est devenu mon réflexe par défaut.

Pourquoi KVM reste un choix solide en 2026

Sans KVM	Avec KVM
Licences VMware coûteuses, incertitude post-Broadcom	Gratuit, GPL, intégré au noyau
Dépendance à un éditeur	Stack 100% open source et standard
Outillage propriétaire	virsh, Terraform, Ansible, API libvirt

Le rachat de VMware par Broadcom et l'envolée des licences ont accéléré une bascule que j'observe partout : les équipes cherchent une alternative libre et pérenne. KVM, intégré au noyau Linux depuis 2007 et moteur de Proxmox comme d'OpenStack, est la réponse la plus mûre.

Ce que cette formation défend

Une formation technique n'est jamais neutre : elle fait des choix, et autant les assumer. Voici les cinq partis pris qui orientent chaque module, avec à chaque fois la raison concrète derrière la position.

L'IaC avant les clics : je pilote KVM en ligne de commande et en Terraform, pas seulement dans virt-manager. Une infra qui compte se script et se versionne.
Cloud-Init systématique : une VM se construit en quelques secondes, jamais à la main. Les VM montées au clic sont une dette.
Snapshot n'est pas backup : je martèle la distinction, parce que c'est l'erreur qui coûte le plus cher.
QCOW2 par défaut : thin provisioning et snapshots natifs, sauf besoin de performance brute (raw).
Le bridge quand il faut de la vraie connectivité : le NAT par défaut suffit pour tester, pas pour exposer un service.

Ce que je vous déconseille

À l'inverse, voici les erreurs que je vois revenir le plus souvent en production. Aucune n'est théorique : chacune a un coût réel, du disque qui explose à la sauvegarde qui n'en était pas une. Les connaître à l'avance vous évitera de les découvrir au pire moment.

Empiler les snapshots : j'ai vu des disques exploser et des VM ramper parce que personne ne consolidait la chaîne QCOW2. Un snapshot est temporaire, point.
Confondre snapshot et sauvegarde : le jour où le stockage lâche, les snapshots partent avec.
Tout faire dans virt-manager : ça ne se reproduit pas, ça ne se versionne pas, ça ne s'automatise pas.
Oublier le qemu-guest-agent : sans lui, pas d'IP propre, pas d'arrêt gracieux, et un output Terraform vide.
Négliger le BIOS/UEFI : la moitié des « KVM ne marche pas » sont une virtualisation désactivée dans le firmware.

KVM face à Proxmox, VMware et VirtualBox

Soyons clairs sur le positionnement. KVM/libvirt est la brique brute : maximale en contrôle et en scriptabilité, mais sans interface clé en main. Proxmox VE est KVM emballé dans une interface web et du clustering, parfait quand on veut une console sans tout scripter (voir la formation Proxmox). VMware reste puissant mais payant et incertain depuis Broadcom. VirtualBox est un outil de poste de travail, pas un hyperviseur de serveur.

Mon conseil : apprenez KVM/libvirt d'abord, c'est le socle qu'on retrouve sous Proxmox comme sous OpenStack, puis montez sur Proxmox si vous voulez l'interface.

Ressources

Cinq adresses suffisent pendant la formation. La documentation libvirt fait autorité sur le format XML et les commandes virsh, le wiki KVM couvre le module noyau, et les deux dépôts d'images cloud fournissent les disques que les leçons cloud-init et Terraform téléchargent.

Documentation libvirt : libvirt.org
Wiki KVM : linux-kvm.org
Provider Terraform : registry.terraform.io/providers/dmacvicar/libvirt
Images cloud Ubuntu : cloud-images.ubuntu.com
Images cloud Debian : cloud.debian.org/images/cloud

FAQ : questions fréquentes sur KVM/libvirt

Ces questions sont celles que les lecteurs posent le plus souvent une fois les premières VM créées : une machine injoignable depuis le LAN, un cloud-init qui ne rejoue pas, un disque qui grossit après chaque snapshot, ou une IP vide côté Terraform. Chaque réponse renvoie à la leçon qui traite le point.

Pourquoi ma VM KVM n'est pas joignable depuis le réseau local (LAN) ?

Cause : réseau NAT par défaut

Libvirt crée automatiquement un réseau NAT nommé default (192.168.122.x). Ce réseau permet aux VMs d'accéder à Internet, mais isole les VMs du réseau local.

Diagnostic

# Vérifier le réseau de la VM
virsh domiflist ma-vm
# Si "network" = "default" → NAT isolé

Solution : créer un bridge

Un bridge relie la VM directement au LAN :

Configuration	Accès LAN	Accès Internet	IP VM
NAT (default)	❌ Non	✅ Oui	192.168.122.x
Bridge (br0)	✅ Oui	✅ Oui	IP du LAN

# Créer le bridge (Netplan - Ubuntu)
network:
  bridges:
    br0:
      interfaces: [enp3s0]
      dhcp4: true

Lien utile

Voir le module Réseau NAT vs Bridge pour la configuration complète.

Comment éviter de perdre l'IP de l'hôte lors de la création d'un bridge KVM ?

Le problème

Quand vous ajoutez une interface physique (ex: enp3s0) à un bridge, elle perd son IP. Si c'est votre interface principale, vous perdez la connexion SSH.

Solution préventive

Configurez le bridge avant d'appliquer, en assignant l'IP au bridge :

# /etc/netplan/01-bridge.yaml
network:
  version: 2
  ethernets:
    enp3s0:
      dhcp4: false  # Pas d'IP sur l'interface
  bridges:
    br0:
      interfaces: [enp3s0]
      dhcp4: true   # IP sur le bridge
      # ou IP statique :
      # addresses: [192.168.1.100/24]
      # routes:
      #   - to: default
      #     via: 192.168.1.1

Appliquer sans perdre la connexion

# Tester d'abord
sudo netplan try
# Appliquer si OK (confirmation dans 120s)

Si vous êtes déjà déconnecté

Accès console physique ou IPMI/iLO
Ou reboot (la config précédente revient si non persistée)

Pourquoi Cloud-Init ne s'exécute pas sur ma VM KVM ?

Cause principale : machine-id

Cloud-Init utilise /etc/machine-id pour détecter si c'est un premier boot. Si ce fichier existe et contient un ID, Cloud-Init considère que l'initialisation est déjà faite.

Diagnostic

# Dans la VM
cat /etc/machine-id
# Si non vide → Cloud-Init ne se relancera pas

# Vérifier les logs Cloud-Init
cat /var/log/cloud-init.log | grep -i "running"

Solution : nettoyer l'image

Avant de créer un template/clone :

# Vider machine-id
sudo truncate -s 0 /etc/machine-id
sudo rm -f /var/lib/cloud/instance
sudo cloud-init clean
sudo shutdown -h now

Autres causes possibles

Symptôme	Cause	Solution
Pas de user-data	Datasource mal configuré	Vérifier `ds=nocloud`
Erreur YAML	Syntaxe invalide	Valider avec `cloud-init schema`
Timeout	Pas de métadonnées	Ajouter `meta-data` au seed ISO

Pourquoi le disque de ma VM KVM grossit après chaque snapshot ?

Cause : chaîne de backing files

Un snapshot QCOW2 ne copie pas le disque. Il crée un nouveau fichier qui stocke uniquement les différences (delta). L'original devient un "backing file" en lecture seule.

base.qcow2 ← snap1.qcow2 ← snap2.qcow2 ← snap3.qcow2 (actif)

Chaque écriture va dans le fichier actif → il grossit.

Diagnostic

# Voir la chaîne de backing
qemu-img info --backing-chain /var/lib/libvirt/images/vm-disk.qcow2

# Taille réelle vs virtuelle
du -h /var/lib/libvirt/images/*.qcow2

Solution : consolider

# Fusionner tous les snapshots dans la base
virsh blockcommit ma-vm vda --active --pivot --verbose

Bonnes pratiques

Action	Fréquence
Snapshot temporaire	Avant opération risquée
Supprimer après test	Immédiatement si OK
Consolider	Après 3-5 snapshots max
Backup complet	Planifié (pas snapshot !)

Quelle est la différence entre un snapshot et un backup KVM ?

Différence fondamentale

Critère	Snapshot	Backup
Dépendance	Lié au disque original	Indépendant
Portabilité	Non exportable seul	Exportable
Vitesse	Instantané	Long (copie)
Usage	Test, retour rapide	Protection données
Risque	Corruption en chaîne	Aucun

Snapshot = point de retour

# Créer un snapshot
virsh snapshot-create-as ma-vm snap-avant-upgrade

# Revenir en arrière
virsh snapshot-revert ma-vm snap-avant-upgrade

⚠️ Attention : si le disque de base est corrompu, tous les snapshots sont perdus.

Backup = copie complète

# VM arrêtée : copie simple
cp /var/lib/libvirt/images/vm.qcow2 /backup/vm-$(date +%F).qcow2

# VM en cours : export avec virsh
virsh backup-begin ma-vm --backupxml backup.xml

Règle d'or

Snapshot : avant une mise à jour, pour rollback rapide
Backup : planifié, pour restauration après sinistre

Comment récupérer l'adresse IP d'une VM KVM avec virsh ?

Méthode 1 : domifaddr (recommandé)

virsh domifaddr ma-vm
# Nécessite qemu-guest-agent dans la VM

Sortie :

 Name       MAC address          Protocol     Address
-------------------------------------------------------
 vnet0      52:54:00:ab:cd:ef    ipv4         192.168.122.45/24

Méthode 2 : baux DHCP

# Pour le réseau NAT default
virsh net-dhcp-leases default

Méthode 3 : table ARP

# Forcer la découverte
ping -b 192.168.122.255 -c 2
arp -n | grep 52:54:00

Comparaison

Méthode	Prérequis	Fiabilité
`domifaddr`	qemu-guest-agent	✅ Excellente
`net-dhcp-leases`	Réseau géré par libvirt	✅ Bonne
`arp`	VM répond au ping	⚠️ Variable

Installer qemu-guest-agent

# Dans la VM Ubuntu/Debian
sudo apt install qemu-guest-agent
sudo systemctl enable --now qemu-guest-agent

Pourquoi j'ai l'erreur 'failed to connect to the hypervisor' avec virsh ?

Causes et solutions

Cause	Diagnostic	Solution
libvirtd arrêté	`systemctl status libvirtd`	`sudo systemctl start libvirtd`
Permissions	`groups \| grep libvirt`	`sudo usermod -aG libvirt $USER`
Socket absent	`ls /var/run/libvirt/`	Redémarrer libvirtd
Mauvais URI	Variable `LIBVIRT_DEFAULT_URI`	`export LIBVIRT_DEFAULT_URI=qemu:///system`

Diagnostic complet

# 1. Vérifier le service
sudo systemctl status libvirtd

# 2. Vérifier les groupes
groups
# Doit contenir : libvirt (et kvm sur certaines distros)

# 3. Tester la connexion
virsh -c qemu:///system version

Solution typique

# Démarrer et activer libvirtd
sudo systemctl enable --now libvirtd

# Ajouter l'utilisateur au groupe
sudo usermod -aG libvirt $USER

# Recharger les groupes (ou logout/login)
newgrp libvirt

Quand utiliser virtio vs IDE/SATA pour les disques KVM ?

Comparaison des performances

Type	Latence	Débit	CPU host
virtio	~50µs	~1 GB/s	Faible
SATA (émulé)	~500µs	~300 MB/s	Moyen
IDE (émulé)	~1ms	~100 MB/s	Élevé

Pourquoi virtio est meilleur

Virtio est une interface paravirtualisée : le guest OS sait qu'il tourne dans une VM et communique directement avec l'hyperviseur. Pas d'émulation matérielle = moins de overhead.

Quand utiliser IDE/SATA

Installation Windows : le driver virtio n'est pas chargé au boot
OS très anciens : pas de support virtio
Debugging : isoler un problème de driver

Configuration virt-install

# Recommandé : virtio
virt-install --disk path=disk.qcow2,bus=virtio ...

# Fallback : SATA
virt-install --disk path=disk.qcow2,bus=sata ...

Windows : installer les drivers

Télécharger l'ISO virtio-win de Fedora
Monter comme CD-ROM secondaire
Installer les drivers pendant l'installation Windows

Comment accéder à libvirt à distance via SSH ?

Connexion SSH simple

# Depuis le poste client
virsh -c qemu+ssh://admin@192.168.1.100/system list --all

Avec virt-manager

Fichier → Ajouter une connexion
Hyperviseur : QEMU/KVM
Cocher : Se connecter à un hôte distant via SSH
Entrer : admin@192.168.1.100

Prérequis côté serveur

# L'utilisateur doit être dans le groupe libvirt
sudo usermod -aG libvirt admin

# Vérifier que libvirtd tourne
sudo systemctl status libvirtd

Prérequis côté client

# Clé SSH configurée (pas de mot de passe)
ssh-copy-id admin@192.168.1.100

# Test
ssh admin@192.168.1.100 "virsh version"

URIs disponibles

URI	Usage
`qemu+ssh://user@host/system`	VMs système (root)
`qemu+ssh://user@host/session`	VMs utilisateur
`qemu+tcp://host/system`	Sans SSH (non chiffré !)

Pourquoi Terraform affiche une IP vide pour ma VM libvirt ?

Cause : qemu-guest-agent absent

Le provider Terraform dmacvicar/libvirt utilise qemu-guest-agent pour interroger l'IP de la VM. Sans agent, aucune IP n'est remontée.

Solution complète

1. Installer l'agent via Cloud-Init

# user-data.yaml
#cloud-config
packages:
  - qemu-guest-agent
runcmd:
  - systemctl enable --now qemu-guest-agent

2. Ajouter le channel dans le domaine

# Terraform/OpenTofu
resource "libvirt_domain" "vm" {
  # ... autres configs ...

  qemu_agent = true  # Active le channel virtio-serial
}

3. Récupérer l'IP avec data source

# Provider 0.9.x
data "libvirt_domain_interface_addresses" "vm" {
  domain_id     = libvirt_domain.vm.id
  wait_for_lease = true  # Attend que l'IP soit disponible
}

output "ip" {
  value = data.libvirt_domain_interface_addresses.vm.interfaces[0].addrs[0].addr
}

Délai nécessaire

Même avec l'agent, il faut 30-60 secondes après le boot pour que l'IP soit disponible. Ajoutez un depends_on ou utilisez wait_for_lease = true.

Comment redimensionner un disque QCOW2 d'une VM KVM ?

Étapes complètes

1. Arrêter la VM

virsh shutdown ma-vm
# Attendre l'arrêt complet
virsh list --all  # State = shut off

2. Agrandir le fichier QCOW2

# Ajouter 10 Go
qemu-img resize /var/lib/libvirt/images/ma-vm.qcow2 +10G

# Vérifier
qemu-img info /var/lib/libvirt/images/ma-vm.qcow2

3. Démarrer et étendre la partition

virsh start ma-vm
ssh user@vm

# Voir l'espace disponible
lsblk
# vda    50G
# └─vda1 40G  ← partition à étendre

# Étendre la partition (partition 1)
sudo growpart /dev/vda 1

# Étendre le filesystem
sudo resize2fs /dev/vda1   # ext4
# ou
sudo xfs_growfs /          # XFS

Résultat

df -h /
# Filesystem      Size  Used Avail Use%
# /dev/vda1        49G   15G   32G  32%  ← étendu !

Attention

Ne jamais réduire un disque QCOW2 contenant des données
Faire un backup avant toute opération de redimensionnement

Comment cloner une VM KVM proprement ?

Clonage avec virt-clone

# La VM source doit être arrêtée
virsh shutdown ma-vm

# Cloner
virt-clone --original ma-vm \
           --name ma-vm-clone \
           --auto-clone

# Résultat
virsh list --all
# ma-vm        shut off
# ma-vm-clone  shut off

Ce qui est automatiquement changé

Élément	Original	Clone
Nom	ma-vm	ma-vm-clone
UUID	abc123...	def456...
MAC	52:54:00:aa:bb:cc	52:54:00:dd:ee:ff
Disque	ma-vm.qcow2	ma-vm-clone.qcow2

Nettoyage post-clone

Dans le clone, avant utilisation :

# Nouveau machine-id (important pour Cloud-Init)
sudo truncate -s 0 /etc/machine-id
sudo rm /var/lib/dbus/machine-id 2>/dev/null

# Nouvelles clés SSH host
sudo rm /etc/ssh/ssh_host_*
sudo dpkg-reconfigure openssh-server

# Nouveau hostname
sudo hostnamectl set-hostname nouveau-nom

Clone vs Snapshot

	Clone	Snapshot
Copie indépendante	✅ Oui	❌ Non
Espace disque	Full copy	Delta only
Usage	Duplication	Rollback