Comment vérifier un disque NVMe sur un VPS Linux

Vérifier un disque NVMe sous Linux en 4 étapes

Pour vérifier un disque NVMe sur un VPS Linux, exécutez 4 contrôles dans l’ordre : lsblk pour connaître le nom du périphérique, le flag rotational et le chemin du bus dans sysfs, nvme list pour confirmer la présence d’un véritable contrôleur NVMe, puis une courte exécution de fio pour obtenir la seule information qu’un hébergeur ne peut pas maquiller. Les 3 premiers contrôles prennent chacun une seconde. Le dernier permet de trancher, car sur la plupart des plateformes VPS, l’hyperviseur masque le disque physique au système invité.

NVMe (non-volatile memory express) est le protocole utilisé par le stockage flash sur les lignes PCIe (peripheral component interconnect express). Il a remplacé le chemin SATA et AHCI conçu pour les disques à plateaux. Il est rapide, car il supprime un goulot d’étranglement dans la mise en file entre le CPU et la mémoire flash. Dans une machine virtuelle, vous utilisez rarement ce protocole directement. Vous utilisez un disque virtuel assemblé par l’hôte. Le nom du périphérique dans le système invité décrit donc un pilote, et non le support présent dans le rack.

Étape 1 : que montre lsblk ?

lsblk lit la liste des périphériques blocs du kernel. L’option -d masque les partitions : vous obtenez donc une ligne par disque.

lsblk -d -o NAME,ROTA,SIZE,TYPE,TRAN,MODEL

Un VPS KVM renvoie généralement ceci :

NAME ROTA  SIZE TYPE TRAN   MODEL
vda     1   80G disk virtio

Trois schémas de nommage couvrent presque tous les serveurs Linux :

• nvme0n1 correspond à l’espace de noms 1 du contrôleur NVMe 0. Votre machine virtuelle utilise un périphérique NVMe, physique ou émulé.
• sda correspond à la couche SCSI. Les disques SATA et SAS physiques apparaissent ici, tout comme ceux utilisés par le pilote virtio-scsi.
• vda correspond à virtio-blk, le pilote de périphériques blocs paravirtualisés utilisé par défaut par la plupart des hôtes KVM.

La colonne TRAN (transport) affiche nvme pour un périphérique NVMe et sata pour un disque SATA que la machine virtuelle peut voir directement. Avec virtio-blk, les versions actuelles de util-linux affichent virtio, que lsblk déduit du nom de périphérique vd. Les versions plus anciennes laissent cette colonne vide. Dans les deux cas, la machine virtuelle n’a aucun transport physique à signaler. MODEL est vide pour la même raison. Une chaîne de modèle vide sur un VPS est normale et ne fournit aucune information sur le matériel.

Étape 2 : écarter un disque mécanique

DISK=$(lsblk -dno NAME,TYPE | awk '$2 == "disk" { print $1; exit }')
echo "checking $DISK"
cat "/sys/block/$DISK/queue/rotational"
readlink -f "/sys/block/$DISK"

Le fichier rotational indique 1 lorsque le noyau considère que le périphérique utilise des plateaux mécaniques, et 0 dans le cas contraire. Sur une machine physique, cette valeur provient du disque. Avec virtio-blk, elle ne provient de nulle part : la spécification virtio-blk ne comporte aucun bit de fonctionnalité pour le type de support ou la vitesse de rotation, et le pilote virtio-blk de Linux marque tous les disques comme rotatifs. Un vda renvoie donc normalement 1, même sur un hôte entièrement équipé de mémoire flash, sauf si quelqu’un l’a forcé à 0 avec une règle udev. Avec un périphérique sda virtio-scsi, la valeur correspond à celle que l’hôte a configurée. Dans un VPS, cet indicateur ne permet donc pas de confirmer ou d’exclure la présence d’un disque dur, et un 1 ne justifie pas à lui seul l’ouverture d’un ticket auprès du support. Le test fio ci-dessous permet de répondre à cette question.

readlink -f résout le lien symbolique sysfs et affiche le bus auquel le périphérique est rattaché :

/sys/devices/pci0000:00/0000:00:05.0/virtio2/block/vda

Le mot virtio présent dans ce chemin fournit la réponse pour cette étape. Un périphérique NVMe fournit un chemin contenant nvme, par exemple /sys/devices/pci0000:00/0000:01:00.0/nvme/nvme0/nvme0n1, tandis qu’un disque ATA directement connecté fournit un chemin contenant ata1. Il s’agit de la même information que celle affichée par lsblk, mais obtenue depuis le noyau plutôt que depuis une colonne formatée, ce qui est utile lorsque le champ TRAN est vide.

Étape 3 : interroger nvme-cli et le bus PCI

sudo apt update
sudo apt install -y nvme-cli pciutils
sudo nvme list || echo "nvme-cli found no NVMe device"
lspci | grep -i -e nvme -e 'non-volatile' || echo "no NVMe controller on this guest's PCI bus"

nvme list affiche une ligne par namespace, avec le numéro de série du contrôleur, la chaîne du modèle et la révision du firmware. Une table vide signifie qu’aucun périphérique NVMe n’est exposé à votre guest. lspci n’affichant aucune ligne correspondante indique la même chose sous un autre angle : le bus PCI virtuel visible par votre guest ne contient aucun contrôleur NVMe. Ces deux résultats vides sont normaux sur un VPS virtio. Aucun des deux ne prouve que l’hôte ne possède aucun disque NVMe.

Si un namespace apparaît, nvme-cli permet d’aller plus loin. sudo nvme id-ctrl /dev/nvme0 affiche l’identité du contrôleur, et sudo nvme smart-log /dev/nvme0n1 affiche la température, le nombre d’heures sous tension et le pourcentage de l’endurance nominale en écriture déjà utilisé. Exécutez ces commandes uniquement lorsque nvme list a effectivement listé un périphérique, car elles doivent toutes deux ouvrir un véritable nœud /dev/nvme*.

Pourquoi un hôte réellement équipé de NVMe affiche quand même /dev/vda

L’hyperviseur détermine le modèle de périphérique présenté à votre guest. Ce choix est indépendant du support de stockage sous-jacent. Trois configurations sont courantes.

• virtio-blk ou virtio-scsi au-dessus d’un fichier, d’un logical volume ou d’un dataset ZFS situé sur des disques NVMe. Vous voyez vda ou sda. Le stockage est en NVMe. Le guest n’a aucun moyen de le savoir.
• Un contrôleur NVMe émulé placé devant n’importe quel stockage. Vous voyez nvme0n1, même si les données sont écrites sur une baie SATA ou sur un volume réseau situé à deux baies de distance.
• Le PCIe passthrough, dans lequel l’hôte attribue un contrôleur physique à un seul guest. Vous voyez un véritable nvme0n1 avec une véritable chaîne de modèle. Cette configuration est rare sur les offres VPS partagées, car la carte est alors dédiée à un seul client.

Le nom du périphérique peut donc vous induire en erreur dans les deux sens. De plus, l’hôte peut placer un write-back cache, une couche RAID ou un volume réseau répliqué entre vos écritures et la mémoire flash. Chacun de ces éléments modifie les performances obtenues sans changer un seul nom dans /sys. C’est pourquoi le nom constitue un point de départ, pas une conclusion. Si vous êtes encore en train de choisir une offre, la différence entre le stockage NVMe et le stockage SSD SATA explique ce que chaque niveau justifie réellement de payer.

Le vrai test, c’est la latence : mesurez-la

fio (flexible I/O tester) effectue de vraies lectures sur un fichier réel et indique la durée de chaque opération. De petites lectures aléatoires constituent la charge adaptée ici, car elles exposent l’aller-retour vers le support et ne peuvent pas être servies par la lecture anticipée.

Commencez par créer le fichier de test et vérifiez que ce système de fichiers accepte les entrées-sorties sans mise en tampon. --direct=1 ouvre le fichier avec O_DIRECT, ce qui contourne le cache de pages. Sans cette option, vous mesurez votre propre mémoire vive et obtenez des valeurs qu’aucun disque ne peut produire.

sudo apt install -y fio
fio --name=prep --filename=/var/tmp/nvme-check.tmp --size=256M --bs=1M --rw=write --direct=1 --end_fsync=1 > /dev/null \
  && echo "unbuffered writes work here, the timing test is valid" \
  || echo "this filesystem refuses direct=1, so the timing test below will not run"

Si le message affiché indique un refus, le chemin choisi se trouve sur un système de fichiers qui ne prend pas en charge O_DIRECT. Les systèmes de fichiers overlay des conteneurs et certains systèmes de fichiers réseau se comportent ainsi. Choisissez un répertoire sur le système de fichiers racine du VPS, puis réessayez. Si le message indique une réussite, lancez la mesure :

fio --name=randread4k --filename=/var/tmp/nvme-check.tmp --bs=4k --rw=randread \
  --direct=1 --iodepth=1 --numjobs=1 --runtime=20 --time_based --group_reporting \
  || echo "fio stopped early, read its first line for the reason"
rm -f /var/tmp/nvme-check.tmp

La durée du test est volontairement limitée : un seul job, une profondeur de file d’attente de 1, vingt secondes et 256 MB de données. Le test ne remplira pas votre disque et ne vous fera pas signaler pour abus. Une profondeur de file d’attente de 1 est également le réglage approprié pour cette question, car les files d’attente profondes permettent à un périphérique lent de masquer ses performances derrière le parallélisme alors que la latence reste élevée.

Lecture de la sortie de fio

Deux lignes sont importantes. La ligne de synthèse ressemble à read: IOPS=9012, BW=35.2MiB/s, puis fio affiche un bloc clat. clat correspond à la latence d’achèvement : le délai entre la soumission d’une lecture par fio et la restitution des données par le kernel. Relevez la valeur avg, puis le percentile 99.00th dans la liste clat percentiles. La moyenne indique la classe de stockage. Le 99e percentile indique la lenteur des 1 % de lectures les plus lentes. C’est généralement là que la contention sur un hôte partagé apparaît en premier.

Fio affiche la latence en microsecondes lorsque les valeurs sont faibles et passe aux millisecondes lorsqu’elles ne le sont plus. Vérifiez l’unité indiquée sur la ligne avant toute comparaison.

Quels chiffres permettent de distinguer une classe NVMe d’une classe SATA

Les valeurs ci-dessous sont des valeurs publiées typiques pour des lectures aléatoires 4k sur une seule tâche, avec une profondeur de file de 1. Elles proviennent de la documentation des fabricants et de benchmarks réalisés par la communauté, à jour en août 2026. Il s’agit de fourchettes de comparaison, pas de mesures effectuées sur votre serveur.

[
  {
    "label": "Local NVMe",
    "avg_latency_us": 110
  },
  {
    "label": "Local SATA SSD",
    "avg_latency_us": 320
  },
  {
    "label": "Network block storage",
    "avg_latency_us": 900
  }
]

[
  {
    "label": "Local NVMe",
    "iops": "9,000"
  },
  {
    "label": "Local SATA SSD",
    "iops": "3,100"
  },
  {
    "label": "Network block storage",
    "iops": "1,100"
  }
]

Un volume NVMe local répond à une lecture aléatoire 4k en environ 110 microsecondes et atteint environ 9,000 IOPS avec une profondeur de file de 1. Un SSD SATA local se situe autour de 320 microsecondes et 3,100 IOPS. Le stockage bloc raccordé au réseau se situe autour de 900 microsecondes et 1,100 IOPS, car une lecture absente de tout cache côté hôte doit traverser le réseau avant d’atteindre la mémoire flash.

Avec une profondeur de file de 1, ces deux colonnes expriment presque deux fois le même fait : lorsqu’une seule lecture est en cours à la fois, le débit correspond environ à l’inverse de la latence, avec une légère baisse due à la surcharge de chaque requête. Si votre moyenne est plus proche de 110 que de 320 microsecondes, votre stockage appartient à la classe NVMe, quelle que soit l’appellation choisie pour le périphérique par lsblk. Si elle est plus proche de 900 microsecondes, un composant plus lent que la mémoire flash locale se trouve sur le chemin, ou l’hôte limite les IOPS de votre volume. Des hyperviseurs tels que QEMU peuvent appliquer cette limitation, quel que soit le stockage sous-jacent. Dans les deux cas, votre volume ne fournit pas une latence de classe NVMe, quelle que soit l’affirmation de la page de commande concernant les disques de l’hôte.

Lancez le test plusieurs fois avant de vous plaindre

Un seul test fournit un échantillon, pas un résultat. Un VPS partage ses disques, et un voisin très sollicité peut doubler votre latence pendant dix minutes avant de redevenir normal. Certaines plateformes accordent aussi des crédits de burst, ce qui rend les premières minutes d’un test particulièrement bonnes. Exécutez la même commande trois ou quatre fois à différentes heures de la journée et comparez le pire résultat, pas le meilleur. Un seul mauvais résultat peut être ponctuel. Un schéma récurrent indique un problème qui justifie un ticket auprès du support, lequel sera plus convaincant avec trois sorties fio horodatées en pièce jointe. Pour obtenir une vue d’ensemble incluant le CPU et le réseau, en plus du disque, un benchmark complet du VPS applique la même méthode aux autres sous-systèmes.

Que faire de la réponse

Si la latence se situe dans la plage du stockage NVMe, ne vous préoccupez plus du nom du périphérique et passez à la suite. vda n’est pas une régression. C’est le pilote de disque virtuel le plus rapide proposé par la plupart des hébergeurs, et c’est celui qu’il vous faut.

Si la latence se situe dans la plage du stockage réseau alors que l’offre est vendue comme du NVMe local, vous disposez d’un constat précis et reproductible : la commande fio exacte, la latence moyenne d’achèvement et les horaires auxquels vous avez effectué les tests. Cela justifie l’ouverture d’un ticket auprès du support, plutôt qu’une discussion sur un forum. Avant de l’envoyer, vérifiez que le disque n’est pas simplement plein ou fortement fragmenté, et qu’aucun processus sur la machine n’effectue d’importantes écritures pendant le test.

Effectuez cette vérification le jour où vous provisionnez le serveur, et non le jour où quelque chose semble lent. Vous aurez ainsi une référence à laquelle comparer les résultats ultérieurs. Cette vérification s’intègre naturellement dans les dix premières minutes sur un nouveau VPS, avec la configuration du firewall et des clés SSH. Si la distinction entre les différents niveaux de stockage reste floue, ce qu’un VPS SSD vous apporte réellement présente les notions sous-jacentes.

FAQ

Pourquoi lsblk affiche-t-il /dev/vda alors que mon hébergeur annonce du NVMe ?

Parce que vda désigne le pilote virtio-blk dans votre invité, et non le matériel de l’hôte. Un hyperviseur KVM présente un périphérique bloc paravirtualisé, adossé à un fichier, à un volume logique ou à un dataset. Ce stockage sous-jacent peut se trouver sur des disques NVMe sans que l’invité ne puisse le savoir. Le nom décrit la couche de virtualisation. Seule une mesure de latence décrit le support.

rotational 0 prouve-t-il que j’ai un disque NVMe ?

Non. /sys/block/<dev>/queue/rotational contenant 0 signifie que le noyau ne considère pas le périphérique comme doté de plateaux rotatifs. Dans un VPS, il s’agit toutefois d’un paramètre, et non d’une mesure. virtio-blk ne possède aucun bit de fonctionnalité indiquant le type de support. Le pilote Linux virtio-blk renvoie 1 pour chaque disque, sauf si un autre paramètre le remplace. La présence de 0 signifie donc généralement que quelqu’un l’a défini manuellement. Ce paramètre ne permet pas de distinguer un NVMe d’un SSD SATA, ni une mémoire flash locale d’un volume réseau. La présence de 1 dans un VPS ne prouve pas non plus qu’il s’agit d’un disque dur. Basez-vous donc sur la latence mesurée avec fio, et non sur ce paramètre.

Pourquoi nvme list n’affiche-t-il rien sur mon VPS ?

Parce qu’aucun contrôleur NVMe n’est présenté à votre invité. nvme list et lspci lisent tous deux ce que la machine virtuelle peut voir. Un disque virtio-blk ou virtio-scsi ne présente aucun contrôleur NVMe à énumérer. Un tableau vide est le résultat normal sur la plupart des offres VPS. Il ne prouve pas que l’hôte ne possède pas de disques NVMe. Installez nvme-cli avec sudo apt install -y nvme-cli et attendez-vous à obtenir un tableau vide, sauf si un contrôleur a été passé directement à la machine virtuelle.

Quel résultat fio correspond à un stockage de classe NVMe ?

Avec une profondeur de file de 1, des lectures aléatoires de 4k et --direct=1, une latence moyenne d’achèvement proche de 110 microsecondes correspond à un stockage de classe NVMe. Elle donne environ 9,000 IOPS. Une valeur proche de 320 microsecondes indique plutôt un SSD SATA. Une valeur proche de 900 microsecondes indique plutôt un stockage attaché au réseau, lorsque les lectures absentes du cache de l’hôte traversent un saut réseau, ou un volume limité par l’hôte. Il s’agit des fourchettes typiquement publiées pour août 2026. Comparez donc les ordres de grandeur plutôt que les valeurs exactes, et répétez le test à différentes heures avant de tirer une conclusion.