KVM : qu'est-ce que c'est ? L'hyperviseur Linux (QEMU, libvirt)

KVM (Kernel-based Virtual Machine) est l'hyperviseur intégré au noyau Linux depuis 2007. Il transforme une machine Linux en plateforme de virtualisation en s'appuyant sur les extensions matérielles du processeur (Intel VT-x ou AMD-V), ce qui donne aux machines virtuelles des performances quasi natives. C'est le moteur derrière Proxmox, OpenStack et la plupart des clouds.

Mais quand on « utilise KVM », on tombe vite sur trois noms : KVM, QEMU, libvirt. Lequel fait quoi ? Ce guide clarifie les 3 couches de la virtualisation Linux et ce que vous manipulez réellement au quotidien.

L'essentiel en 20 secondes

Couche	Rôle	Où ça tourne
KVM	Accélère l'exécution CPU des VMs	Kernel (module)
QEMU	Construit la VM et ses périphériques	Userspace (processus)
libvirt	Pilote tout via API/daemon/outils	Userspace (service)

Glissez pour voir

Quand vous "utilisez KVM", vous utilisez en réalité les trois ensemble.

Ce que vous allez apprendre

• Le rôle de KVM (accélération matérielle)
• Le rôle de QEMU (émulation et création de VMs)
• Le rôle de libvirt (gestion unifiée)
• Les objets que vous manipulez : domain, network, storage pool
• La différence entre défini et actif

La confusion classique

Quand on débute avec la virtualisation Linux, on rencontre rapidement ces trois termes :

• "Installer KVM"
• "Lancer une VM avec QEMU"
• "Gérer les VMs avec libvirt"

Ces termes sont souvent utilisés de manière interchangeable, ce qui crée de la confusion. En réalité, ce sont trois couches distinctes qui travaillent ensemble.

Les 3 couches de la virtualisation Linux

Vue d'ensemble

Chaque couche a un rôle précis. Voyons-les une par une.

KVM : le moteur turbo

KVM (Kernel-based Virtual Machine) est un module du noyau Linux. Ce n'est pas un programme que vous lancez, c'est une extension du kernel qui transforme Linux en hyperviseur.

Ce que fait KVM

• Accélération matérielle : utilise les instructions CPU (Intel VT-x / AMD-V) pour exécuter les VMs à vitesse quasi-native
• Isolation : chaque VM est isolée des autres grâce au matériel
• Performance : les instructions de la VM s'exécutent directement sur le CPU, pas d'émulation coûteuse

Ce que KVM ne fait PAS

• KVM ne crée pas de VMs
• KVM ne gère pas les disques virtuels
• KVM ne configure pas le réseau

KVM est "juste" l'accélérateur. Sans lui, les VMs tourneraient en émulation logicielle (très lent). Avec lui, elles atteignent des performances proches du bare-metal.

Analogie

Si votre VM est une voiture, KVM est le turbo. Sans turbo, la voiture roule (lentement). Avec turbo, elle atteint sa vitesse maximale.

Intel vs AMD

• Intel VT-x → module kvm_intel
• AMD-V → module kvm_amd

Les deux offrent les mêmes fonctionnalités pour l'utilisateur final. Voir le guide Installation pour vérifier que KVM est disponible sur votre machine.

QEMU : le châssis

QEMU (Quick Emulator) est un émulateur et virtualiseur. C'est lui qui crée réellement les machines virtuelles.

Ce que fait QEMU

• Crée les VMs : définit le "matériel virtuel" (CPU, RAM, disques, cartes réseau)
• Émule le matériel : peut émuler différentes architectures (x86, ARM, etc.)
• Gère les périphériques : disques virtuels, cartes réseau, USB, etc.

QEMU seul vs QEMU + KVM

Mode	Performance	Usage
QEMU seul	Lente (émulation)	Émuler une autre architecture (ARM sur x86)
QEMU + KVM	Quasi-native	VMs de production sur même architecture

Glissez pour voir

En pratique, on utilise presque toujours QEMU + KVM pour les VMs Linux/Windows sur serveur x86.

Analogie

Si votre VM est une voiture, QEMU est le châssis. Il définit la structure : combien de roues, quelle carrosserie, quel moteur. Sans châssis, pas de voiture.

QEMU en direct (rare)

On peut lancer une VM directement avec QEMU, par exemple qemu-system-x86_64 -enable-kvm -m 2048 ..., mais c'est fastidieux à gérer. En pratique, on passe par libvirt.

libvirt : le tableau de bord

libvirt est une couche de gestion qui simplifie l'utilisation de QEMU/KVM (et d'autres hyperviseurs).

Ce que fait libvirt

• API unifiée : même interface pour KVM, QEMU, Xen, VirtualBox, VMware...
• Daemon : libvirtd tourne en arrière-plan et gère les VMs
• Outils : virsh (CLI), virt-manager (GUI), virt-install (création)
• Configuration : stocke les définitions de VMs en XML

Ce que libvirt apporte

Sans libvirt	Avec libvirt
Commandes QEMU longues et complexes	virsh start ma-vm
Pas de persistance automatique	VMs définies et persistantes
Gestion manuelle du réseau	Réseaux virtuels préconfigurés
Pas d'interface graphique	virt-manager, cockpit

Glissez pour voir

Analogie

Si votre VM est une voiture, libvirt est le tableau de bord. Vous ne manipulez pas directement le moteur (KVM) ou le châssis (QEMU). Vous utilisez le volant, les pédales, le compteur, l'interface qui rend la conduite facile.

Les outils libvirt

Outil	Type	Usage
virsh	CLI	Gestion en ligne de commande
virt-manager	GUI	Interface graphique desktop
virt-install	CLI	Création de VMs scriptable
cockpit-machines	Web	Interface web (moderne)

Glissez pour voir

Selon votre distribution

libvirtd peut être remplacé par des daemons modulaires (ex. virtqemud pour QEMU, virtnetworkd pour le réseau). Côté utilisateur, virsh et l'API libvirt restent identiques. Consultez la documentation Red Hat pour les détails.

Les objets que vous manipulez

Avec libvirt, vous ne parlez pas de "fichiers QEMU" ou "modules kernel". Vous manipulez des objets avec des noms clairs.

Un point important : dans libvirt, un objet (domain, network, pool) peut être :

• Défini : configuration persistante, stockée sur disque
• Actif : en cours d'exécution / disponible

Un domain peut être défini mais arrêté. Un réseau peut être défini mais inactif. C'est une distinction fondamentale.

Domain (la VM)

Un domain est une machine virtuelle. C'est l'objet principal que vous créez et gérez.

virsh list --all   # Lister tous les domains (actifs et définis)

Pourquoi domain ?

Le terme vient de Xen (l'hyperviseur historique). libvirt a gardé ce vocabulaire pour rester compatible avec différents hyperviseurs.

Network (le réseau virtuel)

Un network est un réseau virtuel. Par défaut, libvirt crée un réseau "default" en NAT.

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

Storage Pool et Volume

Un storage pool est un "conteneur" de disques. Un volume est un disque individuel.

virsh pool-list --all   # Lister les pools (ex: default = /var/lib/libvirt/images/)

Tableau récapitulatif

Objet libvirt	Ce que c'est	État "défini"	État "actif"
Domain	Machine virtuelle	Config XML stockée	VM en cours d'exécution
Network	Réseau virtuel	Config réseau stockée	Bridge créé, DHCP actif
Storage Pool	Conteneur de disques	Chemin configuré	Accessible pour créer des volumes
Volume	Disque virtuel	n/a	Fichier/LV existant

Glissez pour voir

Comment les 3 couches interagissent

Quand vous lancez virsh start ma-vm, voici ce qui se passe :

1. Vous → Envoyez la commande à libvirt (via virsh)

2. libvirt → Lit la définition XML de la VM, vérifie les ressources

3. libvirt → Lance un processus QEMU avec les bons paramètres

4. QEMU → Crée la VM et demande à KVM d'accélérer l'exécution

5. KVM → Utilise le CPU pour exécuter les instructions de la VM

La VM tourne. Vous ne voyez que le résultat : une machine virtuelle qui fonctionne.

Pourquoi cette architecture ?

Cette séparation en couches a des avantages :

Avantage	Explication
Flexibilité	libvirt peut gérer d'autres hyperviseurs (Xen, VirtualBox)
Performance	KVM optimise l'exécution sans que vous vous en occupiez
Simplicité	Vous utilisez des commandes simples, pas des lignes QEMU
Standardisation	Même interface partout (scripts, Ansible, Terraform)

Glissez pour voir

KVM est-il un hyperviseur de type 1 ou de type 2 ?

KVM est généralement classé hyperviseur de type 1 (bare-metal), aux côtés de VMware ESXi et Hyper-V. La raison : KVM s'intègre dans le noyau Linux, qui possède déjà tout ce qu'il faut (ordonnanceur, gestion mémoire, pilotes). Le noyau devient l'hyperviseur et planifie les machines virtuelles directement sur le matériel via VT-x/AMD-V.

La nuance, souvent mal expliquée : comme KVM tourne au sein d'un système Linux hôte complet et s'appuie sur QEMU en espace utilisateur, certains le qualifient de type 2 ou hybride. La formulation juste : un hyperviseur de type 1 à architecture hybride.

KVM face aux autres hyperviseurs

Situer KVM par rapport aux solutions connues aide à comprendre son positionnement : serveur et cloud, open source, performances natives.

Hyperviseur	Type	Licence	Usage typique
KVM	1 (noyau Linux)	open source GPL	serveur, cloud, perfs natives
VMware ESXi	1 (autonome)	propriétaire	entreprise (vSphere)
Xen	1 (micro-noyau)	open source GPL	paravirtualisation
VirtualBox	2 (hosted)	open source GPL	poste de travail
Hyper-V	1	propriétaire	écosystème Windows

Glissez pour voir

KVM est le seul type 1 fondu dans un noyau d'OS généraliste. Pour des tests sur poste, VirtualBox (type 2) suffit ; pour du serveur performant et gratuit, KVM s'impose, d'où sa place de moteur dans Proxmox et OpenStack.

Vérifier que KVM est disponible

Avant de virtualiser, trois commandes confirment que votre machine est prête. Les sorties ci-dessous proviennent d'un poste réel.

# 1. Le CPU supporte-t-il la virtualisation ? (>0 = oui ; vmx=Intel, svm=AMD)
egrep -c '(vmx|svm)' /proc/cpuinfo
# 32

# 2. Diagnostic clair (paquet cpu-checker)
kvm-ok
# INFO: /dev/kvm exists
# KVM acceleration can be used

# 3. Le device et les modules charges
ls /dev/kvm                 # crw-rw---- 1 root kvm ...
lsmod | grep kvm            # kvm_intel ... / kvm ...

Si /dev/kvm est absent malgré un flag vmx/svm présent, la virtualisation est désactivée dans le BIOS/UEFI : activez-la.

KVM est-il gratuit, et qui l'utilise ?

KVM est open source sous licence GPL et fait partie intégrante du noyau Linux. Aucune licence payante : vous l'utilisez librement sur Ubuntu, Debian, Rocky ou Fedora. Les éditeurs entreprise (Red Hat) facturent du support et de l'outillage, pas KVM lui-même.

Côté adoption, KVM est le moteur de Proxmox VE, OpenStack (hyperviseur par défaut), KubeVirt / OpenShift Virtualization, et de nombreux clouds (Google Cloud, OVHcloud, Outscale). La brique de gestion libvirt suit une cadence mensuelle (version 12.x en 2026).

Erreurs fréquentes

Confusion	Réalité
"J'installe KVM"	Vous installez QEMU + libvirt + outils. KVM est la partie noyau qui permet l'accélération, et il faut que la machine l'autorise (BIOS/UEFI + CPU compatible).
"KVM ne marche pas"	Souvent un problème de libvirtd (ou daemon modulaire), de permissions, ou de virtualisation non activée dans le BIOS.
"C'est lent"	KVM n'est peut-être pas utilisé (option -enable-kvm manquante, ou virtualisation désactivée).
"virsh ne trouve pas ma VM"	La VM n'est pas définie dans libvirt (elle n'existe que comme fichier disque).

Glissez pour voir

À retenir

1. KVM = module kernel = accélération matérielle (le "turbo")

2. QEMU = émulateur/virtualiseur = crée les VMs (le "châssis")

3. libvirt = couche de gestion = API + daemon + outils (le "tableau de bord")

4. Vous utilisez libvirt au quotidien (virsh, virt-manager), pas QEMU directement

5. Les objets libvirt : domain (VM), network (réseau), storage pool/volume (disques)

6. Défini vs Actif : un objet peut exister en configuration sans être en fonctionnement

Testez votre compréhension

Avant de continuer, vérifiez que vous pouvez répondre à ces questions :

• ✅ Quel est le rôle de KVM ? De QEMU ? De libvirt ?
• ✅ Pourquoi utilise-t-on libvirt plutôt que QEMU directement ?
• ✅ Qu'est-ce qu'un "domain" dans le vocabulaire libvirt ?
• ✅ Quelle est la différence entre un objet "défini" et "actif" ?

FAQ : questions fréquentes sur KVM

Qu'est-ce que KVM ?

KVM (Kernel-based Virtual Machine) est un module open source du noyau Linux qui transforme Linux en hyperviseur. Intégré au noyau depuis 2007, il exploite les extensions de virtualisation du processeur (Intel VT-x ou AMD-V) pour des machines virtuelles aux performances quasi natives.

KVM est-il un hyperviseur de type 1 ou de type 2 ?

KVM est généralement classé hyperviseur de type 1 (bare-metal) car le noyau Linux devient lui-même l'hyperviseur, avec accès direct au matériel via VT-x/AMD-V. Comme il s'appuie sur un système Linux hôte complet, on parle de type 1 à architecture hybride.

Quelle différence entre KVM, QEMU et libvirt ?

KVM est le module noyau qui accélère CPU et mémoire via le matériel. QEMU est l'émulateur en espace utilisateur qui fournit les périphériques virtuels (disque, réseau). libvirt est la couche de gestion (API, démon, outils virsh et virt-manager) qui pilote le tout.

KVM ou VirtualBox / VMware : quelles différences ?

KVM est un hyperviseur de type 1 open source intégré au noyau Linux, orienté serveur et cloud, gratuit. VirtualBox est un hyperviseur de type 2 (hosted) pour le poste de travail. VMware ESXi est un type 1 propriétaire pour l'entreprise. KVM offre des performances natives sans licence payante.

KVM est-il gratuit ?

Oui. KVM est open source sous licence GPL et fait partie intégrante du noyau Linux. Aucune licence payante pour le module. Les distributions entreprise comme RHEL facturent du support et de l'outillage, pas KVM, librement utilisable sur toute distribution Linux.

Comment savoir si mon CPU supporte KVM ?

Vérifiez les extensions du CPU avec egrep -c '(vmx|svm)' /proc/cpuinfo : un résultat supérieur à 0 indique un CPU compatible. Confirmez avec kvm-ok (paquet cpu-checker) et la présence de /dev/kvm. Si le device manque malgré un flag présent, activez la virtualisation dans le BIOS/UEFI.

Prochaines étapes

Installer KVM/libvirt Installez et configurez votre environnement de virtualisation

Type 1 vs Type 2 Comprendre les différences entre hyperviseurs

Proxmox VE Proxmox utilise KVM sous le capot, découvrez l'interface web

Références

• libvirt API concepts, Concepts fondamentaux (domain, network, storage, defined/active)
• libvirt Storage Management, Pools et volumes
• libvirt Domain XML format, Structure XML des VMs
• Red Hat, Virtualization in RHEL 9, Daemons modulaires et évolutions
• Oracle Linux 9, Virtualization, Notes de version et dépréciations

×

📖 Voir la documentation →