KVM, Xen ou LXC : quel kernel pour votre VPS ?

Ce que votre offre VPS vend réellement

KVM, Xen et LXC sont les trois familles de virtualisation sur lesquelles repose une offre VPS. Ce choix ne concerne pas uniquement le rack du fournisseur. Il détermine si vous disposez de votre propre kernel. Tout ce qui compte pour l’acheteur en découle : charger des modules, contrôler le swap, exécuter une virtualisation imbriquée, déterminer si /proc décrit votre serveur ou celui d’un autre client, et savoir si le steal time est mesurable.

La virtualisation complète (KVM et Xen HVM) fournit à chaque client un kernel et une machine virtuelle. Xen paravirtualisé fournit également un kernel, mais celui-ci sait qu’il s’exécute comme guest et demande à l’hyperviseur d’effectuer les opérations privilégiées. Une offre basée sur des conteneurs (LXC, ou la gamme OpenVZ et Virtuozzo) vous fournit un système de fichiers et un ensemble de namespaces sur le kernel du fournisseur. Les trois modèles sont vendus sous les mêmes trois lettres.

KVM vs Xen vs LXC : un kernel par instance ou un kernel partagé

Avec KVM et Xen, uname -r désigne votre kernel. Vous pouvez en installer un autre, y charger un module et redémarrer dessus. Rien de ce que vous faites à cet endroit ne touche un autre tenant. Avec une offre de conteneurs, uname -r désigne le kernel du fournisseur, exécuté sur l’hôte et partagé par tous les autres conteneurs de cette machine. Vous ne pouvez pas le modifier, et apt install linux-image-generic décompressera des fichiers qui ne démarreront jamais.

Cette seule différence compte davantage que n’importe quelle fiche technique. Lisez la suite de ce guide comme une série de conséquences de cette différence.

Virtualisation complète : KVM et Xen HVM

KVM (kernel-based virtual machine) est un module du noyau Linux qui transforme un hôte Linux ordinaire en hyperviseur, en utilisant les instructions Intel VT-x ou AMD-V intégrées au CPU. QEMU fournit le matériel virtuel associé : disque, carte réseau et console série. Xen repose sur une conception différente. Xen est son propre hyperviseur et démarre avant Linux. Un domaine de contrôle privilégié appelé dom0 exécute la pile de gestion, et chaque tenant est un domU. Xen HVM (hardware virtual machine) utilise les mêmes extensions CPU que KVM, généralement avec des pilotes paravirtualisés pour le disque et le réseau, car le matériel émulé est lent. Cette combinaison s’appelle PVHVM.

Pour un tenant, les deux solutions se comportent presque à l’identique. Vous disposez d’un noyau, d’un bootloader, d’un véritable périphérique bloc, d’un modprobe fonctionnel, d’un /proc fiable, d’un swap qui vous appartient et d’un reboot qui redémarre réellement la machine. Si le fournisseur vous permet d’attacher une image ISO, vous pouvez installer une distribution qu’il ne proposait pas.

Cette isolation a un coût en densité. Vos 4 GB sont réservés à votre machine et ne peuvent pas être prêtés à un voisin lorsque vous êtes inactif. Chaque guest exécute en outre un processus QEMU et possède ses propres tables de pages ainsi que son propre page cache. C’est pourquoi un forfait KVM coûte plus cher qu’un forfait de conteneur affichant les mêmes chiffres.

Xen paravirtualisé : comment le reconnaître

Xen PV est antérieur aux processeurs dotés d’instructions de virtualisation. Au lieu d’intercepter les instructions privilégiées, le kernel invité est modifié pour appeler directement l’hyperviseur. Il fonctionne sans VT-x, ce qui était précisément l’objectif en 2005. Le kernel est chargé depuis votre propre image disque par pygrub ou pvgrub. Il s’agit donc de votre kernel, mais celui-ci doit être compilé avec la prise en charge des invités PV.

Voici les signes qui indiquent que vous utilisez ce mode : lscpu indique que le type de virtualisation est para et non full, /sys/hypervisor/type existe et identifie Xen, et vos disques sont xvda plutôt que vda ou sda. Les outils qui lisent les tables SMBIOS ou DMI ne trouvent rien, car un invité PV ne dispose d’aucun firmware capable de les publier.

Le coût est la virtualisation imbriquée, qui est définitivement impossible. Un invité PV ne voit jamais les extensions de virtualisation du processeur. Aucun hyperviseur ne peut donc fonctionner à l’intérieur. Xen n’est pas abandonné. C’est précisément Xen PV qui a perdu du terrain, tandis que le projet s’est orienté vers PVH et HVM. Si une offre mentionne « Xen », demandez de quel mode il s’agit. HVM correspond à un VPS moderne classique. PV est une offre dont le prix devrait être inférieur.

Conteneur VPS : LXC et la famille OpenVZ

Un VPS conteneur est un ensemble de namespaces Linux (des vues séparées des identifiants de processus, des points de montage, des interfaces réseau, du nom d’hôte et des utilisateurs) ainsi que des cgroups (groupes de contrôle, qui appliquent les limites de ressources du kernel), exécutés sur le kernel du fournisseur. Votre init est un processus sur l’hôte. Votre ls s’exécute directement sur le kernel de l’hôte, sans émulation ni second ordonnanceur intermédiaire. C’est pourquoi les conteneurs sont rapides et permettent une forte densité.

Les noms affichés sur une page de commande sont LXC, les conteneurs Proxmox VE (qui utilisent LXC), OpenVZ et Virtuozzo. OpenVZ 7 et Virtuozzo sont les descendants commerciaux de cette même approche.

Quatre éléments changent pour vous :

• Modules. modprobe n’insérera rien. Si WireGuard, ZFS ou un module netfilter spécifique n’est pas déjà présent dans le kernel du fournisseur, vous ne pourrez pas l’utiliser.
• sysctl. La majeure partie de /proc/sys est en lecture seule. Le réseau utilise un véritable namespace, donc net.ipv4.ip_forward et les éléments associés sont généralement accessibles en écriture. Les paramètres qui s’appliquent à toute la machine, comme vm.swappiness ou fs.file-max, appartiennent à l’hôte.
• Conteneurs imbriqués. Docker dans un conteneur LXC ne fonctionne que si le fournisseur active l’imbrication et si le storage driver est compatible. Testez cette configuration avant d’acheter, au lieu de le supposer.
• Version du kernel. Vous dépendez du calendrier de mise à niveau du fournisseur, y compris des redémarrages.

Comment déterminer ce que vous avez acheté

Exécutez ces commandes sur la machine et interprétez les résultats ensemble. Aucune commande ne permet à elle seule de trancher.

systemd-detect-virt
systemd-detect-virt -c
lscpu | grep -iE 'hypervisor|virtualization'
uname -r
ls /lib/modules/$(uname -r) 2>/dev/null | head -n 3
cat /sys/hypervisor/type 2>/dev/null

systemd-detect-virt affiche un identifiant court issu d’un vocabulaire fixe. Le côté machine inclut kvm, qemu, xen, amazon et vmware. Le côté conteneur inclut lxc, lxc-libvirt, openvz, docker et systemd-nspawn. Lorsqu’il ne détecte rien, il affiche none et se termine avec un code différent de zéro. La forme -c ne fournit une réponse que pour les technologies de conteneurs. Toute réponse différente de none permet donc de trancher, quel que soit le contenu de la page de vente.

lscpu indique le fournisseur de l’hyperviseur et précise si le type de virtualisation est full ou para. C’est ainsi que vous pouvez distinguer Xen HVM de Xen PV. /sys/hypervisor/type existe uniquement sous Xen.

La vérification /lib/modules est souvent ignorée, alors qu’il s’agit de la méthode la plus directe. Si le répertoire correspondant à la version du kernel en cours d’exécution est absent ou vide alors que le système utilise manifestement ce kernel, celui-ci ne provient pas de votre système de fichiers. Il provient de l’hôte, et son arborescence de modules n’a jamais été installée dans votre image. Il s’agit donc d’un conteneur.

Pour obtenir un deuxième avis indépendant, sudo apt install -y virt-what && sudo virt-what exécute les tests de détection comme outil dédié. Il nécessite root et n’affiche absolument rien sur une machine bare metal.

Pourquoi /proc décrit la mauvaise machine dans un conteneur

Sur un invité KVM ou Xen, /proc/meminfo correspond au suivi de la mémoire que votre propre noyau comptabilise parmi celle que l’hyperviseur vous a attribuée. Ces informations concernent bien votre machine et ne disent rien sur l’hôte. C’est le principe d’une machine virtuelle.

Dans un conteneur, aucun second noyau n’effectue ce suivi. /proc correspond donc au /proc de l’hôte. LXCFS est un petit système de fichiers qui réécrit certains de ces fichiers pour les adapter aux limites de votre cgroup. Il prend en charge /proc/cpuinfo, /proc/meminfo, /proc/stat, /proc/uptime, /proc/swaps, /proc/diskstats et /sys/devices/system/cpu/online. Proxmox le monte par défaut. De nombreux petits fournisseurs ne le font pas. Dans ce cas, free -m indique la mémoire totale de l’hôte, nproc peut indiquer le nombre total de cœurs de la machine et uptime indique depuis combien de temps l’hôte fonctionne.

Ce problème n’est pas seulement esthétique, car les logiciels dimensionnent leurs ressources à partir de ces fichiers. nginx avec worker_processes auto compte les cœurs qu’il peut voir. make -j$(nproc), exécuté sur un hôte doté de 64 cœurs avec un quota de 2 cœurs, démarre 64 compilateurs. Une JVM ou une base de données qui choisit la taille de son cache à partir de MemTotal peut sélectionner une valeur que votre cgroup refusera. Le kernel tue alors le processus lorsqu’il atteint la limite. Cette terminaison est inscrite dans le journal du kernel de l’hôte, que vous ne pouvez pas lire.

Les valeurs de référence se trouvent dans le cgroup, et non dans /proc :

cat /sys/fs/cgroup/memory.max
cat /sys/fs/cgroup/memory.current
cat /sys/fs/cgroup/cpu.max

Il s’agit de chemins cgroup v2, utilisés par les distributions actuelles. La lecture de memory.max dans max signifie qu’aucune limite n’est définie à ce niveau. cpu.max affiche un quota et une période en microsecondes. Ainsi, 200000 100000 correspond à 2 cœurs de temps CPU par période. Sur un hôte plus ancien utilisant cgroup v1, les mêmes valeurs se trouvent sous /sys/fs/cgroup/memory/memory.limit_in_bytes et /sys/fs/cgroup/cpu/cpu.cfs_quota_us.

Swap et gestion effective

Avec KVM et Xen, le swap vous appartient. Il s’agit d’un fichier ou d’une partition sur votre disque, et c’est votre kernel qui gère la pagination.

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
swapon --show

swapon --show doit maintenant afficher le fichier avec sa taille et sa priorité. Si swapon refuse le fichier, créez-le plutôt avec dd if=/dev/zero of=/swapfile bs=1M count=2048, car un fichier préalloué contenant des extents non écrits est rejeté sur certains systèmes de fichiers. Ajoutez /swapfile none swap sw 0 0 à /etc/fstab, sinon le swap disparaîtra au prochain redémarrage.

Dans un conteneur, rien de tout cela ne vous appartient. swapon nécessite une capability qu’un conteneur non privilégié ne possède pas. La création de votre propre fichier de swap échoue donc au niveau des permissions et n’atteint jamais le disque. Le swap mentionné dans l’offre correspond à un paramètre cgroup défini sur l’hôte, memory.swap.max avec cgroup v2, et adossé aux propres périphériques de swap de l’hôte. Les anciennes offres OpenVZ vendaient une capacité « vswap » qui ressemblait davantage à un crédit de dépassement qu’à un disque. Vous pouvez lire la limite. Vous ne contrôlez pas le périphérique qui se trouve derrière.

Virtualisation imbriquée et indicateur CPU trompeur

La virtualisation imbriquée consiste à exécuter un hyperviseur dans votre VPS : un invité QEMU, une box Vagrant ou un laboratoire de virtualisation imbriquée avec ses propres VM. Deux conditions doivent être réunies. Le fournisseur doit activer la virtualisation imbriquée sur l’hôte, et les extensions de virtualisation du CPU doivent être présentées à votre invité.

lscpu | grep -i virtualization
ls -l /dev/kvm
sudo apt install -y cpu-checker && sudo kvm-ok

Sur un invité KVM avec la virtualisation imbriquée activée, /dev/kvm existe et kvm-ok indique clairement si l’accélération peut être utilisée. Avec Xen HVM, c’est techniquement possible, mais rarement proposé. Avec Xen PV, c’est impossible.

Dans un conteneur, la vérification échoue de manière instructive. /proc/cpuinfo est le fichier de l’hôte. L’indicateur vmx ou svm est donc présent, et il est réellement valide : le CPU physique auquel vous avez accès possède bien ces instructions. Elles ne sont toutefois pas à votre disposition. Aucun /dev/kvm n’existe dans votre namespace, vous ne pouvez pas charger le module kvm_intel, et l’indicateur que vous venez de lire décrit la machine sur laquelle vous êtes hébergé, pas une machine que vous contrôlez. C’est le cas le plus clair de la règle générale. Dans un conteneur, /proc décrit le namespace et le matériel qui l’entoure, pas un serveur dont vous êtes propriétaire.

AES-NI et les fonctionnalités CPU exposées par votre offre

AES-NI (advanced encryption standard new instructions) est un ensemble d’instructions CPU qui accélèrent plusieurs fois le chiffrement AES par rapport au même calcul effectué en logiciel. La terminaison TLS, le chiffrement des disques, SSH et les pipelines de sauvegarde en dépendent tous.

Avec KVM, les fonctionnalités visibles par votre système invité dépendent du modèle de CPU configuré par le fournisseur pour QEMU. Avec host passthrough, vous voyez les flags réels. Avec un modèle générique comme qemu64, ou avec une baseline volontairement ancienne choisie pour permettre la migration des invités entre des hôtes différents, le flag aes peut être absent. OpenSSL revient alors discrètement à son chemin d’exécution logiciel.

lscpu | grep -ow aes | head -n 1
openssl speed -evp aes-128-gcm
env OPENSSL_ia32cap='~0x200000000000000:~0x20000000000:~0x0:~0x0:~0x0' openssl speed -evp aes-128-gcm

La troisième commande est l’exemple du manuel OpenSSL permettant de désactiver ces instructions dans la bibliothèque : elle efface le bit AES-NI et le bit VAES, sans modifier le reste. Comparez les deux débits. S’ils sont proches, le chemin rapide n’était pas utilisé au départ. Dans ce cas, vérifier correctement la présence d’AES-NI sur un VPS vaut les cinq minutes nécessaires avant de souscrire une offre.

Un conteneur n’a pas de modèle de CPU qui lui soit propre. Les flags présents dans /proc/cpuinfo sont donc les flags réels de l’hôte et s’appliquent à votre conteneur. C’est un véritable avantage des offres basées sur des conteneurs. C’est aussi le seul point de ce guide où le kernel partagé joue en votre faveur.

D’où vient le steal time et pourquoi un conteneur n’en a pas

Le steal time correspond au temps pendant lequel votre CPU virtuel était prêt à s’exécuter, mais ne l’a pas fait parce que l’hyperviseur exécutait une autre charge. Il apparaît sous la forme de st dans top et vmstat, ainsi que dans le huitième champ de la ligne cpu de /proc/stat.

Un guest ne peut pas mesurer cette durée lui-même, car il n’exécute aucun code pendant qu’elle s’écoule. L’hyperviseur doit la lui communiquer. KVM écrit un total cumulé dans une page que le guest enregistre via son interface d’horloge paravirtualisée. Xen conserve un état d’exécution propre à chaque vCPU pour le même usage. La valeur lue provient directement de l’hyperviseur. C’est pourquoi elle existe et pourquoi elle est fiable.

Un steal time élevé signifie que l’hôte est surabonné et que vos voisins utilisent fortement les ressources à cet instant. Il reflète le rapport entre les vCPU vendus et les cœurs physiques. Lire le steal time pour détecter un voisin bruyant est la seule mesure qui permet de vérifier si une offre fournit réellement les ressources annoncées.

vmstat 1 5
cat /sys/fs/cgroup/cpu.stat

Dans un conteneur, cette colonne ne change pas, car aucun hyperviseur ne se trouve entre vous et le scheduler. Vos processus sont mis en file avec ceux des autres tenants comme des tâches ordinaires dans le scheduler CPU de l’hôte. La contention se traduit simplement par une durée d’exécution plus longue, sans compteur indiquant sa cause. L’équivalent le plus proche est le throttling du quota : lorsque le fournisseur définit cpu.max, /sys/fs/cgroup/cpu.stat compte les périodes nr_throttled et throttled_usec microsecondes passées à attendre la prochaine fenêtre de quota. Cela ne couvre que votre propre quota, jamais la concurrence des voisins. Attention : si l’hôte de conteneurs du fournisseur est lui-même une machine virtuelle, une valeur de steal peut apparaître dans /proc/stat. Elle concerne alors cet hôte, pas votre conteneur.

Surallocation : pourquoi l’offre conteneur est moins chère

La réponse est simple. Une offre conteneur coûte moins cher parce que le fournisseur partage la même machine entre davantage de clients.

La différence est la plus importante pour la mémoire. La RAM d’un invité KVM lui est affectée. Un hôte doté de 256 GB peut donc vendre environ 256 GB de RAM d’invités, moins la surcharge. La limite mémoire d’un conteneur est un plafond, pas une réservation. La mémoire qu’un conteneur n’utilise pas est immédiatement disponible pour les autres. Le fournisseur peut donc vendre des limites dont le total atteint plusieurs fois la RAM physique et rester dans le vrai presque tout le temps. Rien n’est simulé. Cela fonctionne jusqu’à ce qu’un nombre suffisant de clients utilise intensivement leurs ressources en même temps. À ce moment-là, cela cesse de fonctionner pour tout le monde.

Le CPU est suralloué avec tous les types d’offres, y compris KVM, en vendant plus de vCPU qu’il n’y a de cœurs. Le stockage est presque toujours provisionné en mode thin provisioning. Les conteneurs augmentent encore la densité : un seul kernel, un seul page cache et aucun processus QEMU par invité. Un hôte peut donc héberger plusieurs fois plus de clients.

En contrepartie, vous perdez en isolation. C’est un compromis d’ingénierie réel, pas un argument alarmiste. Vous partagez un kernel. Une faille du kernel devient donc un problème commun, et une sortie de conteneur donne directement accès à l’hôte. Pour sortir d’une machine virtuelle, il faut exploiter une faille de l’hyperviseur. La cible est donc bien plus réduite et plus difficile à attaquer. Vous dépendez également du calendrier du fournisseur pour les mises à niveau du kernel et les redémarrages. Si l’un de ces points est important pour vous, consultez la sécurité réelle de l’hébergement VPS avant de choisir uniquement en fonction du prix.

Lequel choisir

Choisissez KVM si vous avez besoin de votre propre kernel : modules WireGuard ou ZFS, version spécifique du kernel, virtualisation imbriquée, contrôle réel du swap ou isolation que vous pouvez expliquer à un auditeur. Choisissez une offre de conteneurs si vous exécutez des services courants avec un budget limité, si le kernel du fournisseur est à jour et si vous avez vérifié que les fonctionnalités dont vous dépendez y sont déjà compilées. Pour la plupart des usages, considérez Xen HVM comme équivalent à KVM. Posez la question avant d’acheter une offre encore vendue sous Xen PV.

Deux modèles ne correspondent pas à cette distinction. Les microVM Firecracker fournissent à chaque locataire un kernel réel avec un temps de démarrage proche de celui d’un conteneur. C’est ce qu’utilisent les plateformes serverless. Les conteneurs système Incus vous permettent d’exécuter vous-même le modèle des conteneurs sur du matériel que vous contrôlez. Cela diffère d’une offre de conteneurs fournie par un prestataire. Si la terminologie vous pose problème, ce qu’est réellement un VPS et la différence entre un VPS, une VM et un VPC présentent les termes considérés comme acquis dans ce guide.

FAQ

Comment savoir si mon VPS est une VM KVM ou un conteneur ?

Exécutez systemd-detect-virt -c. Toute réponse autre que none signifie que vous êtes dans un conteneur, quel que soit le nom du produit indiqué par l’offre. Confirmez-le de deux autres façons, car la détection peut être faussée. lscpu indique le fournisseur de l’hyperviseur et précise si le type de virtualisation est complète ou paravirtualisée. ls /lib/modules/$(uname -r) est absent ou vide dans un conteneur, car le noyau utilisé vient de l’hôte et son arborescence de modules n’a jamais été installée dans votre système de fichiers. sudo virt-what fournit une réponse indépendante à l’aide d’un outil conçu uniquement pour cette question.

Pourquoi free -m indique-t-il beaucoup plus de mémoire que mon offre n’en inclut ?

Vous utilisez une offre conteneur sans LXCFS monté. /proc/meminfo correspond donc au fichier de l’hôte et free indique fidèlement la mémoire de l’hôte. Votre limite réelle est celle du cgroup. Consultez /sys/fs/cgroup/memory.max pour connaître la limite et /sys/fs/cgroup/memory.current pour l’utilisation actuelle, ou /sys/fs/cgroup/memory/memory.limit_in_bytes sur un hôte plus ancien utilisant cgroup v1. Configurez tout service qui dimensionne un cache ou un pool de workers à partir de cette valeur, et non de free.

Puis-je exécuter Docker ou WireGuard sur un VPS LXC ?

Parfois, mais jamais grâce à un élément que vous installez. Les deux dépendent du noyau du fournisseur, car vous ne pouvez pas y charger de module. WireGuard fonctionne lorsque le module est déjà présent sur l’hôte et vous est exposé. Sinon, l’implémentation userspace wireguard-go constitue la solution de repli. Docker nécessite que le fournisseur autorise la virtualisation imbriquée et qu’un pilote de stockage fonctionne dans le conteneur. Renseignez-vous avant d’acheter, ou faites un test avec une offre que vous pouvez résilier sans difficulté.

Pourquoi mon VPS conteneur n’indique-t-il jamais de steal time ?

Le steal time existe uniquement lorsqu’un hyperviseur ordonnance un processeur virtuel. Il est indiqué parce que cet hyperviseur écrit la valeur dans une page que votre noyau lit. Un conteneur n’a aucun hyperviseur sous-jacent. Vos processus sont des tâches ordinaires dans l’ordonnanceur de l’hôte. La contention se manifeste donc par un ralentissement général, sans compteur permettant de l’identifier. Consultez plutôt /sys/fs/cgroup/cpu.stat : nr_throttled et throttled_usec comptabilisent le temps pendant lequel votre cgroup a attendu sa prochaine fenêtre de quota CPU. C’est l’équivalent le plus proche du steal time pour un conteneur.