Hyperviseurs de type 1 et 2, KVM et QEMU

Objectif

Comprendre ce qu'est un hyperviseur, situer KVM et QEMU dans le paysage (VMware ESXi, Hyper-V, VirtualBox, Proxmox VE), et savoir dire en deux minutes si un serveur peut héberger des machines virtuelles.

L'essentiel

Un hyperviseur partage un ordinateur physique (l'hôte) entre plusieurs machines virtuelles (les invités), chacune avec son propre noyau.
Type 1 : l'hyperviseur tourne directement sur le matériel (ESXi, Hyper-V, Xen, KVM). Type 2 : c'est une application dans un système déjà installé (VirtualBox, VMware Workstation).
KVM est un module du noyau Linux : il transforme Linux en hyperviseur de type 1 en s'appuyant sur les extensions du processeur Intel VT-x (vmx) ou AMD-V (svm).
QEMU fournit tout le reste : la carte mère virtuelle, les disques, les cartes réseau. Une VM KVM est un processus qemu-system-x86_64 sur l'hôte.
Sans vmx/svm dans /proc/cpuinfo et sans /dev/kvm, QEMU émule le processeur en logiciel (TCG) : cela marche, mais 10 à 50 fois plus lentement.

1. Pourquoi virtualiser

L'agence MasterLinux de Fès avait cinq petits serveurs physiques : un pour la messagerie, un pour le site, un pour la base de données, un pour les sauvegardes, un pour les tests. Chacun utilisait 5 à 10 % de son processeur. Après consolidation, deux serveurs physiques identiques portent les cinq machines virtuelles, avec de la marge :

moins de matériel à acheter, alimenter et refroidir ;
une VM se crée en minutes, se copie, se sauvegarde comme un fichier ;
isolation : un plantage ou une compromission reste (en principe) dans sa VM ;
mobilité : une VM peut changer d'hôte pendant une maintenance, parfois sans s'arrêter (migration à chaud).

La contrepartie : un hôte qui tombe emporte toutes ses VM. C'est pour cela qu'on parle vite de stockage partagé, de cluster et de haute disponibilité (niveau 3 de cette formation).

2. Type 1 et type 2

 Type 1 (bare metal)                     Type 2 (hébergé)
 ┌─────┐ ┌─────┐ ┌─────┐                 ┌─────┐ ┌─────┐
 │ VM1 │ │ VM2 │ │ VM3 │                 │ VM1 │ │ VM2 │
 └─────┘ └─────┘ └─────┘                 └─────┘ └─────┘
 ┌───────────────────────┐               ┌───────────────┐ ┌──────────┐
 │      hyperviseur      │               │  VirtualBox   │ │ navigat. │
 └───────────────────────┘               └───────────────┘ └──────────┘
 ┌───────────────────────┐               ┌──────────────────────────────┐
 │       matériel        │               │  système hôte (Windows, …)   │
 └───────────────────────┘               └──────────────────────────────┘
                                         ┌──────────────────────────────┐
                                         │           matériel           │
                                         └──────────────────────────────┘

Produit	Type	Où on le rencontre
VMware ESXi / vSphere	1	grandes entreprises, banques (licences devenues très chères depuis 2024)
Microsoft Hyper-V	1	parcs Windows Server, Azure
KVM (Proxmox VE, OpenStack, oVirt, libvirt)	1	hébergeurs, cloud public, PME qui quittent VMware
Xen / XCP-ng	1	anciens clouds, XCP-ng chez certains hébergeurs
VirtualBox, VMware Workstation	2	poste de travail, formation, tests

KVM est un cas particulier : on installe d'abord Debian, Ubuntu ou Rocky, puis on charge un module. Mais une fois le module chargé, c'est le noyau Linux lui-même qui ordonnance les VM comme des processus : il n'y a pas de couche intermédiaire, d'où le classement en type 1. Tous les grands clouds publics basés sur Linux utilisent KVM ou un dérivé.

3. Le partage du travail : KVM, QEMU, libvirt

  virsh / virt-manager / Proxmox (qm)      ← outils d'administration
              │
           libvirt (virtqemud)             ← API, XML, réseaux, stockage
              │
   qemu-system-x86_64 (un processus par VM) ← matériel virtuel : disques, réseau, BIOS/UEFI
              │  ioctl()
           /dev/kvm  (modules kvm + kvm_intel ou kvm_amd)  ← exécution du CPU invité
              │
          processeur VT-x / AMD-V

KVM exécute le code de l'invité directement sur le vrai processeur, dans un mode protégé prévu pour cela. Il gère aussi la mémoire de l'invité (EPT chez Intel, NPT chez AMD).
QEMU est l'émulateur : il présente au système invité un firmware (SeaBIOS ou UEFI/OVMF), un contrôleur de disque, une carte réseau… Sans KVM, il peut aussi émuler le processeur (mode TCG), utile pour faire tourner une image ARM sur un PC x86.
libvirt (leçon suivante) évite d'écrire de longues lignes de commande QEMU : la VM est décrite en XML et pilotée avec virsh.

4. Vérifier qu'un serveur peut virtualiser

# 1. Le processeur a-t-il les extensions ? (compte les cœurs logiques qui les annoncent)
grep -cwE 'vmx|svm' /proc/cpuinfo          # 0 = non, ou désactivé dans le BIOS
lscpu | grep -i virtualisation              # « Virtualisation : VT-x » ou « AMD-V »

# 2. Les modules sont-ils chargés ?
lsmod | grep kvm
# kvm_intel             409600  0
# kvm                  1388544  1 kvm_intel

# 3. Le périphérique existe-t-il ?
ls -l /dev/kvm                              # crw-rw---- 1 root kvm 10, 232 …

# 4. Diagnostic complet (paquet libvirt-clients sur Debian, libvirt-client sur Rocky)
virt-host-validate qemu
#  QEMU: Checking for hardware virtualization          : PASS
#  QEMU: Checking if device /dev/kvm exists            : PASS
#  QEMU: Checking for secure guest support              : WARN (…)

Le drapeau du processeur indique le constructeur, donc le module :

Drapeau	Processeur	Module	Pagination imbriquée
`vmx`	Intel VT-x	`kvm_intel`	`ept`
`svm`	AMD-V	`kvm_amd`	`npt`

Si le drapeau manque sur un Xeon récent, la fonction est presque toujours désactivée dans le BIOS/UEFI (menus « Intel Virtualization Technology », « SVM Mode »). Le noyau le dit dans ses messages :

dmesg | grep -i kvm
# kvm_intel: VMX not enabled (by BIOS) in MSR_IA32_FEAT_CTL on CPU 0     (noyaux récents)
# kvm: disabled by bios                                                  (noyaux plus anciens)

Sur une VM louée dans le cloud, vmx est souvent absent : l'hébergeur n'expose pas la virtualisation imbriquée. On ne peut alors faire que de l'émulation lente.

5. La virtualisation imbriquée

Faire tourner un hyperviseur dans une VM (labo Proxmox, formation, tests d'OpenStack) demande l'option nested du module :

cat /sys/module/kvm_intel/parameters/nested     # Y ou N  (kvm_amd : 1 ou 0)

# Activation permanente (prise en compte au prochain chargement du module)
echo 'options kvm_intel nested=1' > /etc/modprobe.d/kvm-nested.conf
modprobe -r kvm_intel && modprobe kvm_intel       # toutes les VM doivent être arrêtées

Puis la VM qui servira d'hyperviseur doit recevoir le drapeau : -cpu host avec QEMU, ou <cpu mode='host-passthrough'/> avec libvirt. Les noyaux récents activent souvent nested par défaut ; on le vérifie au lieu de le supposer.

6. Lancer une VM avec QEMU seul

On ne fait presque jamais cela en production, mais le faire une fois montre ce que libvirt et Proxmox écrivent pour vous :

# Un disque de 20 Gio (détails dans la leçon sur le stockage)
qemu-img create -f qcow2 /var/lib/libvirt/images/ml-test-01.qcow2 20G

# -enable-kvm -cpu host : accélération KVM, CPU identique à l'hôte
# -m 2048 -smp 2        : 2 Gio de RAM, 2 vCPU
# -cdrom … -boot d      : démarrer sur l'ISO d'installation
# -nic user,…           : réseau « user », un NAT intégré à QEMU, sans configuration
# -nographic            : console série dans le terminal (pas de fenêtre)
qemu-system-x86_64 \
  -enable-kvm -cpu host \
  -m 2048 -smp 2 \
  -drive file=/var/lib/libvirt/images/ml-test-01.qcow2,format=qcow2,if=virtio \
  -cdrom debian-13-netinst.iso -boot d \
  -nic user,model=virtio-net-pci \
  -nographic

Pendant que la VM tourne, sur l'hôte :

ps -eo pid,%cpu,rss,cmd | grep [q]emu-system   # la VM est un processus comme un autre
top -H -p <pid>                                 # un thread par vCPU (« CPU 0/KVM », « CPU 1/KVM »)

Une VM est donc soumise aux mêmes règles que tout processus : elle consomme de la mémoire (RSS), du temps processeur, et peut être tuée par le noyau en cas de manque de mémoire (OOM killer).

Selon la version

Point	Debian 13	Ubuntu 24.04	Rocky 9 / RHEL 10
Paquets de base	`qemu-system-x86 libvirt-daemon-system`	`qemu-kvm libvirt-daemon-system`	`qemu-kvm libvirt` (RHEL : groupe « Virtualization Host »)
Binaire QEMU	`/usr/bin/qemu-system-x86_64`	idem	`/usr/libexec/qemu-kvm` (version allégée, machines `pc-q35-rhel*`)
Groupe pour `/dev/kvm`	`kvm`	`kvm`	`kvm`
Validation	`virt-host-validate`	idem	idem

Pièges fréquents

Chercher vmx sans -w : grep vmx trouve aussi vmx flags sur certains noyaux et peut tromper ; grep -w cherche le mot entier.
Conclure trop vite « pas compatible » : un Xeon sans vmx a presque toujours la fonction coupée dans le BIOS. Vérifiez dmesg avant de commander un serveur.
Oublier que l'hôte a besoin de ressources : 64 Go de RAM physique ne font pas 64 Go de VM. Gardez 2 à 4 Go et un ou deux cœurs pour l'hôte.
Imbriquer en production : la virtualisation imbriquée est pratique en labo, déconseillée pour des services réels (performances, migrations impossibles).

Lab

Sur une machine Debian, trois fournisseurs ont envoyé des extraits de /proc/cpuinfo et de dmesg pour les futurs hyperviseurs de l'agence de Fès. Vous allez :

trier les serveurs capables de faire tourner KVM ;
associer à chacun le bon module noyau ;
activer la virtualisation imbriquée sur le serveur Intel ;
écrire la commande QEMU qui démarre une VM de test.

Quiz

Quelle est la différence entre un hyperviseur de type 1 et de type 2 ?
Que fait KVM et que fait QEMU ?
Un serveur Intel ne montre pas vmx dans /proc/cpuinfo. Quelle est la cause la plus probable, et où le confirmer ?
Quel module charger sur un processeur AMD EPYC ?
Comment une VM KVM apparaît-elle dans la liste des processus de l'hôte ?

Réponses

Le type 1 s'exécute directement sur le matériel ; le type 2 est une application installée dans un système d'exploitation existant.
KVM, module du noyau, exécute le processeur et la mémoire de l'invité grâce à VT-x/AMD-V ; QEMU émule le reste du matériel (firmware, disques, réseau) et s'appuie sur /dev/kvm.
La virtualisation est désactivée dans le BIOS/UEFI ; dmesg | grep -i kvm affiche « VMX not enabled (by BIOS) » ou « disabled by bios ».
kvm_amd (avec le module générique kvm).
Comme un processus qemu-system-x86_64 (ou qemu-kvm sur RHEL), avec un thread par vCPU.