KVM/libvirt virtualise AWS, GCP et Azure — votre homelab mérite la même stack
KVM atteint 97 % des performances bare-metal, ne coûte aucune licence et propulse les trois plus grands clouds publics. Avec libvirt, virt-manager et Cockpit, cette stack de niveau datacenter est accessible en vingt minutes sur n’importe quel serveur Linux.
En 2024, Broadcom rachète VMware pour 69 milliards de dollars et annonce la fin des licences perpétuelles. En janvier 2026, le prix moyen d’une licence VMware vSphere a triplé pour les PME. Pendant ce temps, la stack KVM/QEMU/libvirt — le même hyperviseur qui fait tourner AWS Nitro, Google Compute Engine et une partie d’Azure — reste intégrée au noyau Linux, gratuite, et n’a jamais été aussi performante. Si les trois plus gros clouds de la planète lui font confiance pour leurs charges de production, il n’y a aucune raison technique de lui préférer un hyperviseur payant pour un homelab ou un petit datacenter.
Ce que KVM est vraiment — et ce qu’il n’est pas
KVM (Kernel-based Virtual Machine) est un module du noyau Linux depuis la version 2.6.20 en février 2007. Il transforme le kernel en hyperviseur de type 1 — contrairement à VirtualBox (type 2, hébergé), KVM ne s’intercale pas entre le matériel et l’OS hôte : le noyau Linux est l’hyperviseur. Chaque machine virtuelle devient un processus Linux standard, schedulé par le scheduler du kernel, avec des mappings mémoire directs via les extensions processeur Intel VT-x et AMD-V.
La confusion classique vient de QEMU, le companion obligé de KVM. QEMU est un émulateur — il sait simuler un processeur x86, un contrôleur SCSI, une carte réseau. Sans KVM, QEMU émule tout en software, ce qui est lent. Avec KVM (-enable-kvm), QEMU délègue l’exécution CPU au module kernel et ne conserve que l’émulation des périphériques. Le résultat : un overhead CPU de 3 à 5 % par rapport au bare-metal, contre 10 à 15 % pour VMware Workstation et facilement 20 à 30 % pour VirtualBox, selon les benchmarks VTmark de l’Université du Danemark du Sud et les mesures de Pextra en août 2025.
La couche de management, c’est libvirt : une API en C avec des bindings Python, Go, Rust qui unifie le pilotage de KVM/QEMU, LXC, Xen. C’est libvirt qui expose le concept de domaine, de pool de stockage, de réseau virtuel — les abstractions que les outils graphiques manipulent ensuite. Au-dessus, virsh donne la ligne de commande, virt-manager l’interface GTK, Cockpit-machines l’interface web.
La dernière version de QEMU à date de publication est la 11.0.3 (juillet 2026), avec la 11.1.0 en release candidate. libvirt tourne en série 11.x depuis janvier 2025.
La performance bare-metal n’est pas un mythe marketing
Les benchmarks indépendants sont convergents. La suite VTmark (Dhrystone, Whetstone, Bonnie++, Iperf3) donne un tableau clair :
Le différentiel disque s’explique par les pilotes VirtIO — des drivers paravirtualisés qui évitent l’émulation complète d’un contrôleur SATA. Dans un invité Linux, virtio-blk et virtio-scsi sont chargés automatiquement par le noyau. Pour un invité Windows, les drivers VirtIO sont un téléchargement séparé (signés par Red Hat via le projet Fedora VirtIO), mais l’investissement de cinq minutes est amorti dès la première requête SQL en prod.
Un test en conditions réelles mené sur une application web de production (Ordbogen A/S, dictionnaire multilingue avec trafic concurrent simulé) confirme l’écart : la latence de réponse sous KVM n’est supérieure que de 4 à 7 % au bare-metal, contre ≈18 % pour VMware Workstation, un écart largement imputable aux goulots I/O.
Les trois leviers qui écartent KVM de VirtualBox
VirtualBox reste un excellent outil — pour tester un ISO Ubuntu en cinq minutes sur un laptop Windows. Mais trois différences structurelles l’excluent des charges de production.
Premièrement, l’architecture. VirtualBox est un hyperviseur de type 2 : il tourne comme une application au-dessus de l’OS hôte, ce qui ajoute une couche de traduction pour chaque accès mémoire et chaque interruption. KVM est un hyperviseur de type 1 : le noyau Linux absorbe l’appel de virtualisation directement. La différence se voit au premier fio ou iperf3 sous charge.
Deuxièmement, le mode headless. KVM/QEMU/libvirt est conçu pour fonctionner sans écran, piloté par virsh ou une API REST — c’est le mode de fonctionnement normal d’un serveur. VirtualBox propose un mode headless (VBoxHeadless), mais toute son architecture de snapshots, de clonage et de réseau est pensée autour du GUI Manager.
Troisièmement, le passthrough matériel. Le PCI passthrough (et son corollaire vedette, le GPU passthrough pour les VMs gaming) repose sur VFIO et IOMMU, deux technologies du noyau Linux. KVM y accède nativement. VirtualBox propose un PCI passthrough expérimental sur Linux uniquement, non supporté sur Windows et macOS. Le SR-IOV — qui permet de découper une carte réseau physique en plusieurs interfaces virtuelles directement exposées aux VMs — est un citoyen de première classe sous KVM/libvirt. Sous VirtualBox, il n’existe pas.
Cockpit-machines : le virt-manager dans un navigateur
L’argument historique contre KVM était l’absence d’interface graphique « prête à l’emploi ». Cet argument est mort en 2024 avec la maturation de Cockpit-machines, le plugin de virtualisation du projet Cockpit de Red Hat.
Cockpit est activé par défaut sur RHEL 9, Fedora Server et Debian 12. Une fois le paquet cockpit-machines installé et le service cockpit.socket démarré, l’interface est accessible sur https://<serveur>:9090. Elle permet de créer une VM, d’attacher une image ISO, de configurer le réseau, de gérer les pools de stockage et de lancer une console VNC — le tout depuis un navigateur, sans X11, sans tunnel SSH.
Pour l’administration avancée, virt-manager (GTK) reste l’outil de référence avec une interface plus riche : édition XML du domaine, tuning NUMA, snapshots externes, migration à chaud. Les deux outils parlent au même démon libvirtd, donc une VM créée dans Cockpit est visible dans virt-manager et vice-versa.
Le workflow recommandé pour un homelab en juillet 2026 : installer Debian 12 ou Ubuntu 24.04 LTS, activer Cockpit pour le quotidien, garder virsh sous le coude pour l’automatisation, et documenter ses domaines en YAML avec virt-install.
Verdict : KVM pour tout ce qui tourne plus de vingt-quatre heures
Si vous virtualisez un service qui doit tourner 24/7, prenez KVM. Les raisons ne sont pas idéologiques — elles sont mécaniques : overhead CPU minimal, I/O disque contrôlé via VirtIO, passthrough PCI natif, headless par conception, API libvirt scriptable, et possibilité de migrer vers Proxmox VE ou OpenStack sans changer de stack d’hyperviseur.
Si vous testez une distrib Linux sur votre poste de travail, VirtualBox fait le job — et le fait bien. Mais la frontière est nette : au moment où la VM devient un serveur, VirtualBox n’est plus l’outil adapté.
Si vous avez un parc VMware existant, la question est économique. Broadcom a fait le calcul pour vous : depuis le rachat de 2024, les licences vSphere ont triplé en deux ans pour les PME. Le coût de migration vers KVM/libvirt — conversion des VMDK en QCOW2 via qemu-img, réécriture des scripts vCenter en virsh ou Terraform — doit maintenant être comparé au coût de rester sur VMware. Pour les nouveaux projets, la réponse est encore plus simple : KVM est le défaut.
Le même KVM qui virtualise un million d’instances EC2 chez AWS chaque minute peut virtualiser vos trois VMs Plex, Pi-hole et Home Assistant. La seule différence, c’est l’échelle — pas la stack.
Références
- Performance Comparison: KVM (QEMU) vs VMware ESXi — Pextra, août 2025
- VTmark Benchmark Suite — University of Southern Denmark, 2021
- Virtualization Costs: Benchmarking Containers and Virtual Machines Against Bare-Metal — SN Computer Science, 2021
- KVM vs VirtualBox: Speed, Performance & Best Use Cases — MonoVM, juillet 2026
- QEMU Releases — qemu.org, juillet 2026
- libvirt Releases — libvirt.org, 2025-2026
- KVM — ArchWiki
- The Security Design of the AWS Nitro System — AWS Whitepapers
- Cockpit Project — cockpit-project.org