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.

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-system-x86 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-system-x86), 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-system-x86 \
  libvirt-daemon-system \
  libvirt-clients \
  virtinst \
  virt-manager

Détail des paquets :

Paquet	Rôle
qemu-system-x86	Émulateur QEMU pour x86, 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

Pourquoi qemu-system-x86 et pas qemu-kvm ?

Sur la famille Debian, qemu-kvm n'est pas un paquet. C'est un nom virtuel, une étiquette que plusieurs paquets réels déclarent fournir. Celui qui contient l'émulateur x86 s'appelle qemu-system-x86, et c'est lui qui porte la ligne Provides: qemu-kvm. Vous pouvez le constater avec apt-cache show qemu-system-x86.

Tant qu'un seul paquet fournit ce nom, apt choisit à votre place et l'installation passe sans rien signaler. Dès que deux paquets ou plus le fournissent, apt refuse de trancher et s'arrête sur une erreur de résolution :

Package qemu-kvm is a virtual package provided by:
  qemu-system-x86-hwe 1:10.2.1+ds-1ubuntu4.3
  qemu-system-x86 1:10.2.1+ds-1ubuntu3.2
You should explicitly select one to install.

Error: Package 'qemu-kvm' has no installation candidate

C'est ce qui se produit sur Ubuntu 26.04, où qemu-system-x86-hwe (issu du paquet source qemu-hwe, qui livre un QEMU plus récent) est venu s'ajouter comme second fournisseur. Partout ailleurs, un fournisseur unique laisse apt résoudre, et le problème reste invisible :

Distribution	Fournisseurs de qemu-kvm	Résultat de apt install qemu-kvm
Debian 12, 13 et 14	1 seul, qemu-system-x86	Passe
Ubuntu 24.04 (noble)	1 seul, qemu-system-x86	Passe
Ubuntu 26.04 (resolute)	2, dont qemu-system-x86-hwe	Échoue
RHEL, Rocky, Alma, Fedora	sans objet, paquet réel	Passe

Glissez pour voir

Nommer qemu-system-x86 directement fonctionne dans tous ces cas, et continuera de fonctionner le jour où une distribution ajoutera un fournisseur supplémentaire, comme Ubuntu vient de le faire. La dernière ligne du tableau explique au passage pourquoi l'onglet RHEL parle toujours de qemu-kvm : là-bas, le paquet existe réellement.

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 des paquets

La documentation Red Hat pour RHEL 9 et 10 nomme désormais les paquets un par un, plutôt que de passer par le groupe @virtualization :

sudo dnf install -y qemu-kvm libvirt virt-install virt-viewer

Paquet	Rôle
qemu-kvm	QEMU avec accélération KVM, vrai paquet ici, contrairement à Debian
libvirt	Daemon et bibliothèques
virt-install	Création de VMs en CLI
virt-viewer	Console graphique

Glissez pour voir

Le groupe @virtualization existe toujours et fonctionne, notamment sur Fedora. Il installe un ensemble plus large, défini par la distribution, ce qui reste pratique sur un poste de travail et discutable sur un serveur, où l'on veut maîtriser ce qui est présent.

Activer les démons, qui ne s'appellent plus forcément libvirtd

RHEL 9 et 10 sont passés aux démons modulaires : il n'y a plus un libvirtd unique mais un service par domaine de responsabilité, activé par socket. Démarrer libvirtd sur ces systèmes ne donne donc rien d'utile.

for drv in qemu network nodedev nwfilter secret storage interface; do
  sudo systemctl start "virt${drv}d.socket"
  sudo systemctl start "virt${drv}d-ro.socket"
done

Vérifiez ensuite ce qui écoute réellement, c'est le contrôle qui ne ment pas :

systemctl list-units 'virt*d.socket' --state=active

Un seul modèle à retenir : ce qui existe sur VOTRE hôte

libvirtd monolithique et démons modulaires cohabitent dans la nature, et aucune règle simple ne dit lequel vous avez. La commande qui tranche est la même partout :

systemctl list-unit-files 'libvirtd*.socket' 'virt*d.socket'

Ce que cette liste contient décide de la suite. Le reste du guide parle de libvirtd parce que c'est encore le cas le plus répandu sur Debian et Ubuntu ; transposez au démon modulaire correspondant si votre système est dans l'autre configuration.

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

Installer les paquets ne démarre pas toujours le service. libvirtd est le daemon qui détient les définitions de vos machines et parle à QEMU en votre nom : sans lui, virsh n'a personne à qui s'adresser. Les deux mots de la commande ci-dessous répondent à deux besoins différents, enable inscrit le service au démarrage de la machine, --now le lance immédiatement sans attendre un redémarrage.

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 gère les machines. La méthode courante consiste à ajouter son utilisateur aux groupes libvirt et kvm, ce qui évite de taper sudo à chaque commande.

Ce n'est pas un réglage de confort. L'appartenance au groupe libvirt donne un accès plein au driver qemu:///system, celui qui pilote la virtualisation côté serveur : créer et détruire des machines, mais aussi rattacher un périphérique PCI ou USB de l'hôte, ouvrir un disque brut, définir des réseaux. Autrement dit, elle confère une administration de l'hyperviseur, et non la permission de lancer quelques commandes. Sur un poste personnel, c'est le compromis normal ; sur un serveur partagé, cela mérite d'être décidé plutôt que subi.

Plus fin que le groupe : polkit

libvirt s'appuie aussi sur polkit, qui permet d'autoriser à la granularité de l'action plutôt que du groupe entier. Une règle peut par exemple accorder la lecture seule à une équipe de supervision, qui a besoin de voir l'état des machines sans pouvoir les modifier :

/etc/polkit-1/rules.d/60-libvirt-lecture.rules

polkit.addRule(function(action, subject) {
  if (action.id == "org.libvirt.unix.monitor" &&
      subject.isInGroup("supervision")) {
    return polkit.Result.YES;
  }
});

L'action org.libvirt.unix.manage correspond à l'accès complet, monitor à la consultation. C'est le moyen de donner à chacun ce dont il a besoin, sans verser toute une équipe dans le groupe libvirt.

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.

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.

Pourquoi virt-manager demande encore un mot de passe

Les groupes gouvernent l'accès à la socket libvirt, donc les commandes que vous tapez. Les interfaces graphiques, virt-manager et Cockpit, passent en plus par Polkit, un second mécanisme d'autorisation qui a ses propres règles et interroge l'utilisateur par une fenêtre. Voir surgir une demande de mot de passe alors que id affiche bien libvirt n'est donc pas le signe d'une configuration ratée : les deux systèmes coexistent, et votre appartenance aux groupes reste correcte.

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

libvirt expose deux espaces de travail distincts, et c'est la source de confusion la plus fréquente après les groupes. Le mode system (qemu:///system) appartient au daemon lancé par la machine : c'est là que vivent le réseau default, le pool de stockage et les VMs d'un serveur. Le mode session (qemu:///session) crée un second univers, propre à votre utilisateur, avec ses propres VMs et sans le réseau default. Une sortie vide de virsh net-list, alors que tout semble installé, signifie presque toujours que vous interrogez session quand vous pensiez parler à 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

Un pool de stockage est simplement un répertoire que libvirt surveille pour y ranger les disques virtuels de vos machines. Contrairement au réseau default, il n'est pas créé partout : certaines distributions le fournissent, une installation minimale le laisse absent, et virt-manager le crée parfois au premier lancement. Commencez donc par regarder ce que vous avez avant de le définir, la commande ci-dessous ne modifie rien.

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.

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

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

2. Installer les paquets : qemu-system-x86, libvirt-daemon-system, virtinst (Debian/Ubuntu, où qemu-kvm n'est qu'un nom virtuel) 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

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 →