2. KVM, QEMU et Proxmox : qui fait quoi ?

2.1 La chaîne de virtualisation

Comprendre la répartition des rôles entre KVM, QEMU et Proxmox évite beaucoup de confusion, notamment lorsqu'un message d'erreur nomme l'un ou l'autre de ces composants.

KVM — Kernel-based Virtual Machine — est un module du noyau Linux. Il ne fait qu'une chose : exposer les instructions de virtualisation matérielle du CPU (Intel VT-x ou AMD-V) à l'espace utilisateur.

KVM transforme le noyau Linux en hyperviseur de type 1. Sans KVM, QEMU fonctionnerait en émulation pure, en traduisant chaque instruction du processeur invité — dix fois plus lent, souvent davantage.

QEMU est l'émulateur. Il simule le matériel que voit la VM : carte réseau virtuelle, contrôleur de disque, carte graphique, BIOS.

Chaque VM en cours d'exécution est un processus QEMU sur l'hôte. C'est QEMU qui lit le fichier de configuration de la VM et instancie les périphériques virtuels correspondants.

Proxmox VE est la couche de gestion au-dessus. Il crée les fichiers de configuration, appelle QEMU avec les bons paramètres, gère le stockage, le réseau, les sauvegardes, l'interface web. Proxmox ne virtualise rien directement — il orchestre QEMU/KVM.

• 📖 Documentation Proxmox — KVM Virtual Machines
• 📖 KVM — Kernel-based Virtual Machine, présentation Red Hat

Les quatre couches d'une VM en marche, de la gestion au matériel, avec ce qu'on en voit réellement sur un nœud du lab. Le fichier de configuration écrit par Proxmox, le processus kvm de la VM.

Puis les modules du noyau et l'extension du processeur. Cliquez sur une couche pour lire son rôle et le résultat correspondant.

Revenons à la définition de base : virtualiser une machine, c'est faire croire à un système qu'il a un ordinateur pour lui seul. Trois logiciels se partagent ce travail, avec chacun un rôle distinct :

Quand un message d'erreur nomme qm, le problème est dans la couche de gestion ; QEMU, dans le processus de la VM ; KVM, dans le module du noyau ou le processeur. On sait ainsi où chercher.

Où voir chaque couche sur votre nœud :

2.2 Vérifier les prérequis matériels

Avant de créer une VM, le CPU de l'hôte doit exposer ses extensions de virtualisation. Sur du matériel récent elles sont actives par défaut, mais il arrive que le BIOS/UEFI les désactive.

Dans le Shell du nœud (interface web → votre nœud → Shell) :

# Depuis le Shell du noeud Proxmox (pas depuis votre poste Windows)
# Verifier la presence des extensions de virtualisation dans /proc/cpuinfo
# "vmx" = Intel VT-x  |  "svm" = AMD-V
grep -m 1 -E '^flags.*\b(vmx|svm)\b' /proc/cpuinfo   # -m 1 : la première ligne trouvée

# Vérifier que les modules KVM sont bien chargés dans le noyau
lsmod | grep -E '^kvm'

Résultat attendu :

flags: ... vmx ... (ou svm pour AMD)
kvm_intel             397312  0
kvm                  1032192  1 kvm_intel

Si la commande grep ne renvoie rien, les extensions sont absentes ou désactivées dans le BIOS. Sur les machines de l'atelier, cette vérification a été faite en amont lors du déploiement PXE — vous devriez voir vmx ou svm sans aucune action supplémentaire.

2.3 Une VM, un processus QEMU sur l'hôte

Chaque VM Proxmox correspond à un processus QEMU sur l'hôte :

Dans le Shell du nœud (interface web → votre nœud → Shell) :

# Voir les processus QEMU actifs (une ligne par VM démarrée)
# Proxmox lance QEMU sous le nom « kvm » : c'est ce nom qu'on cherche
pgrep -a kvm

Résultat attendu (les lignes qui comptent) :

12345 /usr/bin/kvm -id 100 -name debian-base,debug-threads=on -no-shutdown -chardev socket,id=qmp,path=/va

Chaque ligne est une VM. Proxmox lance QEMU par le lien /usr/bin/kvm : chercher qemu-system ne trouve donc rien. L'option -id porte le VMID.

C'est ce qui permet de relier un processus gourmand vu dans top à la VM responsable. Le PID donne accès aux informations détaillées via /proc/<PID>/. La ligne complète fait plusieurs milliers de caractères : c'est la traduction, option par option, du fichier de configuration de la VM, que qm showcmd 100 --pretty affiche lisiblement.

2.4 Types de CPU : emulated, host, custom

Proxmox propose plusieurs types de CPU avec un compromis performances/portabilité.

CPU émulé (ex: kvm64, qemu64) : QEMU présente un processeur générique. La VM peut migrer entre hôtes de générations différentes, mais n'a pas accès aux instructions avancées, comme AVX-512 (Advanced Vector Extensions, calcul vectoriel).

CPU host : QEMU expose directement le CPU physique. Performances maximales, mais la VM ne peut migrer qu'entre hôtes avec des CPU strictement identiques.

CPU custom : profils intermédiaires qui exposent certaines extensions tout en gardant une compatibilité de migration entre nœuds d'une même génération.

Dans le Shell du nœud (interface web → votre nœud → Shell) :

# Changer le type de CPU d'une VM arrêtée
qm set 100 --cpu host

# Voir le type de CPU actuel
qm config 100 | grep cpu
# → cpu: host

Résultat attendu :

root@pxe211:~# qm set 100 --cpu host
update VM 100: -cpu host
root@pxe211:~# qm config 100 | grep cpu
cpu: host

qm set renvoie toujours cette ligne update VM <id>: -<option> <valeur> : elle confirme l'écriture dans /etc/pve/qemu-server/100.conf, rien de plus.