Come verificare se il disco VPS è davvero NVMe

Verificare un disco NVMe su Linux in quattro passaggi

Per verificare un disco NVMe su un VPS Linux, esegui quattro controlli in sequenza: lsblk per il nome del dispositivo, il flag rotational e il percorso del bus in sysfs, nvme list per verificare la presenza di un controller NVMe reale e una breve esecuzione di fio per ottenere l'unico dato che un host non può falsificare. I primi tre controlli richiedono circa un secondo ciascuno. L'ultimo risolve il dubbio, perché nella maggior parte delle piattaforme VPS l'hypervisor nasconde al guest il disco fisico.

NVMe (non-volatile memory express) è il protocollo utilizzato dallo storage flash sulle linee PCIe (peripheral component interconnect express). Ha sostituito il percorso SATA e AHCI, progettato per i dischi rotanti, ed è veloce perché elimina un collo di bottiglia nell'accodamento tra CPU e memoria flash. All'interno di una macchina virtuale, raramente si comunica direttamente con questo protocollo. Si accede invece a un disco virtuale assemblato dall'host, quindi il nome del dispositivo nel guest identifica un driver, non il supporto installato nel rack.

Passaggio 1: cosa mostra lsblk?

lsblk legge l'elenco dei dispositivi a blocchi del kernel. Il flag -d nasconde le partizioni, quindi viene visualizzata una riga per ogni disco.

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

Un VPS KVM normalmente restituisce un output simile:

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

Tre schemi di denominazione coprono quasi tutti i server Linux:

• nvme0n1 è lo spazio dei nomi 1 sul controller NVMe 0. Il guest utilizza un dispositivo NVMe, fisico o emulato.
• sda è il livello SCSI. I dischi SATA e SAS fisici vengono visualizzati qui, così come quelli gestiti dal driver virtio-scsi.
• vda è virtio-blk, il driver a blocchi paravirtualizzato utilizzato per impostazione predefinita dalla maggior parte degli host KVM.

La colonna TRAN (trasporto) mostra nvme per un dispositivo NVMe e sata per un disco SATA direttamente visibile al guest. Con virtio-blk, le versioni correnti di util-linux visualizzano virtio, che lsblk ricava dal nome del dispositivo vd, mentre le versioni precedenti lasciano il campo vuoto. In entrambi i casi il guest non dispone di un trasporto fisico da indicare. MODEL è vuoto per lo stesso motivo. Una stringa del modello vuota su un VPS è normale e non fornisce informazioni sull'hardware.

Passaggio 2: escludere un disco magnetico

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"

Il file rotational contiene 1 quando il kernel considera il dispositivo dotato di piatti magnetici rotanti e 0 negli altri casi. Su un server fisico, il valore proviene dall'unità. Con virtio-blk non proviene da alcuna fonte: la specifica virtio-blk non definisce alcun feature bit per il tipo di supporto o la velocità di rotazione e il driver Linux virtio-blk contrassegna ogni disco come rotazionale. Di conseguenza, un vda normalmente restituisce 1 anche su un host interamente basato su memoria flash, a meno che qualcuno non lo abbia impostato su 0 tramite una regola udev. Su un dispositivo sda virtio-scsi, il valore corrisponde a quello configurato dall'host. Pertanto, all'interno di una VPS questo flag non consente di confermare né di escludere la presenza di un disco rigido e un 1, da solo, non giustifica l'apertura di un ticket all'assistenza. Il test fio seguente fornisce la risposta.

readlink -f risolve il symlink sysfs e stampa il bus a cui è collegato il dispositivo:

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

La parola virtio presente nel percorso è la risposta per questo passaggio. Un dispositivo NVMe restituisce un percorso contenente nvme, ad esempio /sys/devices/pci0000:00/0000:01:00.0/nvme/nvme0/nvme0n1, mentre un disco ATA collegato direttamente restituisce un percorso contenente ata1. Si tratta dello stesso dato stampato da lsblk, ricavato dal kernel anziché da una colonna formattata. Questo è utile quando il campo TRAN è vuoto.

Passaggio 3: interrogare nvme-cli e il 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 stampa una riga per ogni namespace, con il numero di serie del controller, la stringa del modello e la revisione del firmware. Una tabella vuota indica che al guest non è esposto alcun dispositivo NVMe. Se lspci non stampa alcuna riga corrispondente, il risultato conferma la stessa condizione dal lato opposto: il bus PCI virtuale visibile al guest non contiene alcun controller NVMe. Entrambi i risultati vuoti sono normali su una VPS virtio e non dimostrano che l'host non disponga di unità NVMe.

Se compare un namespace, nvme-cli può fornire ulteriori informazioni. sudo nvme id-ctrl /dev/nvme0 stampa l'identità del controller, mentre sudo nvme smart-log /dev/nvme0n1 stampa la temperatura, le ore di accensione e la percentuale dell'endurance di scrittura nominale già utilizzata. Esegui questi comandi solo se nvme list ha effettivamente elencato un dispositivo, perché entrambi devono aprire un nodo /dev/nvme* reale.

Perché un host realmente basato su NVMe mostra comunque /dev/vda

L’hypervisor decide quale modello di dispositivo vede il guest, indipendentemente dal supporto sottostante. Sono comuni tre configurazioni.

• virtio-blk o virtio-scsi sopra un file, un volume logico o un dataset ZFS che risiede su unità NVMe. Vedi vda o sda. Lo storage è NVMe. Il guest non può rilevarlo.
• Un controller NVMe emulato davanti a qualsiasi tipo di storage. Vedi nvme0n1 anche quando i dati vengono scritti su un array SATA o su un volume di rete a due rack di distanza.
• PCIe passthrough, con cui l’host assegna un controller fisico a un solo guest. Vedi un vero nvme0n1 con una stringa del modello reale. Questa configurazione è rara nei piani VPS condivisi, perché la scheda viene dedicata a un solo cliente.

Il nome del dispositivo può quindi trarre in errore in entrambe le direzioni. Inoltre, l’host può inserire una cache write-back, un livello RAID o un volume di rete replicato tra le operazioni di scrittura e la memoria flash. Ognuno di questi livelli modifica le prestazioni ottenute senza cambiare un solo nome in /sys. Per questo il nome è il punto di partenza, non quello di arrivo. Se stai ancora scegliendo un piano, la differenza tra storage NVMe e SSD SATA spiega per quale motivo vale realmente la pena pagare ciascun livello.

La verifica corretta è la latenza, quindi misurala

fio (flexible I/O tester) esegue letture reali su un file reale e indica quanto tempo ha richiesto ciascuna operazione. Le piccole letture casuali sono il carico corretto in questo caso, perché evidenziano il tempo di andata e ritorno verso il supporto e non possono essere soddisfatte dal read-ahead.

Per prima cosa crea il file di test e verifica che questo filesystem accetti l’I/O non bufferizzato. --direct=1 apre il file con O_DIRECT, bypassando la page cache. Senza questa opzione misuri la RAM del sistema e ottieni valori che nessun disco può produrre.

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"

Se il comando ha stampato il rifiuto, il percorso scelto si trova su un filesystem che non supporta O_DIRECT. I filesystem overlay dei container e alcuni filesystem di rete si comportano in questo modo. Scegli una directory sul filesystem root del VPS e riprova. Se ha stampato il messaggio di esito positivo, esegui la misurazione:

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

L'esecuzione è limitata intenzionalmente: un job, profondità della coda pari a 1, venti secondi e 256 MB di dati. Non riempirà il disco e non farà segnalare il sistema per abuso. La profondità della coda pari a 1 è inoltre l'impostazione corretta per questa verifica, perché le code profonde permettono a un dispositivo lento di nascondere la propria latenza usando operazioni parallele, mentre la latenza resta elevata.

Lettura dell’output di fio

Sono importanti due righe. La riga di riepilogo ha un formato simile a read: IOPS=9012, BW=35.2MiB/s e subito sotto fio stampa un blocco clat. clat è la latenza di completamento: il tempo che intercorre tra l’invio di una richiesta di lettura da parte di fio e la restituzione dei dati da parte del kernel. Leggere il valore avg, quindi il percentile 99.00th nell’elenco clat percentiles. La media indica la classe dello storage. Il 99° percentile indica la lentezza dell’1% delle letture più lente. È in questo intervallo che la contesa su un host condiviso compare di norma per prima.

Fio esprime la latenza in microsecondi quando i valori sono ridotti e passa ai millisecondi per valori più elevati. Controllare l’unità nella riga precedente prima di confrontare i valori.

Quali numeri distinguono la classe NVMe dalla classe SATA

I valori riportati di seguito sono valori tipici pubblicati per letture casuali 4k con un singolo job e queue depth 1, raccolti dalla documentazione dei vendor e da benchmark della community ad agosto 2026. Sono intervalli di confronto, non misurazioni eseguite sul tuo 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"
  }
]

Un volume NVMe locale completa una lettura casuale 4k in circa 110 microsecondi e raggiunge circa 9,000 IOPS con queue depth 1. Un SSD SATA locale si colloca intorno a 320 microsecondi e 3,100 IOPS. Lo storage a blocchi collegato tramite rete si colloca intorno a 900 microsecondi e 1,100 IOPS, perché una lettura che non trova dati nella cache lato host deve attraversare la rete prima di raggiungere la memoria flash.

Con queue depth 1, le due colonne esprimono quasi lo stesso dato: con una sola lettura in corso alla volta, il throughput è approssimativamente uguale a uno diviso per la latenza, e diventa leggermente inferiore quando si considera l'overhead di ogni richiesta. Se la tua media è più vicina a 110 che a 320 microsecondi, stai usando storage di classe NVMe, indipendentemente dal nome con cui lsblk ha classificato il dispositivo. Se è più vicina a 900 microsecondi, nel percorso è presente un componente più lento della memoria flash locale oppure l'host sta limitando gli IOPS del volume; possono farlo hypervisor come QEMU, indipendentemente dallo storage sottostante. In entrambi i casi, il tuo volume non offre una latenza di classe NVMe, qualunque cosa indichi la pagina dell'ordine sui drive dell'host.

Esegui il test più volte prima di segnalare un problema

Un'esecuzione è un campione, non un risultato. Un VPS condivide i dischi, quindi un vicino che utilizza intensamente le risorse può raddoppiare la latenza per dieci minuti e poi smettere. Alcune piattaforme concedono anche crediti di burst, che fanno apparire eccellenti i primi minuti di qualsiasi test. Esegui lo stesso comando tre o quattro volte in ore diverse della giornata e confronta il risultato peggiore, non quello migliore. Un singolo risultato negativo può dipendere da una condizione temporanea. Un andamento ricorrente indica un problema per cui vale la pena aprire un ticket all'assistenza, che sarà più efficace se alleghi tre output di fio con relativo timestamp. Per una valutazione più ampia, che includa CPU e rete oltre al disco, un test completo delle prestazioni del VPS applica lo stesso metodo agli altri sottosistemi.

Cosa fare con il risultato

Se la latenza rientra nell'intervallo tipico degli NVMe, non concentrarti più sul nome del dispositivo e prosegui. vda non rappresenta un declassamento. È il driver per dischi virtuali più veloce offerto dalla maggior parte degli host ed è quello che vuoi utilizzare.

Se la latenza rientra nell'intervallo tipico dello storage di rete su un piano venduto come NVMe locale, hai una segnalazione specifica e riproducibile: il comando fio esatto, la latenza media di completamento e gli orari in cui hai eseguito il test. Questo è un ticket di supporto, non una discussione da forum. Prima di inviarlo, verifica che il disco non sia semplicemente pieno o fortemente frammentato e accertati che durante il test nessun processo sul server stia eseguendo un'intensa attività di scrittura.

Esegui questo controllo il giorno in cui esegui il provisioning, non quando qualcosa sembra lento, così in seguito avrai una baseline con cui confrontare i risultati. Si inserisce naturalmente nei primi dieci minuti su un nuovo VPS, insieme alla configurazione del firewall e delle chiavi SSH. Se la distinzione tra i diversi livelli di storage non è ancora chiara, cosa offre realmente un VPS con SSD illustra i concetti alla base di questo test.

FAQ

Perché lsblk mostra /dev/vda quando il mio host dichiara NVMe?

Perché vda identifica il driver virtio-blk nel guest, non l'hardware dell'host. Un hypervisor KVM presenta un dispositivo a blocchi paravirtualizzato supportato da un file, un volume logico o un dataset. Questo storage di supporto può trovarsi su unità NVMe senza che il guest possa rilevarlo. Il nome descrive il livello di virtualizzazione. Solo una misurazione della latenza descrive il supporto.

Il valore rotational 0 dimostra che ho un disco NVMe?

No. /sys/block/<dev>/queue/rotational con valore 0 indica che il kernel non considera il dispositivo dotato di piatti rotanti, ma in una VPS è un'impostazione, non una misurazione. virtio-blk non dispone di un bit di funzionalità per indicare il tipo di supporto. Il driver Linux virtio-blk segnala 1 per ogni disco, salvo override. Pertanto, un valore 0 indica di solito che qualcuno lo ha impostato manualmente. Non consente di distinguere NVMe da un SSD SATA e non consente di distinguere la memoria flash locale da un volume di rete. Un valore 1 in una VPS non dimostra nemmeno la presenza di un disco rigido. Basati quindi sulla latenza misurata con fio, non su questo flag.

Perché nvme list non restituisce risultati nella mia VPS?

Perché nel guest non è esposto alcun controller NVMe. nvme list e lspci leggono entrambi ciò che la macchina virtuale può vedere. Un disco virtio-blk o virtio-scsi non presenta alcun controller NVMe da enumerare. Una tabella vuota è il risultato normale nella maggior parte dei piani VPS e non dimostra che l'host sia privo di unità NVMe. Installa nvme-cli con sudo apt install -y nvme-cli e attenditi una tabella vuota, salvo che sia stato esposto un controller tramite passthrough.

Quale risultato di fio indica uno storage di classe NVMe?

Con queue depth 1, letture casuali 4k e --direct=1, una latenza media di completamento vicina a 110 microsecondi è tipica dello storage di classe NVMe. Da questo valore derivano circa 9,000 IOPS. Un valore intorno a 320 microsecondi indica un SSD SATA. Un valore intorno a 900 microsecondi indica uno storage collegato alla rete, nel quale le letture che non trovano i dati nella cache dell'host attraversano un hop di rete, oppure un volume soggetto a limitazione da parte dell'host. Questi sono intervalli tipici pubblicati per agosto 2026. Confronta quindi gli ordini di grandezza, non i valori esatti, e ripeti il test in orari diversi prima di trarre una conclusione.