Serveur dedie virtuel : VDS vs VPS vs serveur dedie

Ce qu'est réellement un serveur dédié virtuel

Un serveur dédié virtuel (VDS) est une machine virtuelle découpée dans un hôte physique par un hyperviseur (le plus souvent KVM sous Linux, parfois Xen, VMware ESXi ou Hyper-V), avec une propriété déterminante : les ressources facturées sont réservées. Deux cœurs, cela signifie deux threads de l'hôte mis de côté pour cette VM ; 8 Go de RAM, ce sont 8 Go que l'hôte ne prête jamais à un autre locataire. À l'intérieur de la machine, vous disposez de votre propre noyau, de votre propre image disque, des droits root ou Administrateur complets, et de n'importe quel système d'exploitation que l'hyperviseur sait démarrer : un petit serveur dédié du point de vue de l'invité, un locataire parmi d'autres qui ne se disputent jamais la même allocation du point de vue de l'hôte.

Le terme existe parce que « VPS » est devenu trop large. Un VPS peut aussi bien être un conteneur OpenVZ à RAM burstable qu'une machine KVM sur un hôte qui vend le même cœur physique à six clients. « VDS » a été adopté par les hébergeurs qui voulaient dire « celui-ci n'est pas survendu ». Aucune norme ne se cache derrière ce label : sur le marché de l'hébergement russophone, VDS et VPS sont interchangeables, et certains hébergeurs ailleurs renomment une gamme de VPS ordinaire parce que VDS sonne plus proche de dédié. Le mot indique l'intention ; les commandes ci-dessous disent la vérité.

VDS, VPS et serveur dédié

Les produits diffèrent sur deux axes : la manière dont la machine est isolée (conteneur, machine virtuelle ou matériel physique) et le fait que les ressources soient réservées ou partagées. Le VDS se situe entre un VPS partagé et un serveur dédié sur ces deux plans.

La colonne des prix donne une fourchette indicative 2026 pour les offres d'entrée de gamme, pas un benchmark. Une VM réservée de quatre cœurs et 8 Go ne peut pas être vendue $3 par mois ; quand un « VDS » est facturé comme un conteneur, c'en est généralement un.

Ressources réservées ou partagées : où se joue la différence

CPU. Sur KVM, chaque vCPU est un thread de l'hôte que l'ordonnanceur Linux traite comme n'importe quel autre processus. Un hôte de 32 threads matériels peut être vendu sous forme de 32 vCPU (1:1, réservés) ou de 128 vCPU (4:1, partagés). Rien à l'intérieur de l'invité n'affiche ce ratio ; il ne devient visible que sous forme de steal time et de pics de latence lorsque les voisins sont actifs.

RAM. Les hôtes KVM surallouent la mémoire de deux façons : le pilote virtio balloon permet à l'hôte de récupérer les pages qu'un invité n'utilise pas, et KSM (kernel samepage merging) déduplique les pages identiques entre VM. Sur une offre réservée, la mémoire est engagée au démarrage de la VM et le ballon n'est jamais gonflé. Voir virtio_balloon dans lsmod prouve la capacité, pas l'usage : le pilote est présent dans presque toutes les images cloud.

Stockage. La réservation s'étend rarement au disque ; presque tous les hébergeurs partagent le backend de stockage et plafonnent au mieux les IOPS par VM. Ce qui change les performances, c'est le palier sous-jacent : un disque NVMe délivre bien plus d'IOPS et une latence bien plus basse qu'un SSD SATA, et aucune réservation de CPU ne compense un disque lent sous une base de données.

Réseau. Le lien montant est partagé partout, sauf sur un serveur dédié disposant de son propre port ; une bande passante « illimitée » signifie illimitée dans le cadre d'une politique de fair-use, pas 1 Gbit/s garanti pour vous seul.

KVM face à la virtualisation par conteneurs (OpenVZ, LXC)

Cette distinction détermine si un « VDS » peut être dédié tout court. KVM, Xen et ESXi relèvent de la virtualisation matérielle : VT-x ou AMD-V permet à chaque invité d'exécuter son propre noyau sur du matériel virtuel. OpenVZ, Virtuozzo, LXC et Docker relèvent de la virtualisation au niveau du système d'exploitation : chaque locataire est un ensemble de processus tournant sur le noyau de l'hôte, séparés par des namespaces et limités par des cgroups. Proxmox les appelle « CT », et de nombreux hébergeurs low-cost les vendent comme des VPS. Les conséquences :

• uname -r renvoie le noyau de l'hôte, que vous n'avez pas choisi et que vous ne pouvez pas mettre à jour. Historiquement, les hôtes OpenVZ faisaient tourner des séries de noyaux très anciennes. Si vous ne savez pas ce que fait réellement tourner une machine, les commandes pour connaître la version de l'OS et du noyau sous Linux, Windows et macOS prennent quelques secondes.
• Vous ne pouvez pas charger de modules noyau : WireGuard, ZFS et tout ce qui est livré sous forme de .ko dépendent de l'hôte.
• La virtualisation imbriquée est impossible, et Docker ou systemd à l'intérieur du conteneur ne fonctionnent que si l'hôte l'autorise.

Un invité KVM n'a aucune de ces contraintes : il démarre depuis une ISO, exécute n'importe quel noyau et peut exposer VT-x à ses propres invités si l'hôte autorise la virtualisation imbriquée. Un véritable VDS est donc toujours une VM complète.

Voisins bruyants et steal time

Un voisin bruyant est un autre locataire du même hôte dont l'usage du CPU, du disque ou du réseau empiète sur le vôtre. Sur un hôte KVM surchargé, l'ordonnanceur place votre vCPU dans la file derrière le sien, et le temps pendant lequel votre vCPU était prêt mais en attente est remonté à l'invité sous forme de steal time. Linux l'expose comme huitième valeur de la ligne cpu de /proc/stat, comme colonne st de vmstat et top, et comme %steal dans mpstat et sar.

Une VM réservée doit afficher un steal nul ou quasi nul, même quand ses voisins tournent à plein régime. Quelques pour cent lors des pointes sont normaux sur les offres partagées ; un steal durablement à deux chiffres signifie que l'hôte est survendu, et les seuls remèdes sont un autre nœud ou une véritable offre 1:1. L'hébergeur ne peut pas masquer cette métrique : l'hyperviseur l'écrit dans la comptabilité de l'invité lui-même. Les conteneurs se comportent différemment : dans LXC ou OpenVZ, la colonne st reste généralement à zéro pendant que vous êtes bridé ; là où le runtime l'expose, cat /sys/fs/cgroup/cpu.stat (cgroup v2) montre à la place nr_throttled et throttled_usec qui grimpent.

Quand « VDS » n'est que du marketing

Le label n'étant pas encadré, lisez la page de l'offre à la recherche des signaux qui décrivent l'architecture :

• « vCPU » sans ratio. Une offre réservée annonce des « cœurs dédiés » ou « 1 vCPU = 1 thread ». Si le support ne sait pas indiquer le ratio vCPU/thread, considérez que c'est partagé.
• « RAM garantie » à côté de « RAM en burst ». C'est le vocabulaire d'OpenVZ pour un conteneur à limite souple, pas pour une VM à mémoire engagée.
• Pas d'ISO personnalisée, pas de choix du noyau, pas de réinstallation libre. Ces restrictions viennent du partage du noyau de l'hôte.
• « Semi-dédié » ou « hybride » dans le nom. Des mots honnêtes pour une offre partagée à faible contention : très bien, mais ce n'est pas un VDS.

Beaucoup d'hébergeurs emploient le terme VDS honnêtement ; les vérifications ci-dessous tranchent la question en moins d'une minute.

Comment vérifier ce que vous obtenez vraiment

1. Identifier la couche de virtualisation

systemd-detect-virt
# typical answers: kvm, qemu, xen, vmware, microsoft, openvz, lxc, docker, none
systemd-detect-virt --container   # container type, or none

virt-what (exécuté en root) donne la même réponse sur les distributions sans systemd. lscpu | grep -i hypervisor doit afficher Hypervisor vendor: KVM sur un invité KVM ; dans un conteneur, lscpu montre le nombre total de cœurs de l'hôte au lieu de votre allocation, et la présence de /proc/vz ou de /proc/user_beancounters est un marqueur OpenVZ sans ambiguïté.

2. Lire le modèle et le nombre de CPU

nproc
grep -m1 'model name' /proc/cpuinfo
lscpu | grep -E '^(Model name|Socket|Core|Thread|CPU\(s\))'

nproc doit correspondre à ce que vous avez acheté. Un nom de modèle QEMU Virtual CPU ou Common KVM processor signifie que l'hôte masque le vrai CPU derrière un modèle générique, en cachant les jeux d'instructions récents comme AVX ; un modèle réel tel que AMD EPYC 7443P indique un passthrough de l'hôte. Aucun des deux ne prouve la réservation, mais un CPU masqué suggère un hôte optimisé pour la densité.

3. Mesurer le steal time en charge

vmstat 1 5          # last column: st
head -1 /proc/stat  # cpu user nice system idle iowait irq softirq steal guest guest_nice
stress-ng --cpu $(nproc) --timeout 60s   # package stress-ng, then watch vmstat

Mesurez à une heure de pointe. Si st reste proche de zéro alors que tous les vCPU sont saturés, les cœurs sont effectivement les vôtres ; répétez l'opération sur quelques jours, la contention dépendant de qui partage le nœud avec vous.

4. Vérifier la virtualisation imbriquée

grep -cE 'vmx|svm' /proc/cpuinfo   # more than 0: the virtualisation flag is exposed
ls -l /dev/kvm                     # appears once kvm_intel or kvm_amd is loaded
kvm-ok                             # Ubuntu: package cpu-checker

Si le flag est absent, l'hôte masque le modèle de CPU ou a désactivé la virtualisation imbriquée, et rien de ce qui exige un hyperviseur ne tournera dans l'invité. Un conteneur ne l'expose jamais.

5. Regarder le périphérique disque

lsblk -d -o NAME,SIZE,ROTA,MODEL
cat /sys/block/vda/queue/rotational   # 0 = non-rotational

vda est un périphérique bloc virtio, la configuration KVM habituelle ; sda avec un modèle QEMU HARDDISK correspond à du SATA émulé, toujours dans une VM. Dans un conteneur, le système de fichiers racine est souvent un montage ploop ou simfs. Sur les invités Windows, systeminfo | findstr /i hyper-v signale qu'un hyperviseur a été détecté.

Paliers tarifaires et cas d'usage

• VPS conteneur ($2-6) : sites statiques, petits bots, point de sortie VPN, bref tout ce où le noyau importe peu et où des ralentissements occasionnels sont acceptables.
• VPS KVM partagé ($4-12) : machines de développement et de préproduction, applications à faible trafic qui ont besoin de leur propre noyau et tolèrent des pointes de steal.
• VDS à ressources KVM réservées ($8-40) : bots de trading, serveurs de jeu, bases de données, runners CI, automatisation 24/7 et tout ce qui est sensible à la latence et tourne à haut niveau de CPU pendant des heures.
• Serveur dédié ($60-300+) : 100 % de CPU en continu sur de nombreux cœurs, grande quantité de RAM, GPU, votre propre hyperviseur, ou des règles qui interdisent le matériel partagé. Un serveur dédié bare-metal avec accès IPMI est l'étape supérieure quand un VDS ne suffit plus.

Si le palier réservé correspond à votre charge de travail, c'est exactement ce que vend rdp.monster : un VPS KVM avec CPU et RAM réservés, du stockage NVMe, un accès root ou administrateur complet, une bande passante illimitée (fair-use), sans KYC, avec les cryptomonnaies acceptées au même titre que les cartes et PayPal, à partir de $8.99/mois. La machine est livrée environ 10 secondes après confirmation du paiement, ce qui vous permet d'exécuter vous-même systemd-detect-virt et vmstat 1 avant de faire confiance au label (les mêmes vérifications que cet article recommande pour n'importe quel hébergeur).

Foire aux questions

Un VDS est-il la même chose qu'un VPS ?

Techniquement, les deux sont des serveurs virtuels ; VDS est censé signaler des ressources réservées, sans surallocation.

Les deux sont des serveurs virtuels sur du matériel partagé. La différence est une promesse, pas une technologie : un VDS est censé tourner comme une machine virtuelle complète (typiquement KVM) avec des cœurs CPU et de la RAM qui vous sont réservés, tandis qu'un VPS peut partager ces ressources avec d'autres locataires, voire être un conteneur sur le noyau de l'hôte. Comme aucune norme n'encadre le terme, certains hébergeurs emploient VDS et VPS indifféremment. Vérifiez avec systemd-detect-virt, nproc et le steal time plutôt que de vous fier au nom.

Comment savoir si mon VPS est en KVM ou en OpenVZ ?

Lancez systemd-detect-virt ; il affiche kvm, openvz, lxc ou none en une ligne.

Lancez systemd-detect-virt : il affiche kvm, qemu, openvz, lxc ou none. Sans systemd, installez et exécutez virt-what en root. Deux autres indices : lscpu | grep -i hypervisor affiche Hypervisor vendor: KVM sur un invité KVM, et la présence de /proc/vz ou de /proc/user_beancounters signifie OpenVZ. Dans un conteneur, nproc et uname -r reflètent eux aussi l'hôte plutôt que votre offre.

Quel steal time CPU est acceptable sur un serveur virtuel ?

Proche de zéro sur les offres réservées ; quelques pour cent en pointe restent tolérables, un taux durablement à deux chiffres trahit un hôte survendu.

Sur un VDS à cœurs réservés, la colonne st de vmstat 1 doit rester à 0 ou tout près, même à pleine charge. Sur les offres partagées, des valeurs occasionnelles à un chiffre pendant les pointes sont normales. Des valeurs durables de dix pour cent ou plus signifient que l'hôte est surchargé et que vos vCPU attendent derrière d'autres locataires. Aucun correctif n'existe depuis l'intérieur de l'invité : demandez à l'hébergeur de vous migrer vers un nœud plus calme, ou passez à une offre au ratio vCPU/thread de 1:1.

Puis-je faire tourner Docker ou une VM imbriquée sur un serveur dédié virtuel ?

Docker oui sur tout invité KVM ; les VM imbriquées seulement si l'hôte expose le flag CPU vmx ou svm.

Sur un VDS basé sur KVM, Docker fonctionne comme sur n'importe quelle machine Linux, puisque vous exécutez votre propre noyau. La virtualisation imbriquée (KVM, VirtualBox, Hyper-V dans l'invité) exige que l'hôte transmette l'extension de virtualisation du CPU : vérifiez avec grep -cE 'vmx|svm' /proc/cpuinfo, et confirmez que /dev/kvm apparaît après le chargement de kvm_intel ou kvm_amd. Sur des conteneurs OpenVZ ou LXC, les VM imbriquées sont impossibles et Docker dépend entièrement de ce que l'hôte autorise.