KVM vs OpenVZ vs LXC : ce que le type de virtualisation de votre VPS vous autorise réellement à faire

Deux offres VPS, sur la même page. Quatre vCPU, 8 Go de RAM, 160 Go de stockage, prix presque identique. L'une indique KVM. L'autre indique OpenVZ. Aucune des deux pages n'explique ce que ce mot change.

Elle change ce que vous avez le droit d'exécuter. Les types de virtualisation VPS ne sont pas une simple note de bas de page sur les performances. Ils déterminent si vous contrôlez le noyau, si Windows est possible et si Docker fonctionne sans l'intervention de l'hébergeur. KVM vs OpenVZ vs LXC est d'abord une question de capacités, avant d'être une question de vitesse.

Ce guide traite des trois appellations les plus pertinentes pour cette décision d'achat. Xen, VMware, Hyper-V et d'autres plateformes de virtualisation existent, mais elles sortent du cadre de cette comparaison à trois.

En bref

• KVM donne à chaque VPS son propre noyau invité. Docker fonctionne normalement, Windows est techniquement possible et vous pouvez généralement charger des modules noyau ou démarrer un noyau personnalisé. En revanche, KVM seul ne garantit pas de CPU ni de RAM dédiés ; les engagements de ressources dépendent toujours de l'hébergeur et de l'offre.
• OpenVZ les offres VPS sont normalement des conteneurs Linux qui partagent le noyau de l'hôte. Docker ne peut fonctionner sous OpenVZ 7 que si l'hébergeur utilise un noyau et une configuration de modèle compatibles. Vous ne pouvez pas remplacer le noyau de l'hôte, et la mémoire au-delà de la RAM passe par le VSwap contrôlé par l'hébergeur plutôt que par un swap disque géré par l'invité.
• LXC partage lui aussi le noyau de l'hôte, mais il repose sur les fonctions de cloisonnement du noyau Linux principal. Docker peut fonctionner si l'hôte active les fonctions requises, même si Proxmox recommande d'imbriquer les conteneurs dans une machine virtuelle QEMU pour les charges qui exigent une isolation maximale et la migration à chaud.
• Les conteneurs sont généralement plus faciles à redimensionner à chaud. KVM peut lui aussi prendre en charge l'ajout à chaud de CPU et de mémoire, donc « KVM impose toujours un redémarrage » n'est pas une règle d'achat fiable. Demandez à l'hébergeur ce que sa plateforme prend réellement en charge.
• Pour un site statique ou une petite pile LAMP qui n'a jamais besoin de Docker, de Windows ni de personnalisation au niveau du noyau, la différence pratique peut être minime. L'isolation, le cycle de vie et la politique de ressources peuvent tout de même varier.

La seule différence qui entraîne toutes les autres

KVM donne à chaque VPS de l'hôte son propre noyau invité. Les conteneurs OpenVZ et LXC utilisent le noyau démarré par l'hôte.

KVM est une solution de virtualisation complète pour le matériel x86 doté d'extensions de virtualisation. Il a été intégré au noyau Linux principal à partir de la version 2.6.20. Chaque invité voit du matériel virtuel et démarre son propre système d'exploitation et son propre noyau.

Les types de conteneurs fonctionnent différemment. LXC est une interface en espace utilisateur pour les fonctions de cloisonnement du noyau Linux, notamment les namespaces, les cgroups, les capabilities, seccomp et les profils de sécurité. Son but est d'offrir un environnement proche d'une installation Linux classique, sans démarrer de noyau distinct.

Un conteneur OpenVZ suit le même modèle général de noyau partagé, bien qu'OpenVZ utilise sa propre plateforme et sa propre pile noyau. OpenVZ 7 peut gérer à la fois des conteneurs et des machines virtuelles KVM, mais lorsqu'une offre VPS grand public porte la mention « OpenVZ », le produit vendu est normalement le type conteneur.

Toutes les différences de capacités ci-dessous en découlent. Un module noyau doit être chargé dans un noyau que vous contrôlez. Un système d'exploitation différent exige un noyau différent. Docker a besoin d'un cloisonnement au niveau du noyau, disponible là où réside le noyau lui-même. Du côté KVM de cette frontière, la couche hyperviseur suit une architecture couramment répartie entre hyperviseurs de type 1 et de type 2.

LXC apparaît souvent dans des environnements Proxmox, y compris sur des serveurs autogérés et certaines plateformes d'hébergement. La possibilité d'activer les fonctions avancées de LXC dépend de qui contrôle cet hôte.

LIRE

KVM vs OpenVZ 2022 : qui est l'as de la virtualisation ?

Ce que chaque type vous permet d'exécuter

Les axes qui déterminent l'achat sont le contrôle du noyau, la prise en charge du système d'exploitation invité, la compatibilité Docker, le comportement de la mémoire, le redimensionnement et la politique de ressources.

Lequel choisir ? KVM est la réponse la plus nette lorsque vous avez besoin de Windows, d'un noyau personnalisé, de modules chargés par l'invité ou d'un hôte Docker prévisible. OpenVZ et LXC peuvent constituer des environnements Linux efficaces, mais ils laissent les décisions au niveau du noyau à l'hébergeur.

Il s'agit d'une carte des capacités, pas d'un banc d'essai. Elle ne dit rien de la latence du stockage, de la qualité du réseau, de la génération de CPU, du taux d'occupation de l'hôte ni de la politique d'allocation des ressources de l'hébergeur. Deux hébergeurs utilisant le même type de virtualisation peuvent livrer des machines très différentes.

C'est sur les cases conditionnelles que les acheteurs perdent du temps. J'ai un jour déployé un VPN sur un VPS conteneurisé où la fonction réseau requise côté hôte n'était pas exposée. L'interface refusait de se lever, et la correction a exigé un ticket au support plutôt qu'un changement de configuration dans l'invité. Avec une offre conteneur, demandez si l'hébergeur expose exactement le périphérique ou la fonction noyau dont votre VPN a besoin. Avec KVM, vous contrôlez normalement cela depuis l'invité.

Pourquoi Docker est la question qui tranche la plupart des achats

VPS conteneurisé contre VPS KVM cesse d'être une comparaison abstraite dès que Docker figure dans vos exigences. Docker lui-même utilise les namespaces du noyau, les cgroups, le réseau et les pilotes de stockage. Sous KVM, ces fonctions appartiennent au noyau invité que vous contrôlez. Sous OpenVZ ou LXC, elles dépendent en dernier ressort de l'hôte.

Docker sur OpenVZ

La prise en charge de Docker sur OpenVZ est une décision de provisionnement prise au-dessus de vous. Un article du support SolusVM indique que Docker peut fonctionner dans OpenVZ 7 à partir d'une version de noyau 3.10 donnée, mais précise aussi que Docker ne fonctionne pas avec les modèles précréés hérités standard. Le conteneur doit utiliser un modèle EZ ou un modèle personnalisé adapté. Ce même article exclut les invités CentOS 8.

Alors, Docker fonctionne-t-il sous OpenVZ ? Parfois. L'hébergeur doit avoir bâti le service autour d'un noyau OpenVZ 7 compatible et d'une chaîne de modèles adaptée. Si la page de l'offre ne l'indique pas clairement, interrogez le support avant d'acheter et conservez la réponse par écrit.

Lorsque la configuration de l'hôte est incompatible, modifier les options de Docker à l'intérieur du VPS ne résoudra pas le problème de fond. Il faut que l'hébergeur change la configuration du conteneur ou vous bascule vers un autre type de virtualisation.

Docker sur LXC

Docker peut fonctionner dans LXC lorsque l'hôte expose les fonctions requises. Sous Proxmox, cela inclut couramment l'imbrication de conteneurs et keyctl pour les conteneurs non privilégiés.

Le signal d'achat le plus important reste la recommandation de l'éditeur de la plateforme. La documentation de Proxmox précise ceci : imbriquer des conteneurs dans une VM QEMU Proxmox reste une pratique recommandée pour les cas d'usage qui exigent une isolation maximale et la migration à chaud, plutôt que de les exécuter directement dans un conteneur système LXC.

Si vous contrôlez l'hôte LXC, vous pouvez évaluer ce compromis et tester les mises à niveau à votre rythme. Si vous louez un VPS LXC, c'est l'hébergeur qui contrôle le noyau, le profil de sécurité et les options avancées. Confirmez la configuration prise en charge au lieu de supposer qu'un accès root dans le conteneur suffit.

Docker sur KVM

Docker fonctionne normalement parce que l'invité Linux contrôle son propre environnement noyau. Il n'y a ni commutateur d'imbrication LXC ni exigence de modèle OpenVZ au-dessus de l'invité. Il vous faut toujours une distribution Linux prise en charge, un noyau compatible, et assez de RAM et de stockage pour la charge de travail.

Posséder le noyau invité, c'est aussi devoir l'entretenir. Sur un VPS non infogéré, les mises à jour, les règles de pare-feu, la sécurité de Docker et les sauvegardes restent à votre charge.

Point clé : Docker ne rend pas OpenVZ ou LXC impossibles, mais il fait de la configuration de l'hébergeur une composante de la fiabilité de votre application. Pour un hôte Docker de production loué, KVM supprime cette dépendance supplémentaire.

« 4 vCPU » signifie-t-il quatre cœurs de processeur dédiés

Un VPS qui paraît lent alors que sa propre supervision affiche un CPU au repos : c'est le symptôme le plus souvent décrit. La virtualisation par conteneurs est ce qui le rend possible. La contention se produit une couche en dessous de ce que l'invité peut voir, si bien que ses propres métriques n'indiquent rien d'anormal.

Le mécanisme, c'est le faible surcoût lui-même. Un conteneur coûte à l'hôte bien moins qu'une machine virtuelle complète, donc davantage de conteneurs tiennent sur le même matériel. Cette densité est peu coûteuse à créer et difficile à détecter depuis l'invité, ce qui rend la survente structurellement plus facile sous OpenVZ que sous KVM. KVM n'empêche pas un hébergeur de tasser un hôte. Mais il engage de la mémoire réelle et des parts de CPU réelles par invité, ce qui impose un plafond arithmétique au tassement. Le versant diagnostic a son propre guide sur comment savoir si votre hébergeur pratique la survente.

La mémoire se comporte elle aussi différemment. Sous OpenVZ, vous ne pouvez pas utiliser le swap disque comme mémoire supplémentaire : le chiffre de RAM affiché sur la page de l'offre est donc un mur, pas une pente. Un invité KVM sous pression mémoire ralentit. Un conteneur OpenVZ sous pression mémoire voit ses processus tués.

Il y a aussi une conséquence en matière d'isolation, et c'est celle que l'on sous-estime le plus. La mémoire d'un conteneur est adressable depuis l'hôte, ce qui n'est pas le cas de celle d'un invité KVM. Le chiffrement du disque dans l'invité vous protège toujours contre le vol d'un disque. Il ne protège pas les clés d'un conteneur en cours d'exécution contre la machine qui l'exécute. Si votre modèle de menace inclut l'opérateur de l'hôte, un noyau partagé est le mauvais substrat. Aucune configuration à l'intérieur de l'invité n'y change rien.

Point clé : le même chiffre sur une page d'offre ne constitue pas la même promesse selon le type. Sous KVM, c'est une allocation. Sous OpenVZ, c'est un plafond que vous partagez.

Où OpenVZ garde du sens, et où il se dirige

Hébergez un site statique ou une pile LAMP à faible trafic et vous ne toucherez peut-être jamais aux capacités qu'OpenVZ restreint. Pas de Windows, pas de noyau personnalisé, pas de module chargé par l'invité, pas de Docker en production. Pour cette charge de travail étroite, un conteneur OpenVZ bien exploité fait encore l'affaire.

Le cycle de vie exige plus d'attention qu'il y a dix ans. OpenVZ 7 repose sur la branche noyau de RHEL 7, la version 3.10. Le numéro de version à lui seul ne prouve pas qu'un noyau d'entreprise maintenu manque de correctifs de sécurité, car les éditeurs rétroportent les patchs. Il signifie en revanche que vous devriez vérifier la compatibilité avec les logiciels qui attendent des interfaces noyau plus récentes.

The open-source OpenVZ project and the commercial Virtuozzo product are on separate tracks, and the commercial one has published dates. Virtuozzo Hybrid Server 7 reached end of maintenance in July 2024 and is listed for end of life in December 2027 in the politique officielle de cycle de vie.

Cela ne casse pas un site OpenVZ qui fonctionne aujourd'hui. En revanche, cela rend le plan de migration de l'hébergeur pertinent avant d'y engager une charge de travail durable. Demandez quelle version d'OpenVZ ou de Virtuozzo tourne, comment les correctifs de sécurité sont livrés et quel chemin de migration existe.

Quand une page d'offre ne nomme pas le type de virtualisation, interrogez le support plutôt que de le déduire du prix. La réponse mérite d'être conservée par écrit.

Choisir selon la charge de travail

Partez du besoin plutôt que de la technologie.

Choisissez KVM quand la charge de travail a besoin de son propre noyau

KVM est le choix direct dès que vous avez besoin de l'un des éléments suivants :

• Windows comme système d'exploitation invité
• Un noyau personnalisé
• Des modules noyau chargés par l'invité
• Docker en production sans dépendances de conteneur dans conteneur
• La virtualisation imbriquée, lorsque l'hébergeur l'expose
• Un swap et un réglage du noyau contrôlés par l'invité

Windows est décisif parce que les conteneurs OpenVZ comme LXC utilisent un noyau hôte Linux. Choisir entre Linux et Windows pour l'application elle-même est une autre question, qui touche à la compatibilité logicielle, à l'administration et aux licences. Voyez la comparaison VPS Linux et Windows pour cette décision.

Choisissez LXC quand vous voulez un conteneur système Linux efficace

LXC est rationnel quand la charge de travail est uniquement Linux, n'a pas besoin d'un noyau distinct et tire parti d'un faible surcoût ou de changements rapides gérés par l'hôte. Il est particulièrement utile lorsque vous contrôlez vous-même l'hôte Proxmox ou LXC.

Pour un VPS LXC loué, vérifiez la prise en charge de Docker, les périphériques requis, le mode de sécurité, le comportement des sauvegardes et la possibilité d'activer les fonctions avancées.

Envisagez OpenVZ pour une charge Linux simple et vérifiée

OpenVZ peut encore convenir pour un site web basique, une petite pile LAMP, un service DNS ou une charge Linux tout aussi classique, à condition que :

• L'hébergeur documente la version de la plateforme.
• Vos logiciels prennent en charge l'environnement noyau disponible.
• Vous n'avez besoin ni de Windows ni de personnalisation du noyau.
• Docker est soit inutile, soit explicitement pris en charge.
• L'hébergeur dispose d'un plan de sécurité et de migration crédible.
• Le prix ou le modèle d'exploitation vous donne une vraie raison de le choisir.

Ne le choisissez pas simplement parce qu'une vieille comparaison affirme qu'OpenVZ est toujours moins cher. Comparez l'offre actuelle, le support, la politique de ressources et les options de migration.

Si votre réponse est KVM, c'est la contrainte qui a tranché, pas une préférence. Le VPS KVM de Cloudzy démarre en 60 secondes sur AMD EPYC avec du NVMe pur, et chaque instance reçoit son propre noyau invité. Les modules noyau se chargent, les noyaux personnalisés démarrent, et les invités Linux comme Windows sont pris en charge. Docker est disponible sur la marketplace si vous préférez ne pas l'installer vous-même.

Foire aux questions

systemd-detect-virt