How to Check Say Your VPS Disk Na Real NVMe

Linux for NVMe disk verify na steps four

To verify NVMe disk for Linux VPS, run four checks one after another: lsblk for the device name, the rotational flag for sysfs to check whether na spinning media, nvme list to confirm real NVMe controller, and short fio run for the only number wey host no fit disguise. The first three dey take one second each. The last one go settle the matter, because for most VPS platforms, hypervisor dey hide the physical disk from guest.

NVMe (non-volatile memory express) na protocol wey flash storage dey use through PCIe (peripheral component interconnect express) lanes. E replace SATA and AHCI path wey dem design for spinning drives, and e fast because e remove queueing bottleneck between CPU and flash. Inside virtual machine, you hardly dey talk that protocol directly. You dey talk to virtual disk wey host assemble for you, so device name for your guest dey describe driver, no be the media wey dey rack.

Step 1: wetin lsblk dey show?

lsblk dey read kernel list of block devices. -d flag dey hide partitions, so you go see one line for each disk.

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

KVM VPS usually dey answer like this:

NAME ROTA  SIZE TYPE TRAN MODEL
vda     0   80G disk

Three naming patterns cover almost every Linux server:

• nvme0n1 na namespace 1 for NVMe controller 0. Your guest dey use NVMe device, whether na real device or emulated one.
• sda na SCSI layer. Real SATA and SAS disks dey show here, and virtio-scsi driver too.
• vda na virtio-blk, the paravirtual block driver wey most KVM hosts dey use by default.

The TRAN (transport) column dey show nvme for NVMe device and sata for SATA disk wey guest fit see directly. E usually blank under virtio-blk because guest no get any physical transport to report. MODEL dey blank for the same reason. Empty model string for VPS normal, and e no tell you anything about the hardware.

Step 2: rule out a spinning disk

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"

The rotational file dey hold 1 when kernel believe say the device get spinning platters, and 0 for every other device. For bare metal, na the drive dey provide the value. Under virtio-blk, na feature bit wey host set dey provide am. So, a 0 rule out plain hard drive, but e no prove anything beyond that. Read am anyway: if plan wey dem sell as solid state storage get 1, na direct contradiction. Na also the one screenshot wey support no fit argue with.

readlink -f dey resolve the sysfs symlink and print the bus wey device connect to:

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

The word virtio for that path na your answer for this step. NVMe device go give path wey contain nvme, such as /sys/devices/pci0000:00/0000:01:00.0/nvme/nvme0/nvme0n1. Directly attached ATA disk go give path wey contain ata1. Na the same information wey lsblk print, but e come from kernel instead of formatted column. This dey useful when the TRAN field empty.

Step 3: nvme-cli and the PCI bus ask

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 dey print one row for each namespace, with the controller serial number, model string and firmware revision. Empty table mean say no NVMe device dey exposed to your guest. lspci wey no print any matching line dey show the same thing from another side: the virtual PCI bus wey your guest fit see no carry any NVMe controller. Both empty results na the normal outcome for virtio VPS, and none of dem mean say the host no get NVMe drives.

If namespace show, nvme-cli go check further. sudo nvme id-ctrl /dev/nvme0 dey print the controller identity, while sudo nvme smart-log /dev/nvme0n1 dey print temperature, power-on hours and the percentage of rated write endurance wey dem don use. Run dem only when nvme list don list device, because both commands need real /dev/nvme* node to open.

Why host wey truly use NVMe still dey show /dev/vda

Hypervisor dey decide the device model wey your guest go see, and that choice no depend on the storage media underneath. Three arrangements dey common.

• virtio-blk or virtio-scsi over a file, logical volume, or ZFS dataset wey dey live for NVMe drives. You go see vda or sda. The storage na NVMe. Guest no get way to know that one.
• Emulated NVMe controller wey dey front any kind storage. You go see nvme0n1 even when the bytes dey land for SATA array or network volume wey dey two racks away.
• PCIe passthrough, where host dey hand physical controller give one guest. You go see real nvme0n1 with real model string. This one rare for shared VPS plans, because the card go then belong to that one customer alone.

So device name fit mislead you for both directions. Worse, host fit put write-back cache, RAID layer, or replicated network volume between your writes and the flash. Each one fit change the performance wey you get without changing any name for /sys. Na why the name na where you start, no be where you stop. If you still dey choose plan, the difference between NVMe and SATA SSD storage explain wetin each tier really worth paying for.

The real test na latency, so measure am

fio (flexible I/O tester) dey make real reads against real file and report how long each one take. Small random reads na the correct workload here, because dem show the round trip to the media and read-ahead no fit serve dem.

First create the test file and confirm say this filesystem accept unbuffered I/O. --direct=1 dey open the file with O_DIRECT, wey bypass page cache. If you no use am, you go measure your RAM and get numbers wey no disk fit produce.

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"

If na refusal e print, the path wey you choose dey for filesystem without O_DIRECT support. Container overlay filesystems and some network filesystems dey behave like this. Choose directory for the VPS root filesystem and try again. If na success e print, run the measurement:

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

The run get limits intentionally: one job, queue depth 1, twenty seconds, and 256 MB data. E no go fill your disk, and e no go make dem flag you for abuse. Queue depth 1 na also the honest setting for this question, because deep queues fit make slow device hide behind parallelism while latency still high.

Understand fio output

Two lines matter. The summary line dey look like read: IOPS=9012, BW=35.2MiB/s, and under am fio dey print one clat block. clat na completion latency: na the time between when fio submit a read and when kernel hand the data back. Read the avg value, then read the 99.00th percentile for the clat percentiles list. The average dey tell you the storage class. The 99th percentile dey tell you how often another user for the same host make you wait.

Fio dey print latency for microseconds when the values small, and e go switch to milliseconds when dem no be small. Check the unit for the line before you compare anything.

Wetin numbers dey separate NVMe class from SATA class

The figures below na typical published values for single-job 4k random reads at queue depth 1, collected from vendor documentation and community benchmarks as of August 2026. Dem be comparison ranges, no be measurements from your server.

[
  {
    "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"
  }
]

A local NVMe volume dey answer one 4k random read for about 110 microseconds and reach around 9,000 IOPS at queue depth 1. A local SATA SSD dey around 320 microseconds and 3,100 IOPS. Network attached block storage dey around 900 microseconds and 1,100 IOPS, because every single read must pass through one network hop before e touch any flash.

For queue depth 1, those two columns na the same fact wey dem state two times: when na one read at a time, throughput simply be one divided by latency. If your average dey closer to 110 than to 320 microseconds, you dey use NVMe class storage, no matter wetin lsblk decide to call the device. If e dey closer to 900 microseconds, something slower than local flash dey inside the path, and the word NVMe for the order page dey describe the host drives, no be your volume.

Run am more than once before you complain

One run na sample, e no be result. VPS dey share disk, so busy neighbour fit double your latency for ten minutes, then e disappear. Some platforms still dey give burst credits wey make the first minutes of any test look excellent. Run the same command three or four times for different hours of the day, then compare the worst result, no be the best one. One bad run na just temporary condition. Pattern na fault wey deserve support ticket, and ticket go get better response if you attach three fio outputs with timestamps. For wider picture wey cover CPU and network together with disk, full VPS benchmark run dey use the same method for the other subsystems.

Wetín to do with the answer

If the latency dey for NVMe band, stop to worry about the device name and move on. vda no be downgrade. Na the fastest virtual disk driver wey most hosts dey offer, and na wetin you want.

If the latency dey for network storage band for plan wey dem sell as local NVMe, you get specific, reproducible claim: the exact fio command, the average completion latency, and the times wey you run am. This one na support ticket, no be forum argument. Before you send am, confirm say the disk no just full or heavily fragmented, and confirm say nothing for the box dey write heavily while you dey test.

Run this check the day wey you provision am, no be the day something begin feel slow, so you get baseline wey you fit compare with later. E fit enter naturally for the first ten minutes for a new VPS, together with setting up the firewall and the SSH keys. If the difference between storage tiers still dey unclear, wetin SSD VPS actually dey give you explain the foundation behind this one.

FAQ

Why lsblk dey show /dev/vda when my host advertise NVMe?

Because vda na the virtio-blk driver name for your guest, e no be the hardware name for the host. KVM hypervisor dey present paravirtual block device wey file, logical volume, or dataset dey back, and that backing store fit dey on NVMe drives without the guest ever knowing. The name dey describe the virtualisation layer. Na only latency measurement fit describe the storage media.

Rotational 0 prove say I get NVMe disk?

No. /sys/block/<dev>/queue/rotational wey hold 0 mean say kernel no believe the device get spinning platters, and under virtio, host dey set that value through feature bit. E rule out ordinary hard drive. E no fit tell NVMe apart from SATA SSD, and e no fit tell local flash apart from network volume. A 1 still dey worth acting on, because e contradict any plan wey dem sell as solid state storage.

Why nvme list empty for my VPS?

Because no NVMe controller dey exposed to your guest. nvme list and lspci both read wetin virtual machine fit see, and virtio-blk or virtio-scsi disk no present any NVMe controller to enumerate. Empty table na the normal result for most VPS plans, and e no prove say host no get NVMe drives. Install nvme-cli with sudo apt install -y nvme-cli and expect empty table unless dem pass controller through to the guest.

Which fio result count as NVMe class storage?

For queue depth 1 with 4k random reads and --direct=1, average completion latency near 110 microseconds na NVMe class, and roughly 9,000 IOPS follow from am. Around 320 microseconds point to SATA SSD, while around 900 microseconds point to network attached storage, where every read cross network hop. These na typical published bands for August 2026, so compare orders of magnitude instead of exact figures, and repeat the run for different hours before you draw conclusion.