Cómo comprobar si tu VPS usa NVMe de verdad

Verificar un disco NVMe en Linux en cuatro pasos

Para verificar un disco NVMe en un VPS Linux, ejecute cuatro comprobaciones en este orden: lsblk para obtener el nombre del dispositivo, el indicador rotational y la ruta del bus en sysfs, nvme list para confirmar que existe un controlador NVMe real y una ejecución breve de fio para obtener el único dato que un host no puede falsear. Las tres primeras comprobaciones tardan un segundo cada una. La última resuelve la duda porque, en la mayoría de las plataformas VPS, el hipervisor oculta el disco físico al sistema invitado.

NVMe (non-volatile memory express) es el protocolo que utiliza el almacenamiento flash a través de los carriles PCIe (peripheral component interconnect express). Sustituyó la ruta SATA y AHCI, diseñada para unidades mecánicas, y es rápido porque elimina un cuello de botella de colas entre la CPU y la memoria flash. Dentro de una máquina virtual, rara vez se utiliza ese protocolo directamente. El sistema se comunica con un disco virtual que el host prepara, por lo que el nombre del dispositivo del sistema invitado describe un controlador, no el medio de almacenamiento instalado en el servidor.

Paso 1: ¿qué muestra lsblk?

lsblk lee la lista de dispositivos de bloque del kernel. La opción -d oculta las particiones, por lo que se muestra una línea por disco.

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

Un VPS KVM normalmente responde así:

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

Tres patrones de nombres cubren casi todos los servidores Linux:

• nvme0n1 es el espacio de nombres 1 del controlador NVMe 0. El sistema invitado utiliza un dispositivo NVMe, real o emulado.
• sda corresponde a la capa SCSI. Los discos SATA y SAS reales aparecen aquí, al igual que el controlador virtio-scsi.
• vda corresponde a virtio-blk, el controlador de bloques paravirtualizado que la mayoría de los hosts KVM utiliza de forma predeterminada.

La columna TRAN (transporte) muestra nvme para un dispositivo NVMe y sata para un disco SATA que el sistema invitado puede ver directamente. Con virtio-blk, las versiones actuales de util-linux muestran virtio, que lsblk deduce del nombre del dispositivo vd, mientras que las versiones anteriores la dejan vacía. En cualquier caso, el sistema invitado no tiene ningún transporte físico que informar. MODEL también está vacía por el mismo motivo. Que la cadena del modelo esté vacía en un VPS es normal y no proporciona información sobre el hardware.

Paso 2: descartar un disco magnético

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"

El archivo rotational contiene 1 cuando el kernel trata el dispositivo como si tuviera platos giratorios y 0 en los demás casos. En un servidor físico, el valor procede de la unidad. Con virtio-blk no procede de ninguna parte: la especificación de virtio-blk no tiene ningún bit de funcionalidad para indicar el tipo de medio o la velocidad de rotación, y el controlador virtio-blk de Linux marca todos los discos como rotacionales. Por tanto, un vda normalmente muestra 1 incluso en un host totalmente basado en flash, salvo que alguien lo haya forzado a 0 mediante una regla de udev. En un sda virtio-scsi, el valor es el que el host haya configurado. Por eso, dentro de una VPS este indicador no permite confirmar ni descartar un disco duro, y un 1 por sí solo no justifica abrir un ticket de soporte. La prueba de fio que aparece a continuación es la que responde a esa pregunta.

readlink -f resuelve el enlace simbólico de sysfs e imprime el bus al que está conectado el dispositivo:

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

La palabra virtio en esa ruta es la respuesta para este paso. Un dispositivo NVMe muestra una ruta que contiene nvme, como /sys/devices/pci0000:00/0000:01:00.0/nvme/nvme0/nvme0n1, y un disco ATA conectado directamente muestra una que contiene ata1. Es el mismo dato que imprimió lsblk, obtenido del kernel en lugar de una columna formateada, lo que resulta útil cuando el campo TRAN está vacío.

Paso 3: consultar nvme-cli y el 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 muestra una fila por espacio de nombres, con el número de serie del controlador, la cadena del modelo y la revisión del firmware. Una tabla vacía significa que el invitado no tiene ningún dispositivo NVMe expuesto. lspci, si no muestra ninguna línea coincidente, indica lo mismo desde el otro lado: el bus PCI virtual que puede ver el invitado no contiene ningún controlador NVMe. Ambos resultados vacíos son normales en un VPS virtio y ninguno demuestra que el host no tenga unidades NVMe.

Si aparece un espacio de nombres, nvme-cli proporciona más información. sudo nvme id-ctrl /dev/nvme0 muestra la identidad del controlador y sudo nvme smart-log /dev/nvme0n1 muestra la temperatura, las horas de funcionamiento y el porcentaje de la resistencia nominal de escritura utilizado. Ejecute esos comandos sólo cuando nvme list haya mostrado realmente un dispositivo, porque ambos necesitan abrir un nodo /dev/nvme* real.

Por qué un host que realmente usa NVMe todavía muestra /dev/vda

El hipervisor decide qué modelo de dispositivo ve el sistema invitado. Esa decisión es independiente del medio de almacenamiento subyacente. Hay tres configuraciones habituales.

• virtio-blk o virtio-scsi sobre un archivo, un volumen lógico o un conjunto de datos de ZFS alojado en unidades NVMe. Se muestra vda o sda. El almacenamiento es NVMe. El sistema invitado no puede saberlo.
• Un controlador NVMe emulado delante de cualquier tipo de almacenamiento. Se muestra nvme0n1 incluso cuando los datos terminan en una matriz SATA o en un volumen de red situado dos racks más allá.
• PCIe passthrough, donde el host asigna un controlador físico a un único sistema invitado. Se muestra un nvme0n1 real con una cadena de modelo real. Esto es poco habitual en planes VPS compartidos, porque la tarjeta queda dedicada a un solo cliente.

Por tanto, el nombre del dispositivo puede inducir a error en ambos sentidos. Además, el host puede colocar una caché write-back, una capa RAID o un volumen de red replicado entre las escrituras y la memoria flash. Cada una de estas capas cambia el rendimiento obtenido sin modificar un solo nombre en /sys. Por eso, el nombre es el punto de partida, no el punto final. Si todavía está eligiendo un plan, la diferencia entre el almacenamiento NVMe y el almacenamiento SSD SATA explica cuánto merece la pena pagar por cada nivel.

La prueba real es la latencia, así que mídala

fio (flexible I/O tester) realiza lecturas reales contra un archivo real e informa cuánto tardó cada una. Las lecturas aleatorias pequeñas son la carga adecuada en este caso, porque muestran el tiempo de ida y vuelta hasta el medio de almacenamiento y no pueden ser atendidas mediante la lectura anticipada.

Primero cree el archivo de prueba y confirme que este sistema de archivos acepta E/S sin búfer. --direct=1 abre el archivo con O_DIRECT, lo que omite la caché de páginas. Sin esta opción, medirá la RAM del sistema y obtendrá valores que ningún disco puede producir.

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 se mostró el mensaje de rechazo, la ruta elegida está en un sistema de archivos sin compatibilidad con O_DIRECT. Los sistemas de archivos overlay de los contenedores y algunos sistemas de archivos de red se comportan así. Elija un directorio del sistema de archivos raíz de la VPS y vuelva a intentarlo. Si se mostró el mensaje de éxito, ejecute la medición:

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 ejecución está limitada de forma intencionada: un trabajo, una profundidad de cola de 1, veinte segundos y 256 MB de datos. No llenará el disco ni provocará que se marque el servidor por abuso. La profundidad de cola de 1 también es el valor adecuado para esta prueba, porque las colas profundas permiten que un dispositivo lento oculte su rendimiento mediante el paralelismo, mientras la latencia sigue siendo alta.

Lectura de la salida de fio

Hay dos líneas importantes. La línea de resumen tiene este formato: read: IOPS=9012, BW=35.2MiB/s. Debajo, fio muestra un bloque clat. clat es la latencia de finalización: el tiempo entre el envío de una lectura por parte de fio y la devolución de los datos por parte del kernel. Lea el valor avg y, después, el percentil 99.00th de la lista clat percentiles. El promedio indica la clase de almacenamiento. El percentil 99 indica cuánto tardó el 1 % más lento de las lecturas. Es ahí donde suele aparecer primero la contención en un host compartido.

Fio muestra la latencia en microsegundos cuando los valores son pequeños y cambia a milisegundos cuando dejan de serlo. Compruebe la unidad de la línea antes de comparar los valores.

Qué cifras separan la clase NVMe de la clase SATA

Las cifras siguientes son valores publicados habituales para lecturas aleatorias 4k de una sola tarea con profundidad de cola 1, recopilados de documentación de proveedores y pruebas comparativas de la comunidad hasta agosto de 2026. Son intervalos de referencia, no mediciones de su servidor.

[
  {
    "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 volumen NVMe local responde a una lectura aleatoria 4k en aproximadamente 110 microsegundos y alcanza unos 9,000 IOPS con profundidad de cola 1. Una SSD SATA local se sitúa cerca de 320 microsegundos y 3,100 IOPS. El almacenamiento de bloques conectado por red suele situarse alrededor de 900 microsegundos y 1,100 IOPS, porque una lectura que no encuentra los datos en ninguna caché del host debe atravesar la red antes de llegar a la memoria flash.

Con profundidad de cola 1, esas dos columnas expresan prácticamente el mismo dato: cuando sólo hay una lectura en curso, el rendimiento resulta aproximadamente de dividir uno por la latencia, aunque es algo menor al contar la sobrecarga de cada solicitud. Si su promedio se acerca más a 110 que a 320 microsegundos, utiliza almacenamiento de clase NVMe, independientemente de cómo lsblk haya decidido denominar el dispositivo. Si se acerca a 900 microsegundos, hay algo más lento que la memoria flash local en la ruta o el host está limitando los IOPS de su volumen, algo que pueden hacer hipervisores como QEMU con independencia del almacenamiento subyacente. En ambos casos, el volumen no ofrece una latencia de clase NVMe, independientemente de lo que indique la página de pedido sobre las unidades del host.

Ejecute la prueba varias veces antes de presentar una queja

Una ejecución es una muestra, no un resultado. Un VPS comparte sus discos, por lo que un vecino con mucha actividad puede duplicar la latencia durante diez minutos y después dejar de afectar al rendimiento. Algunas plataformas también conceden créditos de ráfaga, lo que hace que los primeros minutos de cualquier prueba parezcan excelentes. Ejecute el mismo comando tres o cuatro veces en distintas horas del día y compare el peor resultado, no el mejor. Un único resultado malo puede deberse a las condiciones del momento. Un patrón repetido indica un fallo que justifica abrir un ticket de soporte, y el ticket tendrá más peso si adjunta tres salidas de fio con sus marcas de tiempo. Para obtener una visión más amplia, que incluya la CPU y la red además del disco, una prueba de rendimiento completa del VPS aplica la misma disciplina a los demás subsistemas.

Qué hacer con el resultado

Si la latencia está en el rango de NVMe, deje de preocuparse por el nombre del dispositivo y continúe. vda no es una degradación. Es el controlador de disco virtual más rápido que ofrecen la mayoría de los hosts y es el que debe usar.

Si la latencia está en el rango del almacenamiento de red en un plan vendido como NVMe local, tiene una incidencia específica y reproducible: el comando exacto de fio, la latencia media de finalización y las horas a las que ejecutó la prueba. Eso corresponde a un ticket de soporte, no a una discusión en un foro. Antes de enviarlo, confirme que el disco no esté simplemente lleno o muy fragmentado y que ningún proceso del sistema esté escribiendo intensivamente durante la prueba.

Ejecute esta comprobación el día que aprovisione el servidor, no el día que algo parezca lento. Así tendrá una línea base para compararla más adelante. Esta comprobación encaja de forma natural en los primeros diez minutos en un VPS nuevo, junto con la configuración del firewall y las claves SSH. Si la diferencia entre los niveles de almacenamiento aún no está clara, qué ofrece realmente un VPS con SSD explica los fundamentos de este tema.

FAQ

¿Por qué lsblk muestra /dev/vda si mi proveedor anuncia NVMe?

Porque vda identifica el controlador virtio-blk en el guest, no el hardware del host. Un hipervisor KVM presenta un dispositivo de bloques paravirtual respaldado por un archivo, un volumen lógico o un dataset. Ese almacenamiento subyacente puede estar en unidades NVMe sin que el guest llegue a saberlo. El nombre describe la capa de virtualización. Sólo una medición de latencia describe el medio.

¿El valor rotational 0 demuestra que tengo un disco NVMe?

No. /sys/block/<dev>/queue/rotational con el valor 0 significa que el kernel no trata el dispositivo como si tuviera platos giratorios, pero en un VPS eso es una configuración, no una medición. virtio-blk no tiene un bit de características para indicar el tipo de medio, y el controlador virtio-blk de Linux informa 1 para todos los discos salvo que algo lo sobrescriba. Por tanto, un valor 0 normalmente significa que alguien lo estableció manualmente. No permite distinguir NVMe de una SSD SATA ni flash local de un volumen de red. Un valor 1 dentro de un VPS tampoco demuestra que haya un disco duro. Base la conclusión en la latencia de fio, no en este indicador.

¿Por qué nvme list no muestra nada en mi VPS?

Porque el guest no tiene expuesto ningún controlador NVMe. nvme list y lspci leen lo que puede ver la máquina virtual, y un disco virtio-blk o virtio-scsi no presenta ningún controlador NVMe para enumerarlo. Una tabla vacía es el resultado normal en la mayoría de los planes VPS y no demuestra que el host no tenga unidades NVMe. Instale nvme-cli con sudo apt install -y nvme-cli y espere una tabla vacía, salvo que se haya pasado un controlador a la máquina virtual.

¿Qué resultado de fio cuenta como almacenamiento de clase NVMe?

Con una profundidad de cola de 1, lecturas aleatorias de 4k y --direct=1, una latencia media de finalización cercana a 110 microsegundos corresponde a almacenamiento de clase NVMe. De ella se derivan aproximadamente 9,000 IOPS. Un valor cercano a 320 microsegundos apunta a una SSD SATA. Un valor cercano a 900 microsegundos apunta a almacenamiento conectado por red, donde las lecturas que no encuentran los datos en la caché del host atraviesan un salto de red, o a un volumen cuyo rendimiento está limitado por el host. Estas son bandas publicadas habituales para agosto de 2026. Compare órdenes de magnitud, no cifras exactas. Repita la prueba a distintas horas antes de sacar una conclusión.