Comment KVM fonctionne en interne
KVM convertit le noyau Linux en hyperviseur de Type 1 en exposant un périphérique caractère /dev/kvm. Un processus en espace utilisateur (généralement QEMU) ouvre ce périphérique, demande au noyau de créer un CPU virtuel, puis exécute les instructions de l'invité directement sur le CPU physique grâce aux extensions de virtualisation matérielle. Le noyau gère les événements privilégiés ; tout le reste s'exécute à la vitesse native.
Trois composants permettent à KVM de fonctionner. D'abord, le module kernel kvm.ko qui gère la virtualisation du CPU et de la mémoire et expose l'interface /dev/kvm. Ensuite, un module spécifique à l'architecture — kvm-intel.ko pour Intel VT-x ou kvm-amd.ko pour AMD-V — qui traduit entre l'API KVM générique et les instructions de virtualisation du CPU sous-jacent. Enfin, un processus hyperviseur en espace utilisateur tel que QEMU, cloud-hypervisor ou Firecracker, qui fournit l'émulation des périphériques : disques virtuels, NIC, contrôleurs USB et firmware BIOS ou UEFI. Comme le noyau Linux lui-même est l'hyperviseur, l'ordonnanceur, le gestionnaire de mémoire et chaque fonction de sécurité s'appliquent aux VM de la même manière qu'aux processus natifs. Du point de vue du noyau, un invité KVM n'est qu'un processus poids lourd, ce qui explique pourquoi des outils comme top, perf et cgroups fonctionnent dessus sans modification.
KVM vs OpenVZ vs VMware ESXi vs Hyper-V
KVM offre une virtualisation matérielle complète avec un noyau invité distinct pour chaque VM. OpenVZ utilise une conteneurisation au niveau du système d'exploitation où chaque conteneur partage le noyau hôte. VMware ESXi est un hyperviseur de Type 1 propriétaire bare metal avec son propre noyau (VMkernel). Hyper-V est l'hyperviseur de Type 1 de Microsoft basé sur Windows. Seuls KVM, ESXi et Hyper-V vous offrent un noyau invité réel et isolé.
OpenVZ (et son successeur Virtuozzo) est une technologie de conteneurs, pas un hyperviseur. Chaque conteneur OpenVZ partage le noyau Linux de l'hôte, ce qui signifie que vous ne pouvez pas exécuter une version différente du noyau, charger des modules personnalisés, ni faire tourner un système d'exploitation non Linux. Le compromis tient à la densité : sans surcoût d'un noyau par VM, un hôte OpenVZ peut entasser plus de conteneurs sur le même matériel, raison pour laquelle les forfaits VPS partagés bas de gamme l'utilisaient fréquemment. VMware ESXi est le standard d'entreprise pour la virtualisation de Type 1, mais il est livré comme produit propriétaire avec une licence par socket qui l'a historiquement écarté de l'hébergement VPS de masse. Hyper-V domine les environnements Windows Server et s'intègre étroitement avec Active Directory et System Center, mais reste un choix moins courant pour les flottes d'hébergement principalement Linux. KVM est devenu la norme de l'hébergement VPS moderne parce qu'il est open source, intégré au noyau principal, prend en charge tout système invité tournant sur x86_64 ou aarch64 et dispose d'un écosystème de gestion mature (libvirt, oVirt, Proxmox, OpenStack Nova).
Pourquoi KVM est le choix par défaut moderne pour le VPS
KVM est devenu la technologie VPS dominante parce qu'elle offre à chaque client un noyau réel et isolé sans la facture des licences à la VMware. Elle prend en charge les invités Linux, Windows, BSD et Solaris, fonctionne sur du matériel x86_64 et ARM courant et est intégrée à toutes les grandes piles d'orchestration cloud — OpenStack, Proxmox VE, Kubernetes via KubeVirt et AWS Nitro reposent dessus.
Trois forces ont convergé pour faire de KVM le standard. D'abord, les extensions de virtualisation matérielle se sont généralisées : Intel VT-x est arrivé sur les puces Core 2 en 2006 et AMD-V sur les premiers Athlon 64 ; ainsi, dès le début des années 2010, virtuellement tout CPU serveur pouvait héberger KVM à une vitesse quasi native. Ensuite, la communauté Linux a refusé d'adopter la paravirtualisation à la Xen dans le tronc principal mais a intégré KVM en 2007, dotant instantanément chaque distribution d'un hyperviseur intégré. Enfin, l'écosystème du cloud public a investi massivement : Google Cloud Engine s'est lancé sur KVM, AWS a migré de Xen vers une architecture Nitro basée sur KVM et OpenStack a standardisé KVM comme hyperviseur de référence. Les hébergeurs VPS plus petits bénéficient de cette traction parce que le même outillage qui anime les flottes des hyperscaleurs — libvirt, pilotes virtio, cloud-init — fonctionne aussi sur un simple rack de serveurs courants.
Caractéristiques de performance réelles : CPU steal, IO et surcoût
Sur un hôte KVM correctement provisionné, attendez-vous à un surcoût CPU de quelques pour cent par rapport au bare metal, à une latence réseau ajoutée inférieure à la milliseconde sur les chemins du réseau local et à 80-95 % des IOPS disque natifs lorsque virtio-blk ou virtio-scsi est utilisé avec un pilote paravirtualisé. Un CPU steal soutenu au-dessus de 5 % est le signe canonique d'une surengagement de l'hôte et un fort signal de mise à niveau.
Trois chiffres comptent pour un invité KVM en production. Le CPU steal time, exposé dans /proc/stat comme huitième champ, mesure le pourcentage de temps pendant lequel le CPU virtuel était prêt à s'exécuter mais où le CPU physique était occupé par d'autres invités. Tout ce qui reste sous 1-2 % est du bruit de fond normal ; des valeurs soutenues au-dessus de 5 % signifient que l'hôte est surengagé et que votre charge est bridée. L'IO wait, remonté par des outils comme iostat et top, mesure le pourcentage de temps pendant lequel le CPU était bloqué sur le disque ou le réseau. Avec des pilotes paravirtualisés virtio et un stockage NVMe moderne en arrière, un IO wait soutenu au-dessus de 20 % sur une charge censée être bornée par le CPU est un signe fort que le sous-système disque est saturé. Le débit réseau sur virtio-net devrait atteindre 80-95 % du débit ligne du NIC physique ; toute valeur sensiblement inférieure pointe vers un offload mal configuré ou un ancien pilote émulé e1000.
Quand NE PAS utiliser KVM
KVM est le mauvais choix dans trois cas : charges conteneurisées à très haute densité où le surcoût du noyau par VM domine, déploiements sensibles aux licences Windows où la tarification SPLA d'Hyper-V est sensiblement plus avantageuse, et certains scénarios de passthrough matériel à faible latence où SR-IOV ou le passthrough GPU sont mal pris en charge sur votre modèle spécifique de NIC ou GPU.
Pour des microservices conteneurisés qui n'ont pas besoin d'isolation au niveau du noyau, des conteneurs Linux (Docker, Podman, Kubernetes) tournant directement sur le bare metal pourront tasser de 3 à 5 fois plus que tout VPS basé sur KVM, car chaque conteneur n'est qu'un groupe de processus avec namespaces et cgroups. Les hébergeurs VPS bas coût sensibles à la densité ont historiquement choisi OpenVZ pour la même raison. Les déploiements lourds en Windows — en particulier ceux faisant tourner des licences Windows Server achetées via SPLA — paient parfois sensiblement moins sur Hyper-V que sur KVM en raison de la façon dont Microsoft tarifie les licences invitées sur des hyperviseurs concurrents. Enfin, certains scénarios de passthrough matériel restent pénibles sur KVM : le passthrough GPU exige des groupes IOMMU proprement isolés, certains NIC grand public n'ont pas de prise en charge SR-IOV et le passthrough PCIe de disques NVMe déclenche parfois des contournements pour bug de reset. Pour 95 % des charges VPS Linux à usage général, aucun de ces cas ne s'applique et KVM est le bon choix par défaut.
Comment vérifier qu'un VPS est réellement basé sur KVM
À l'intérieur d'un invité Linux, exécutez `systemd-detect-virt` — il devrait afficher `kvm`. Recoupez avec `lscpu` (la ligne « Hypervisor vendor » devrait indiquer « KVM ») et `dmesg | grep -i kvm`. Si vous voyez « OpenVZ », « lxc » ou « VMware » à la place, votre fournisseur utilise une autre technologie, quoi qu'en dise le marketing.
Avant de signer un contrat, lancez une petite batterie de diagnostics sur un VPS d'essai. Exécutez `systemd-detect-virt` pour la sortie de détection canonique. Lancez `cat /proc/cpuinfo | grep -E 'vmx|svm'` pour vérifier que les extensions de virtualisation matérielle sont passées (certains fournisseurs les masquent, ce qui casse la virtualisation imbriquée). Faites `uname -r` pour vérifier que vous voyez bien un noyau spécifique à l'invité plutôt qu'un noyau d'hôte partagé — sur un vrai VPS KVM, vous pouvez installer un autre noyau via `apt install linux-image-...` ou `dnf install kernel-...` et redémarrer dessus. Sur OpenVZ, c'est impossible. Enfin, vérifiez `/proc/user_beancounters` — si ce fichier existe, l'hôte tourne sous OpenVZ, peu importe ce que dit le marketing.