Installer KVM/libvirt sur Linux

Vous voulez créer des machines virtuelles sur votre serveur Linux ? Ce guide vous accompagne pour installer KVM/libvirt en 15 minutes. À la fin, vous aurez un hôte de virtualisation fonctionnel, prêt à créer vos premières VMs.

Installation express (5 commandes)

Si vous êtes pressé et sur une distribution standard (Ubuntu/Debian ou RHEL/Rocky) :

Ubuntu/Debian

# 1. Vérifier le CPU
grep -Ec '(vmx|svm)' /proc/cpuinfo   # Doit être > 0

# 2. Installer
sudo apt install -y qemu-kvm libvirt-daemon-system libvirt-clients virtinst

# 3. Activer
sudo systemctl enable --now libvirtd

# 4. Permissions
sudo usermod -aG libvirt,kvm $USER && newgrp libvirt

# 5. Tester
virt-host-validate && virsh -c qemu:///system list --all

RHEL/Rocky/Fedora

# 1. Vérifier le CPU
grep -Ec '(vmx|svm)' /proc/cpuinfo   # Doit être > 0

# 2. Installer
sudo dnf install -y @virtualization

# 3. Activer
sudo systemctl enable --now libvirtd

# 4. Permissions
sudo usermod -aG libvirt $USER && newgrp libvirt

# 5. Tester
virt-host-validate && virsh -c qemu:///system list --all

Ça fonctionne ?

Si virt-host-validate affiche PASS sur /dev/kvm et que virsh list répond sans erreur, vous êtes prêt ! Le reste du guide explique les détails et résout les problèmes éventuels.

Ce que vous allez apprendre

• Vérifier que votre CPU supporte la virtualisation
• Installer les paquets nécessaires selon votre distribution
• Configurer les permissions pour gérer les VMs sans sudo
• Valider l'installation avec les commandes de diagnostic

Prérequis

• Un serveur ou PC avec un processeur Intel VT-x ou AMD-V
• Un système Linux (Debian/Ubuntu ou RHEL/Rocky/Fedora)
• Accès root ou sudo

Rappel : les 3 couches

Avant de continuer, assurez-vous de comprendre la différence entre KVM (accélération matérielle), QEMU (émulateur) et libvirt (gestion). Consultez le guide Concepts fondamentaux si ce n'est pas clair.

Étape 1 : Vérifier le support CPU

La virtualisation KVM nécessite un processeur avec les extensions Intel VT-x ou AMD-V. Sans ce support matériel, vos VMs fonctionneront en émulation pure (très lent).

Vérifier les extensions CPU

Le fichier /proc/cpuinfo expose un bloc de flags par cœur logique. Compter les lignes contenant vmx ou svm revient donc à compter les cœurs capables d'accélérer une machine virtuelle. Ce que vous cherchez ici est binaire : zéro ou pas zéro. La valeur exacte n'a aucune importance, elle reflète simplement le nombre de cœurs logiques vus par le noyau.

# Compter le nombre de cœurs avec support virtualisation
grep -Ec '(vmx|svm)' /proc/cpuinfo

Résultat attendu : un nombre supérieur à 0.

Résultat	Signification
0	Pas de support ou désactivé dans le BIOS
4, 8, 16...	Support activé (nombre = cœurs logiques)

Glissez pour voir

Identifier le type de CPU

Savoir si votre processeur est Intel ou AMD détermine le module noyau que Linux doit charger, et donc le nom à chercher plus loin dans la sortie de lsmod. La commande ci-dessous affiche la première ligne de flags trouvée : si elle contient vmx, vous êtes sur Intel, si elle contient svm, sur AMD. Vous n'avez jamais à charger ce module à la main, le noyau s'en charge au démarrage dès que le matériel le permet.

# Intel ou AMD ?
grep -E 'vmx|svm' /proc/cpuinfo | head -1

Extension	Fabricant	Module kernel
vmx	Intel	kvm_intel
svm	AMD	kvm_amd

Glissez pour voir

Virtualisation désactivée ?

Si le résultat est 0 mais que vous avez un CPU récent :

1. Redémarrez et accédez au BIOS/UEFI
2. Cherchez Intel VT-x, AMD-V, SVM ou Virtualization Technology
3. Activez l'option et sauvegardez
4. Relancez le test après redémarrage

Étape 2 : Installer les paquets

L'installation diffère selon votre distribution. Sélectionnez l'onglet correspondant :

Debian / Ubuntu

Mise à jour du système

Les paquets de virtualisation dépendent étroitement de la version du noyau installée. Mettre le système à jour avant l'installation évite le cas classique où qemu-kvm arrive dans une version plus récente que les modules noyau chargés, ce qui produit des erreurs difficiles à relier à leur cause.

sudo apt update && sudo apt upgrade -y

Installation des paquets KVM/libvirt

Une installation de virtualisation se compose de trois briques distinctes : le moteur d'exécution (qemu-kvm), le service de gestion (libvirt-daemon-system) et les outils que vous manipulez (libvirt-clients, virtinst). Le tableau qui suit les détaille. Sur un serveur sans écran, retirez virt-manager de la commande, il tire toute une chaîne de dépendances graphiques inutiles.

sudo apt install -y \
  qemu-kvm \
  libvirt-daemon-system \
  libvirt-clients \
  virtinst \
  virt-manager

Détail des paquets :

Paquet	Rôle
qemu-kvm	QEMU avec accélération KVM
libvirt-daemon-system	Daemon libvirtd + configuration système
libvirt-clients	Outils CLI (virsh)
virtinst	Outil virt-install pour créer des VMs
virt-manager	Interface graphique (optionnel sur serveur)

Glissez pour voir

bridge-utils n'est plus nécessaire

Les anciens tutoriels mentionnent souvent bridge-utils (commande brctl). Ce paquet est obsolète, utilisez iproute2 (ip link, bridge) qui est déjà installé. libvirt gère les bridges automatiquement.

Vérification avec kvm-ok (Ubuntu)

Là où grep /proc/cpuinfo ne regarde que les capacités du processeur, kvm-ok va plus loin : il vérifie que le fichier de périphérique /dev/kvm existe réellement, ce qui prouve que le module noyau est chargé et que le BIOS n'a pas désactivé l'extension. C'est la vérification la plus fiable des deux.

sudo apt install -y cpu-checker
kvm-ok

Résultat attendu :

INFO: /dev/kvm exists
KVM acceleration can be used

RHEL / Rocky / Alma

Mise à jour du système

Sur la famille RHEL, la mise à jour préalable a un effet supplémentaire : elle aligne les paquets qemu-kvm et libvirt sur la version du noyau du dépôt, alors qu'un système en retard de plusieurs mois peut se retrouver avec des modules incompatibles après le premier redémarrage.

sudo dnf update -y

Installation du groupe de virtualisation

@virtualization est un groupe de paquets, pas un paquet unique : la syntaxe @ indique à dnf d'installer l'ensemble défini par la distribution. L'intérêt est que Red Hat maintient la cohérence de cette liste d'une version à l'autre, là où une installation paquet par paquet finit par oublier une dépendance.

Ce groupe installe automatiquement :

Paquet	Rôle
qemu-kvm	QEMU avec accélération KVM
libvirt	Daemon et bibliothèques
libvirt-client	Outils CLI (virsh)
virt-install	Création de VMs en CLI
virt-viewer	Console graphique

Glissez pour voir

Installation de virt-manager (optionnel)

virt-manager est une interface graphique qui se connecte au même service libvirt que virsh. Sur un serveur sans session graphique, ne l'installez pas : vous pourrez de toute façon le lancer depuis votre poste et pointer vers l'hôte distant en SSH.

sudo dnf install -y virt-manager

Vérification du support KVM

Deux modules doivent apparaître : kvm, générique, et son complément spécifique au fabricant, kvm_intel ou kvm_amd. La troisième colonne est un compteur de références : il reste à 0 tant qu'aucune machine virtuelle ne tourne et grimpe dès qu'une VM démarre. La quatrième colonne, quand elle est présente, liste les modules qui s'appuient sur celui de la ligne.

lsmod | grep kvm

Résultat attendu (Intel) :

kvm_intel             380928  0
kvm                  1036288  1 kvm_intel

Résultat attendu (AMD) :

kvm_amd               139264  0
kvm                  1036288  1 kvm_amd

Fedora

Mise à jour du système

Fedora avance vite : le noyau change à chaque mise à jour importante, et les modules KVM doivent correspondre au noyau en cours d'exécution. Redémarrez si la mise à jour a installé un nouveau noyau, sinon lsmod ne montrera rien.

sudo dnf update -y

Installation du groupe de virtualisation

Fedora utilise le même groupe @virtualization que RHEL, mais avec des versions nettement plus récentes de QEMU et de libvirt. C'est un avantage pour tester des fonctionnalités récentes, et un inconvénient si vous voulez reproduire à l'identique le comportement d'un serveur de production sous RHEL.

sudo dnf install -y @virtualization

Vérification

Ces deux commandes se complètent. lsmod répond à la question « le noyau est-il prêt ». virt-host-validate va plus loin en testant l'accès effectif à /dev/kvm avec vos droits actuels, ainsi que la présence des périphériques réseau nécessaires. Les lignes préfixées par LXC: concernent un autre pilote de libvirt et ne vous concernent pas ici.

# Modules KVM chargés ?
lsmod | grep kvm

# Outil de vérification
virt-host-validate

Résultat attendu de virt-host-validate :

QEMU: Checking for hardware virtualization      : PASS
QEMU: Checking if device /dev/kvm exists        : PASS
QEMU: Checking if device /dev/kvm is accessible : PASS
...

Étape 3 : Activer le service libvirt

Le daemon libvirt doit être démarré et activé au boot.

1. Activer et démarrer le service

   sudo systemctl enable --now libvirtd

2. Vérifier le statut

   sudo systemctl status libvirtd

   Résultat attendu : Active: active (running)

3. Vérifier la socket

   ls -la /run/libvirt/libvirt-sock

   Ce fichier socket permet la communication avec libvirt.

Démons modulaires (RHEL 9+, Fedora 34+, openSUSE)

Certaines distributions modernes utilisent des démons séparés au lieu de libvirtd :

• virtqemud, gestion des VMs QEMU/KVM
• virtnetworkd, réseaux virtuels
• virtstoraged, pools de stockage

Si libvirtd n'existe pas sur votre système, activez les sockets modulaires :

sudo systemctl enable --now virtqemud.socket virtnetworkd.socket virtstoraged.socket

Les commandes virsh restent identiques dans les deux modes.

Étape 4 : Configurer les permissions

Par défaut, seul root peut gérer les VMs. Pour éviter d'utiliser sudo à chaque commande, ajoutez votre utilisateur aux groupes appropriés.

Debian / Ubuntu

# Ajouter l'utilisateur aux groupes libvirt et kvm
sudo usermod -aG libvirt $USER
sudo usermod -aG kvm $USER

RHEL / Rocky / Fedora

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

Déconnexion requise

Les changements de groupe ne prennent effet qu'après déconnexion/reconnexion de votre session. Vous pouvez aussi utiliser :

newgrp libvirt

pour activer le groupe dans le terminal courant.

Interfaces graphiques et Polkit

Si vous utilisez virt-manager ou Cockpit, certaines distributions s'appuient sur Polkit pour les autorisations (en plus des groupes). Si l'interface demande un mot de passe malgré les groupes configurés, c'est normal, Polkit gère les droits différemment.

Vérifier l'appartenance aux groupes

Cette vérification cause plus de confusion que n'importe quelle autre étape du guide, parce que Linux distingue les groupes enregistrés dans /etc/group des groupes actifs dans votre session en cours. usermod écrit dans le fichier immédiatement, mais votre shell garde la liste chargée à l'ouverture de session.

groups $USER

Résultat attendu : ... libvirt kvm ...

Vérifier les groupes effectifs

La commande groups $USER montre les groupes configurés, mais pas forcément ceux actifs dans votre session. Pour voir les groupes effectifs :

id

Si libvirt et kvm n'apparaissent pas dans la ligne groups=..., vous devez vous déconnecter et reconnecter.

Étape 5 : Configurer l'URI par défaut

Résumé : libvirt a deux modes, system (serveurs) et session (desktop). Si virsh net-list est vide sans sudo, vous êtes probablement connecté à session au lieu de system.

Solution rapide (recommandée pour serveurs) :

# Ajouter dans ~/.bashrc ou ~/.zshrc
export LIBVIRT_DEFAULT_URI="qemu:///system"
source ~/.bashrc

Vérification :

virsh uri
# Doit afficher : qemu:///system

En savoir plus

Pour comprendre la différence entre qemu:///system et qemu:///session (stockage, réseau, permissions), consultez le guide Commandes virsh qui détaille ce piège classique.

Étape 6 : Valider l'installation

Plusieurs commandes permettent de confirmer que tout fonctionne.

Test 1 : Lister les VMs

C'est le test le plus simple, et son but n'est pas de voir des machines : il vérifie que virsh parvient à ouvrir la socket du service libvirt avec vos droits actuels. Une liste vide est donc un succès. L'échec, lui, se manifeste par un message de permission plutôt que par une absence de résultat.

# Si LIBVIRT_DEFAULT_URI est configuré :
virsh list --all

# Sinon, précisez l'URI :
virsh -c qemu:///system list --all

Résultat attendu (installation fraîche) :

 Id   Name   State
--------------------

Une liste vide est normale, vous n'avez pas encore créé de VM.

Permission denied ?

Si vous obtenez Failed to connect socket to '/var/run/libvirt/libvirt-sock': Permission denied :

1. Vérifiez que vous êtes dans le groupe libvirt : id | grep libvirt
2. Si le groupe n'apparaît pas : déconnectez-vous et reconnectez-vous
3. En attendant, utilisez sudo devant les commandes

Test 2 : Vérifier le réseau par défaut

libvirt crée un réseau nommé default qui fournit du NAT et un serveur DHCP aux VMs via le pont virbr0. Sans lui, vos machines démarreront mais n'obtiendront aucune adresse IP. Trois colonnes comptent dans la sortie : State doit valoir active maintenant, Autostart doit valoir yes pour que le réseau revienne après un redémarrage, et Persistent confirme que la définition est écrite sur disque et non seulement en mémoire.

virsh net-list --all

Résultat attendu :

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

D'où vient le réseau default ?

Distribution	Paquet responsable	Comportement
Ubuntu/Debian	libvirt-daemon-config-network	Crée default + virbr0 automatiquement
RHEL/Rocky	Inclus dans @virtualization	Crée default au démarrage de libvirtd

Glissez pour voir

Si vous avez installé uniquement libvirt-daemon-system (sans la config réseau), le réseau default peut être absent. Dans ce cas, installez le paquet manquant ou créez le réseau manuellement.

Si le réseau default n'est pas actif (State = inactive) :

virsh net-start default
virsh net-autostart default

Test 3 : Vérifier (et créer) le pool de stockage

Le pool default peut exister ou non selon votre distribution et méthode d'installation.

virsh pool-list --all

Si le pool existe déjà (virt-manager l'a peut-être créé) :

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

Si le pool est absent (fréquent sur installation minimale) :

Créer le pool default :

# Définir le pool (pointe vers /var/lib/libvirt/images/)
virsh pool-define-as default dir --target /var/lib/libvirt/images

# Créer le répertoire si nécessaire
sudo mkdir -p /var/lib/libvirt/images

# Démarrer et activer au boot
virsh pool-start default
virsh pool-autostart default

Vérification :

virsh pool-list --all

Résultat attendu :

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

Le pool default pointe vers /var/lib/libvirt/images/.

Test 4 : Validation complète (recommandé)

virt-host-validate déroule une série de contrôles et affiche un verdict par ligne. C'est le seul test qui vérifie l'ensemble de la chaîne : matériel, module noyau, droits d'accès aux périphériques et contrôleurs cgroup. Lisez-le de haut en bas et arrêtez-vous à la première ligne FAIL, les suivantes en découlent souvent. La sortie réelle contient aussi des lignes préfixées LXC:, propres au pilote conteneur de libvirt, sans rapport avec vos machines virtuelles.

virt-host-validate

Exemple de résultat :

  QEMU: Checking for hardware virtualization                  : PASS
  QEMU: Checking if device /dev/kvm exists                    : PASS
  QEMU: Checking if device /dev/kvm is accessible             : PASS
  QEMU: Checking if device /dev/vhost-net exists              : PASS
  QEMU: Checking if device /dev/net/tun exists                : PASS
  QEMU: Checking for cgroup 'memory' controller support       : PASS
  QEMU: Checking for device assignment IOMMU support          : WARN (...)
  QEMU: Checking for secure guest support                     : WARN (...)

Interpréter les résultats

Résultat	Signification
PASS	Fonctionnalité disponible
WARN	Fonctionnalité optionnelle absente (IOMMU, Secure Guest...)
FAIL	Problème bloquant à corriger

Glissez pour voir

Les WARN sur IOMMU (passthrough PCI) et Secure Guest ne bloquent pas l'usage basique de KVM. Seuls les tests /dev/kvm et hardware virtualization doivent impérativement être PASS.

Récapitulatif des fichiers importants

Ces cinq chemins sont ceux vers lesquels vous reviendrez à chaque incident. Deux méritent une attention particulière : /var/lib/libvirt/images/ est l'emplacement qui remplit le disque système si vous ne surveillez pas la taille des disques virtuels, et /var/log/libvirt/qemu/ contient un fichier de journal par machine virtuelle, c'est là que se trouve la vraie raison d'un démarrage qui échoue, pas dans journalctl.

Chemin	Contenu
/etc/libvirt/	Configuration libvirt
/etc/libvirt/qemu/	Définitions XML des VMs
/var/lib/libvirt/images/	Disques virtuels (pool default)
/run/libvirt/libvirt-sock	Socket de communication
/var/log/libvirt/qemu/	Logs des VMs

Glissez pour voir

Erreurs fréquentes

Trois des quatre lignes ci-dessous se ramènent à la même cause : le shell n'a pas rechargé vos groupes, ou virsh parle au mauvais service. Avant de chercher plus loin, exécutez id puis virsh uri : ces deux commandes éliminent la majorité des symptômes en dix secondes.

Erreur	Cause probable	Solution
Permission denied sur socket	Groupe libvirt non actif	Se déconnecter/reconnecter ou newgrp libvirt
/dev/kvm n'existe pas	Virtualisation désactivée	Activer VT-x/AMD-V dans le BIOS, puis modprobe kvm kvm_intel
virsh net-list vide	Connecté à qemu:///session	Utiliser virsh -c qemu:///system ou configurer LIBVIRT_DEFAULT_URI
libvirtd inactif / n'existe pas	Service non démarré ou démons modulaires	systemctl enable --now libvirtd ou activer les sockets modulaires

Glissez pour voir

Plus de dépannage

Pour d'autres erreurs (pool absent, réseau inactif, problèmes de permissions avancés), consultez le guide Commandes virsh qui inclut une section dépannage détaillée.

À retenir

1. Vérifier le CPU avec grep -Ec '(vmx|svm)' /proc/cpuinfo, doit être > 0

2. Installer les paquets : qemu-kvm, libvirt-daemon-system, virtinst (Debian) ou @virtualization (RHEL)

3. Activer libvirt : systemctl enable --now libvirtd (ou sockets modulaires sur distros récentes)

4. Configurer les permissions : usermod -aG libvirt,kvm $USER puis se reconnecter

5. Valider avec virt-host-validate, /dev/kvm doit être PASS

Pas besoin de tout retenir

Le bloc Installation express en début de guide contient les 5 commandes essentielles. Les détails (URI, pool, réseau) sont à consulter en cas de problème.

Pour aller plus loin

• Stockage libvirt : pools et volumes : Le pool default créé à l'installation se configure et s'étend proprement.
• Créer une VM avec virt-manager et virt-install : La première VM sur l'hyperviseur qui vient d'être installé.
• Les 15 commandes virsh essentielles : Le minimum vital pour vérifier l'état de l'hôte et de ses domaines.

Références

• Ubuntu Server, libvirt, Documentation officielle Ubuntu
• Red Hat, Installing virtualization packages, Documentation RHEL 9
• ArchWiki, KVM, Guide communautaire détaillé
• libvirt.org, Documentation officielle libvirt

×

📖 Voir la documentation →