Créer une VM KVM : virt-manager et virt-install

Vous avez installé KVM/libvirt et vous voulez créer votre première VM ? Ce guide vous montre les deux méthodes : virt-manager (interface graphique) et virt-install (ligne de commande). À la fin, vous saurez créer une VM fonctionnelle en moins de 10 minutes.

Les deux outils pilotent la même bibliothèque libvirt et produisent des VMs strictement identiques : le choix ne porte donc que sur la façon de saisir les paramètres, jamais sur le résultat. Vous pouvez créer une VM avec l'un et l'administrer avec l'autre.

Méthode	Pour qui	Avantage
virt-manager	Débutants, homelab	Visuel, intuitif
virt-install	Sysadmins, automatisation	Scriptable, reproductible

Prérequis

KVM/libvirt installé et fonctionnel (guide installation)
Réseau default actif (virsh net-list → default active)
Pool de stockage configuré (virsh pool-list → default active)
Une image ISO d'installation (Ubuntu Server, Debian, Rocky Linux...)

Ce que vous allez apprendre

Créer une VM avec virt-manager (workflow visuel)
Créer une VM avec virt-install (workflow CLI, scriptable)
Choisir entre BIOS et UEFI
Configurer les paramètres essentiels : CPU, RAM, disque, réseau

Méthode 1 : virt-manager (interface graphique)

virt-manager est l'outil graphique officiel pour gérer les VMs libvirt. Idéal pour :

Découvrir KVM sans apprendre les commandes
Gérer un homelab avec quelques VMs
Accéder aux consoles graphiques facilement

Lancer virt-manager

virt-manager est un client : il se connecte au démon libvirtd (ou virtqemud sur les distributions récentes), localement par défaut. Votre compte doit appartenir au groupe libvirt, sinon l'application démarre mais n'affiche aucun hyperviseur.

virt-manager

Si vous êtes sur un serveur distant (SSH avec X11 forwarding) :

ssh -X user@serveur
virt-manager

Créer une VM pas à pas

L'assistant enchaîne cinq écrans, et un seul mérite votre attention : l'étape 6, où la case Customize configuration before install conditionne l'accès au choix du firmware. Si vous la laissez décochée, la VM sera créée en BIOS et repasser en UEFI après coup implique de réinstaller le système. Les autres écrans se corrigent sans conséquence après création.

Nouvelle VM

Cliquez sur File → New Virtual Machine, ou sur l'icône en forme de plus dans la barre d'outils
Choisir la source d'installation
- Sélectionnez Local install media (ISO image or CDROM)
- Cliquez Forward
Sélectionner l'ISO
- Cliquez Browse → Browse Local
- Naviguez jusqu'à votre fichier ISO
- Le système détecte automatiquement l'OS (sinon, décochez "Automatically detect" et choisissez manuellement)
Configurer CPU et RAM

Paramètre Valeur recommandée (lab) Production
Memory 2048 MB 4096+ MB
CPUs 2 4+
Configurer le disque
- Cochez Enable storage for this virtual machine
- Taille : 20 GB minimum (40+ GB pour production)
- Le disque sera créé dans le pool default (/var/lib/libvirt/images/)
Nom et réseau
- Name : ubuntu-test (ou le nom de votre choix)
- Cochez Customize configuration before install si vous voulez ajuster le firmware (UEFI)
- Cliquez Finish
Personnaliser (optionnel)

Si vous avez coché "Customize" :
- Overview → Firmware : choisissez UEFI si vous voulez un boot moderne
- NIC : vérifiez que le réseau est default (NAT)
- Cliquez Begin Installation
Installation

La console graphique s'ouvre. Suivez l'assistant d'installation de votre OS.

Paramètre	Valeur recommandée (lab)	Production
Memory	2048 MB	4096+ MB
CPUs	2	4+

Mode	Quand l'utiliser
BIOS (SeaBIOS)	Compatibilité maximale, VMs legacy
UEFI (OVMF)	OS modernes, Secure Boot, Windows 11

Par défaut, virt-manager utilise BIOS. Pour UEFI, personnalisez la VM avant l'installation.

Méthode 2 : virt-install (ligne de commande)

virt-install est l'outil CLI pour créer des VMs. Avantages :

Scriptable : automatisez la création de VMs
Reproductible : même commande = même résultat
SSH-friendly : pas besoin de X11

Syntaxe de base

Six options suffisent à décrire une VM complète, et leur ordre n'a aucune importance. Retenez surtout que virt-install crée puis démarre la machine dans la foulée : la commande n'est pas un simple générateur de configuration, elle lance l'installation. Pour produire uniquement la définition sans démarrer, ajoutez --print-xml.

virt-install \
  --name <nom> \
  --memory <MB> \
  --vcpus <nombre> \
  --disk <options> \
  --network <options> \
  --cdrom <chemin-iso> \
  --os-variant <type>

Exemple complet : VM Ubuntu avec ISO

Cette commande rend la main immédiatement grâce à --noautoconsole, pendant que l'installateur démarre en arrière-plan. La console reste accessible à tout moment avec virt-viewer ubuntu-test. Notez la valeur listen=127.0.0.1 : elle restreint le serveur VNC à la boucle locale. C'est le comportement à conserver, car une console VNC libvirt n'exige aucun mot de passe par défaut ; l'ouvrir sur 0.0.0.0 donne à tout le réseau un accès clavier et écran à la machine, avant même que le système ait un compte utilisateur.

virt-install \
  --name ubuntu-test \
  --memory 2048 \
  --vcpus 2 \
  --disk size=20,format=qcow2,pool=default \
  --network network=default \
  --cdrom /var/lib/libvirt/images/ubuntu-24.04.4-live-server-amd64.iso \
  --os-variant ubuntu24.04 \
  --graphics vnc,listen=127.0.0.1 \
  --noautoconsole

Pour atteindre cette console depuis votre poste, ouvrez un tunnel SSH plutôt que d'exposer le port : ssh -L 5900:127.0.0.1:5900 utilisateur@serveur, puis connectez votre client VNC sur localhost:5900.

Placez l'ISO dans /var/lib/libvirt/images/ pour éviter les problèmes de permissions :

sudo cp ~/Downloads/ubuntu-24.04.4-live-server-amd64.iso /var/lib/libvirt/images/

Décryptage des options :

Option	Signification
`--name ubuntu-test`	Nom de la VM dans libvirt
`--memory 2048`	2 GB de RAM
`--vcpus 2`	2 vCPUs
`--disk size=20,format=qcow2,pool=default`	Disque 20 GB QCOW2 dans le pool default
`--network network=default`	Connecté au réseau NAT
`--cdrom /chemin/...`	ISO d'installation
`--os-variant ubuntu24.04`	Optimisations pour Ubuntu 24.04
`--graphics vnc`	Console VNC (pour virt-manager)
`--noautoconsole`	Ne pas ouvrir la console automatiquement

Lister les os-variant disponibles

La liste provient de la base osinfo-db installée sur votre machine, pas d'Internet : une distribution sortie après votre paquet osinfo-db n'y figurera pas, d'où les erreurs unknown OS name sur les systèmes les plus récents. Chaque ligne présente le nom canonique suivi de ses alias ; n'importe lequel est accepté par --os-variant. Les entrées ubuntu-lts-latest et ubuntu-stable-latest sont des pointeurs mouvants, à éviter dans un script que vous voulez reproductible.

Sortie réelle (extrait, la liste complète compte davantage de versions) :

ubuntu25.10, ubuntuquesting
ubuntu-stable-latest, ubuntu25.04, ubuntuplucky
ubuntu24.10, ubuntuoracular
ubuntu-lts-latest, ubuntu24.04, ubuntunoble
ubuntu23.10, ubuntumantic
ubuntu22.04, ubuntujammy
ubuntu20.04, ubuntufocal
ubuntu18.04, ubuntubionic

# Rechercher par nom
virt-install --osinfo list | grep -i debian

# Rechercher par famille
virt-install --osinfo list | grep -i rhel

L'os-variant active des optimisations (pilotes virtio, timers...) pour l'OS cible.

Variante : VM avec boot UEFI

Le firmware se choisit à la création et ne se change plus ensuite : un disque installé en BIOS ne bootera pas si vous basculez la VM en UEFI. Prenez donc cette décision maintenant. UEFI est requis pour le Secure Boot et pour Windows 11, et c'est le choix par défaut de la plupart des images cloud récentes.

virt-install \
  --name ubuntu-uefi \
  --memory 2048 \
  --vcpus 2 \
  --disk size=20,format=qcow2,pool=default \
  --network network=default \
  --cdrom /var/lib/libvirt/images/ubuntu-24.04.4-live-server-amd64.iso \
  --os-variant ubuntu24.04 \
  --boot uefi \
  --graphics vnc \
  --noautoconsole

L'option --boot uefi utilise automatiquement OVMF si installé.

Vous verrez peut-être un warning :

WARNING  Requested memory 2048 MiB is less than the recommended 3072 MiB for OS ubuntu24.04

C'est un avertissement, pas une erreur. 2 GB suffisent pour un lab, mais prévoyez 3-4 GB pour un usage réel.

Variante : VM serveur sans interface graphique

Sur un serveur, la console graphique n'apporte rien et complique l'accès distant. La console série redirige l'affichage de l'installateur puis du système vers un canal texte que virsh console lit directement, sans VNC ni tunnel. Deux conditions doivent être réunies pour que cela fonctionne : la VM doit exposer un port série (--console pty,target_type=serial), et le noyau invité doit être configuré pour y écrire (console=ttyS0), ce que fait --extra-args.

--extra-args ne s'applique qu'aux installations démarrées avec --location, qui extrait le noyau et l'initrd pour les démarrer avec des paramètres personnalisés. Avec --cdrom, la VM boote l'ISO telle quelle et les paramètres seraient ignorés. --location accepte une arborescence d'installation distante ou le chemin local d'une ISO ; il n'accepte pas l'URL d'une ISO distante.

virt-install \
  --name ubuntu-server \
  --memory 2048 \
  --vcpus 2 \
  --disk size=20,format=qcow2,pool=default \
  --network network=default \
  --location /var/lib/libvirt/images/ubuntu-24.04.4-live-server-amd64.iso \
  --os-variant ubuntu24.04 \
  --graphics none \
  --console pty,target_type=serial \
  --extra-args 'console=ttyS0,115200n8'

Différences :

Option	Effet
`--location` au lieu de `--cdrom`	Permet d'injecter des paramètres kernel
`--graphics none`	Pas de console graphique
`--console pty,target_type=serial`	Console série
`--extra-args 'console=ttyS0'`	Redirige la sortie vers la console série

Vous accéderez à la VM via :

virsh console ubuntu-server

Variante : VM connectée à un bridge

Avec le réseau default, la VM est derrière un NAT : elle sort vers Internet mais reste injoignable depuis le reste du LAN. Le mode bridge supprime cette barrière en rattachant la carte virtuelle au même segment Ethernet que l'hôte. La VM tire alors son adresse du DHCP de votre box et devient visible par les autres machines, ce qui est indispensable dès que vous hébergez un service.

Si vous avez configuré un bridge br0 (guide réseau) :

virt-install \
  --name ubuntu-bridge \
  --memory 2048 \
  --vcpus 2 \
  --disk size=20,format=qcow2,pool=default \
  --network bridge=br0 \
  --cdrom /var/lib/libvirt/images/ubuntu-24.04.4-live-server-amd64.iso \
  --os-variant ubuntu24.04 \
  --graphics vnc \
  --noautoconsole

La VM obtiendra une IP directement sur votre LAN.

Variante : Import d'une image cloud (sans installation)

Les images cloud sont des disques pré-installés, prêts à booter. C'est la méthode la plus rapide pour créer une VM :

Télécharger l'image cloud

Téléchargez l'image et le fichier de sommes publié à côté, puis vérifiez l'empreinte avant d'aller plus loin : une image disque non vérifiée devient le système d'exploitation complet de votre VM.
Fenêtre de terminal
```
cd /var/lib/libvirt/images
sudo curl -fLO https://cloud-images.ubuntu.com/noble/current/noble-server-cloudimg-amd64.img
sudo curl -fLO https://cloud-images.ubuntu.com/noble/current/SHA256SUMS
sha256sum --check --ignore-missing SHA256SUMS
```
La sortie attendue est noble-server-cloudimg-amd64.img: OK, ou : Réussi si votre terminal est en français. Canonical publie aussi SHA256SUMS.gpg au même endroit, pour vérifier la signature du fichier de sommes lui-même.

Créer un disque basé sur l'image (backing file)

sudo qemu-img create -f qcow2 -F qcow2 \
  -b /var/lib/libvirt/images/noble-server-cloudimg-amd64.img \
  /var/lib/libvirt/images/ubuntu-test.qcow2 20G

Créer la VM avec --import

virt-install \
  --name ubuntu-test \
  --memory 2048 \
  --vcpus 2 \
  --disk /var/lib/libvirt/images/ubuntu-test.qcow2 \
  --network network=default \
  --os-variant ubuntu24.04 \
  --import \
  --graphics vnc \
  --noautoconsole

Après la création : commandes utiles

Lister les VMs

Sans --all, virsh list n'affiche que les machines en cours d'exécution. La colonne Id est un identifiant attribué au démarrage et réattribué ensuite : ne l'utilisez jamais dans un script, référencez toujours la VM par son nom ou son UUID.

virsh list --all

Sortie réelle :

 Id   Name          State
-----------------------------
 1    ubuntu-test   running

Accéder à la console

Deux consoles coexistent et ne montrent pas la même chose. La console graphique affiche ce que la carte vidéo virtuelle produit, y compris l'écran de l'installateur et le menu de démarrage. La console série ne montre que ce que le système invité choisit d'y écrire : elle reste vide tant que la VM n'a pas été configurée pour l'utiliser.

Console graphique (via virt-manager) :

virt-viewer ubuntu-test

Console série (si configurée) :

virsh console ubuntu-test
# Pour sortir : Ctrl+]

Démarrer / Arrêter

La distinction entre shutdown et destroy compte. shutdown envoie un signal ACPI au système invité, qui arrête ses services et démonte ses systèmes de fichiers ; si l'invité ne gère pas l'ACPI ou est figé, rien ne se passe et la commande semble sans effet. destroy coupe l'alimentation virtuelle sans prévenir : la VM s'arrête à coup sûr, au risque d'un système de fichiers incohérent au redémarrage. Aucune des deux ne supprime la VM, ce que fait virsh undefine.

# Démarrer
virsh start ubuntu-test

# Arrêter proprement (ACPI shutdown)
virsh shutdown ubuntu-test

# Arrêt forcé (équivalent couper le courant)
virsh destroy ubuntu-test

Voir les informations

Trois lignes de cette sortie servent au diagnostic quotidien. Autostart indique si la VM redémarrera avec l'hôte, et vaut disable par défaut, ce qui surprend après un redémarrage du serveur. Used memory révèle la mémoire réellement allouée, qui peut être inférieure au maximum si le ballooning est actif. Security model confirme quel mécanisme confine le processus QEMU, AppArmor sur Debian et Ubuntu, SELinux sur Fedora et RHEL : c'est la première piste quand un accès à un fichier est refusé alors que les droits Unix sont corrects.

virsh dominfo ubuntu-test

Sortie réelle :

Id:             1
Name:           ubuntu-test
UUID:           09978674-04a9-4f02-a61f-18615ddedca1
OS Type:        hvm
State:          running
CPU(s):         2
CPU time:       8,1s
Max memory:     2097152 KiB
Used memory:    2097152 KiB
Persistent:     yes
Autostart:      disable
Managed save:   no
Security model: apparmor
Security DOI:   0
Security label: libvirt-09978674-... (enforcing)

Activer le démarrage automatique

Cette commande crée un lien symbolique dans /etc/libvirt/qemu/autostart/, et la VM redémarrera avec le service libvirt de l'hôte. Elle ne dit rien de l'ordre de démarrage : si une VM applicative dépend d'une VM de base de données, libvirt ne garantit aucune séquence. virsh autostart --disable ubuntu-test revient en arrière.

virsh autostart ubuntu-test

Tableau comparatif des options

Ce tableau ne désigne pas un gagnant : il oppose le confort d'exploration à la reproductibilité. La ligne qui tranche dans la pratique est « Production ». Une VM créée à la souris n'existe nulle part sous forme de texte, donc ni dans un dépôt Git, ni dans une revue, ni dans une procédure de reconstruction. Beaucoup d'administrateurs utilisent les deux : virt-install pour créer, virt-manager pour observer et dépanner.

Besoin	virt-manager	virt-install
Découvrir KVM	Idéal	Courbe d'apprentissage
Automatisation	Manuel	Scriptable
Serveur distant SSH	Besoin de X11	Natif
Console graphique	Intégrée	Via virt-viewer
Homelab	Confortable	Adapté
Production	Pas reproductible	Recommandé

Erreurs fréquentes

Cinq des six erreurs ci-dessous se produisent avant que la VM ne démarre, pendant la validation des paramètres par libvirt : le message est donc explicite et le correctif immédiat. La seule qui demande un vrai diagnostic est Permission denied sur l'ISO, car les droits Unix peuvent être corrects et l'accès malgré tout refusé par AppArmor ou SELinux. Vérifiez alors les journaux de l'hôte, journalctl -u libvirtd et /var/log/libvirt/qemu/<nom>.log.

Erreur	Cause	Solution
`ERROR: --os-variant unknown`	os-variant incorrect	Lister avec `virt-install --osinfo list`
`Permission denied` sur l'ISO	ISO pas lisible par qemu	`chmod 644` ou déplacer dans `/var/lib/libvirt/images/`
`Cannot access storage`	Pool non démarré	`virsh pool-start default`
`Network not found`	Réseau default inactif	`virsh net-start default`
`Unable to complete install`	RAM insuffisante	Augmenter `--memory`
`UEFI firmware not found`	OVMF non installé	`apt install ovmf` ou `dnf install edk2-ovmf`

Checklist création VM

Parcourez ces six points avant de lancer la commande : cinq d'entre eux provoquent un échec immédiat s'ils manquent, et le sixième, le mode de boot, ne se rattrape pas après l'installation. Les deux vérifications libvirt (pool-list et net-list) sont celles qu'on oublie le plus souvent après un redémarrage de l'hôte, car ni le pool ni le réseau default ne sont forcément configurés en démarrage automatique.

ISO téléchargée et accessible
Pool de stockage actif (virsh pool-list)
Réseau actif (virsh net-list)
Ressources disponibles (RAM, espace disque)
os-variant correct pour l'OS cible
Mode boot choisi (BIOS ou UEFI)

À retenir

virt-manager = interface graphique, idéale pour découvrir et gérer un homelab
virt-install = ligne de commande, idéale pour l'automatisation et les scripts
Options essentielles : --name, --memory, --vcpus, --disk, --network, --cdrom/--location
os-variant active les optimisations pour l'OS cible, toujours le spécifier
UEFI (--boot uefi) pour les OS modernes, BIOS par défaut pour la compatibilité
Console série (--graphics none --console pty) pour les serveurs headless

Pour aller plus loin

Les 15 commandes virsh essentielles : Piloter la VM créée depuis le terminal, sans repasser par virt-manager.
Snapshots, clones et backups : Transformer cette première VM en modèle dupliqué en quelques secondes.
Terraform + libvirt : Rejouer la même création de VM à l'identique, décrite dans un fichier versionné.

Références

virt-install man page, Documentation complète des options
Red Hat - Creating guests with virt-install, Guide officiel RHEL
libvirt - Domain XML format, Référence du format XML des VMs