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 : l'accélération dans le noyau

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

Le rôle de KVM se résume à une seule chose, mais elle est décisive : laisser les instructions de la machine virtuelle s'exécuter directement sur le processeur physique, au lieu d'être traduites une à une par un logiciel. Les trois points ci-dessous sont les conséquences de ce mécanisme unique.

• 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 se limite à l'accélération. Sans lui, les VMs tourneraient en émulation logicielle (très lent). Avec lui, elles atteignent des performances proches du bare-metal.

QEMU : la création de la machine virtuelle

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

Ce que fait QEMU

Là où KVM accélère, QEMU construit. C'est le processus en espace utilisateur qui présente à la VM un jeu de matériel virtuel (processeur, mémoire, disques, cartes réseau) et qui relaie ses entrées-sorties vers le système hôte. Les trois points ci-dessous couvrent ce périmètre, du plus visible (créer la VM) au plus technique (gérer chaque périphérique émulé).

• 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.

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 : la couche de gestion

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

Ce que fait libvirt

Lancer une VM directement avec QEMU exige une ligne de commande de plusieurs dizaines d'arguments, à retaper à chaque démarrage. libvirt encapsule cette complexité derrière une API stable et un daemon qui mémorise la configuration. Les quatre points ci-dessous décrivent ce qu'il ajoute par-dessus QEMU/KVM.

• 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

Ce tableau oppose deux façons de piloter la même VM. La colonne de gauche montre le quotidien sans libvirt : commandes interminables, aucune persistance, réseau à monter à la main. La colonne de droite est ce que vous gagnez concrètement ; retenez surtout la persistance, car c'est elle qui permet de retrouver ses VMs après un redémarrage de l'hôte sans les recréer.

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

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

Ce tableau croise les quatre objets libvirt avec la distinction défini / actif vue plus haut. Lisez-le colonne par colonne : la même VM (domain) est une simple configuration XML sur disque quand elle est définie, et un processus QEMU vivant quand elle est active. Le volume fait exception, il n'a pas d'état « défini » propre car il existe dès que le fichier ou le logical volume est créé.

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

Ces quatre confusions reviennent chez presque tous les débutants, et elles découlent toutes du fait que « KVM » désigne dans le langage courant un ensemble dont KVM n'est qu'une brique. La première ligne est la plus importante : comprendre qu'installer « KVM » revient en fait à installer QEMU, libvirt et leurs outils évite la moitié des questions suivantes. Lisez la colonne de droite comme le diagnostic à poser avant de chercher plus loin.

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 (exécution directe sur le CPU)

2. QEMU = émulateur/virtualiseur = crée les VMs et leur matériel virtuel

3. libvirt = couche de gestion = API + daemon + outils (virsh, virt-manager)

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

Ces questions reprennent les points sur lesquels les lecteurs butent le plus après une première lecture : le classement type 1 / type 2, la gratuité réelle de KVM, et la place de chaque couche. Parcourez-les pour vérifier qu'aucune zone d'ombre ne subsiste avant de passer à l'installation.

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.

Pour aller plus loin

• Réseau KVM : NAT vs Bridge : Le vocabulaire network de libvirt prend sa forme concrète, avec virbr0 et dnsmasq.
• Stockage libvirt : pools et volumes : Les objets pool et volume vus ici deviennent des fichiers QCOW2 sur le disque.
• Créer une VM avec virt-manager et virt-install : Le premier domain défini puis démarré, pour vérifier que le modèle mental tient.

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 →