Linux VPS에서 실제 NVMe 디스크 여부 확인하는 방법

Linux에서 NVMe 디스크를 확인하는 4단계 절차

Linux VPS에서 NVMe 디스크를 확인하려면 다음 4가지 점검을 순서대로 수행합니다. lsblk로 장치 이름을 확인하고, rotational 플래그와 sysfs의 버스 경로를 살피며, nvme list로 실제 NVMe 컨트롤러인지 확인한 뒤, 마지막으로 fio를 짧게 실행하여 호스트가 가짜로 꾸며낼 수 없는 유일한 수치를 확인합니다. 앞의 세 단계는 각각 1초면 충분합니다. 마지막 단계가 핵심인데, 대부분의 VPS 플랫폼은 하이퍼바이저가 게스트에게 물리 디스크를 숨기기 때문입니다.

NVMe(non-volatile memory express)는 플래시 스토리지가 PCIe(peripheral component interconnect express) 레인을 통해 통신하는 프로토콜입니다. 이는 회전식 드라이브를 위해 설계된 SATA 및 AHCI 경로를 대체했으며, CPU와 플래시 사이의 큐 병목 현상을 제거하여 속도가 빠릅니다. 가상 머신 내부에서는 이 프로토콜을 직접 사용하는 경우가 거의 없습니다. 사용자는 호스트가 구성해 준 가상 디스크와 통신하므로, 게스트의 장치 이름은 실제 랙에 있는 매체가 아닌 드라이버를 가리킵니다.

1단계: lsblk는 무엇을 보여주는가?

lsblk은 커널의 블록 장치 목록을 읽어옵니다. -d 플래그를 사용하면 파티션이 숨겨지므로 디스크당 한 줄씩만 표시됩니다.

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

KVM VPS는 보통 다음과 같이 응답합니다:

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

대부분의 Linux 서버는 다음 세 가지 명명 규칙을 따릅니다:

• nvme0n1는 NVMe 컨트롤러 0의 네임스페이스 1입니다. 게스트가 실제 또는 에뮬레이션된 NVMe 장치를 구동 중임을 의미합니다.
• sda은 SCSI 계층입니다. 실제 SATA 및 SAS 디스크가 여기에 해당하며, virtio-scsi 드라이버도 이 명명 규칙을 사용합니다.
• vda는 대부분의 KVM 호스트가 기본으로 사용하는 반가상화 블록 드라이버인 virtio-blk입니다.

TRAN(전송) 열은 NVMe 장치의 경우 nvme으로, 게스트가 직접 인식할 수 있는 SATA 디스크의 경우 sata로 표시됩니다. virtio-blk 환경에서 최신 util-linux 릴리스는 vd 장치 이름을 바탕으로 추론한 virtio을 출력하며, 이전 릴리스에서는 이 항목이 비어 있습니다. 어느 경우든 게스트가 보고할 물리적 전송 방식은 존재하지 않습니다. MODEL이 비어 있는 이유도 동일합니다. VPS에서 모델 문자열이 비어 있는 것은 정상이며, 이는 하드웨어에 대해 아무런 정보를 제공하지 않습니다.

2단계: 회전식 디스크 여부 확인

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"

rotational 파일은 커널이 해당 장치를 회전식 플래터가 있는 것으로 간주할 때 1를, 그렇지 않을 때 0을 담고 있습니다. 베어메탈 환경에서는 이 값이 드라이브 자체에서 결정됩니다. virtio-blk 환경에서는 이 값이 어디서도 오지 않습니다. virtio-blk 사양에는 미디어 유형이나 회전 속도에 대한 기능 비트가 없으며, Linux virtio-blk 드라이버는 모든 디스크를 회전식으로 표시합니다. 따라서 vda는 누군가 udev 규칙을 통해 강제로 0으로 설정하지 않는 한, 올플래시 호스트에서도 보통 1로 읽힙니다. virtio-scsi sda에서는 호스트가 설정한 값이 그대로 나타납니다. 그러므로 VPS 내부에서 이 플래그만으로는 하드 드라이브 여부를 판단할 수 없으며, 1이 표시된다는 사실만으로 지원 티켓을 발행할 근거가 되지 않습니다. 아래의 fio 테스트가 이 질문에 대한 답을 제공합니다.

readlink -f는 sysfs 심볼릭 링크를 해석하여 장치가 연결된 버스를 출력합니다:

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

해당 경로에 포함된 virtio이라는 단어가 이 단계의 답입니다. NVMe 장치는 /sys/devices/pci0000:00/0000:01:00.0/nvme/nvme0/nvme0n1와 같이 nvme을 포함하는 경로를 반환하며, 직접 연결된 ATA 디스크는 ata1을 포함하는 경로를 반환합니다. 이는 lsblk가 출력하는 것과 동일한 정보이며, 서식이 지정된 열이 아닌 커널에서 직접 가져온 값이므로 TRAN 필드가 비어 있을 때 유용합니다.

3단계: nvme-cli 및 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는 네임스페이스당 한 행씩 컨트롤러의 일련번호, 모델명, 펌웨어 버전을 출력합니다. 표가 비어 있다면 게스트에 노출된 NVMe 장치가 없다는 뜻입니다. lspci에서 일치하는 줄이 출력되지 않는 것 역시 같은 의미입니다. 즉, 게스트가 인식하는 가상 PCI 버스에 NVMe 컨트롤러가 존재하지 않습니다. 두 결과 모두 virtio 기반 VPS에서는 정상이며, 호스트에 NVMe 드라이브가 없다는 증거는 아닙니다.

네임스페이스가 나타난다면 nvme-cli를 더 활용할 수 있습니다. sudo nvme id-ctrl /dev/nvme0은 컨트롤러 식별 정보를, sudo nvme smart-log /dev/nvme0n1은 온도, 전원 켜짐 시간, 정격 쓰기 내구도 사용률을 출력합니다. 이 명령들은 실제 /dev/nvme* 노드를 열어야 하므로, nvme list에서 장치가 목록에 나타났을 때만 실행하십시오.

진정한 NVMe 호스트임에도 /dev/vda로 표시되는 이유

하이퍼바이저는 게스트가 어떤 장치 모델을 볼지 결정하며, 이 선택은 하부의 물리적 매체와는 무관합니다. 흔히 사용되는 구성은 세 가지입니다.

• NVMe 드라이브에 위치한 파일, 논리 볼륨 또는 ZFS 데이터셋 위에서 동작하는 virtio-blk 또는 virtio-scsi입니다. 이 경우 vda 또는 sda이 표시됩니다. 저장소는 NVMe이지만, 게스트는 이를 알 방법이 없습니다.
• 어떤 저장소든 그 앞에 배치된 에뮬레이션된 NVMe 컨트롤러입니다. SATA 배열이나 두 랙 떨어진 네트워크 볼륨에 데이터가 저장되더라도 nvme0n1가 표시됩니다.
• PCIe 패스스루(passthrough)로, 호스트가 물리적 컨트롤러를 특정 게스트 하나에 직접 할당하는 방식입니다. 이때는 실제 모델명이 포함된 실제 nvme0n1이 표시됩니다. 공유 VPS 플랜에서는 카드가 해당 고객 한 명에게 전용되어야 하므로 드물게 사용됩니다.

따라서 장치 이름은 양방향으로 오해를 불러일으킬 수 있습니다. 더 나쁜 점은 호스트가 쓰기 캐시(write-back cache), RAID 계층, 또는 복제된 네트워크 볼륨을 쓰기 작업과 플래시 사이에 배치할 수 있다는 것입니다. 이들 각각은 /sys의 이름을 바꾸지 않으면서도 실제 성능을 변화시킵니다. 이것이 바로 장치 이름이 시작점일 뿐 종착점이 되어서는 안 되는 이유입니다. 아직 플랜을 선택 중이라면, NVMe와 SATA SSD 저장소의 차이에서 각 계층이 실제로 지불할 가치가 있는지 확인하십시오.

지연 시간 측정은 가장 정직한 성능 테스트입니다

fio (flexible I/O tester)는 실제 파일에 대해 실제 읽기 작업을 수행하고 각 작업에 소요된 시간을 보고합니다. 작은 크기의 무작위 읽기 작업은 미디어까지의 왕복 시간을 드러내며 미리 읽기(read-ahead) 기능으로 처리할 수 없으므로, 이 테스트에 적합한 작업 부하입니다.

먼저 테스트 파일을 생성하고 해당 파일 시스템이 버퍼를 거치지 않는 I/O를 허용하는지 확인합니다. --direct=1는 O_DIRECT 옵션으로 파일을 여는데, 이는 페이지 캐시를 우회합니다. 이 옵션이 없으면 디스크가 낼 수 없는 RAM의 속도만 측정하게 됩니다.

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"

만약 거부 메시지가 출력된다면, 선택한 경로의 파일 시스템이 O_DIRECT을 지원하지 않는 것입니다. 컨테이너 오버레이 파일 시스템이나 일부 네트워크 파일 시스템이 이러한 방식으로 동작합니다. VPS 루트 파일 시스템의 디렉터리를 선택하여 다시 시도하십시오. 성공 메시지가 출력되면 다음 명령으로 측정을 수행합니다.

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

이 테스트는 의도적으로 제한을 두었습니다. 작업 1개, 큐 깊이 1, 20초 동안 256 MB의 데이터를 처리합니다. 디스크를 가득 채우지 않으며, 남용으로 간주되어 차단될 일도 없습니다. 큐 깊이 1은 이 질문에 대한 가장 정직한 설정입니다. 큐 깊이가 깊으면 느린 장치라도 병렬 처리를 통해 지연 시간을 숨길 수 있기 때문입니다.

fio 출력 읽기

두 줄이 중요합니다. 요약 줄은 read: IOPS=9012, BW=35.2MiB/s과 같이 표시되며, 그 아래에 fio가 clat 블록을 출력합니다. clat은 완료 지연 시간(completion latency)으로, fio가 읽기 요청을 제출한 시점부터 커널이 데이터를 반환할 때까지 걸린 시간입니다. avg 값을 읽은 다음, clat percentiles 목록에서 99.00th 백분위수 값을 확인하십시오. 평균값은 스토리지 등급을 알려줍니다. 99번째 백분위수 값은 가장 느린 1퍼센트의 읽기 작업이 얼마나 느렸는지를 나타내며, 공유 호스트에서 경합이 발생할 때 가장 먼저 드러나는 지표입니다.

fio는 값이 작을 때는 마이크로초 단위로 지연 시간을 출력하고, 값이 커지면 밀리초 단위로 전환합니다. 값을 비교하기 전에 해당 줄의 단위를 먼저 확인하십시오.

NVMe 클래스와 SATA 클래스를 구분하는 수치

아래 수치는 2026년 8월 기준, 벤더 문서와 커뮤니티 벤치마크에서 수집한 큐 깊이(queue depth) 1에서의 4k 랜덤 읽기 작업에 대한 일반적인 발표값입니다. 이는 서버에서 직접 측정한 값이 아니라 비교를 위한 기준 범위입니다.

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

로컬 NVMe 볼륨은 4k 랜덤 읽기 요청 하나를 약 110 마이크로초 만에 처리하며, 큐 깊이 1에서 약 9,000 IOPS에 도달합니다. 로컬 SATA SSD는 320 마이크로초 및 3,100 IOPS 부근에 위치합니다. 네트워크 연결 블록 스토리지(network attached block storage)는 약 1,100 IOPS와 900 마이크로초 수준을 보입니다. 이는 호스트 측 캐시에서 적중하지 못한 읽기 요청이 플래시 메모리에 도달하기 전 네트워크를 거쳐야 하기 때문입니다.

큐 깊이 1에서 이 두 열의 수치는 사실상 같은 내용을 다르게 표현한 것입니다. 한 번에 하나의 읽기 작업만 수행할 때 처리량은 대략 1을 지연 시간으로 나눈 값과 같으며, 요청당 오버헤드를 고려하면 이보다 약간 낮아집니다. 평균 지연 시간이 320 마이크로초보다 110 마이크로초에 더 가깝다면, lsblk가 해당 장치를 무엇이라 부르든 상관없이 NVMe 클래스 스토리지를 사용 중인 것입니다. 만약 900 마이크로초에 더 가깝다면, 로컬 플래시보다 느린 장치가 경로에 있거나 호스트가 볼륨의 IOPS를 제한하고 있는 상황입니다. QEMU와 같은 하이퍼바이저는 하부 스토리지의 종류와 관계없이 이러한 제한을 걸 수 있습니다. 두 경우 모두 호스트 드라이브에 대한 주문 페이지의 설명과 관계없이, 해당 볼륨은 NVMe 클래스의 지연 시간을 제공하지 못하고 있습니다.

불평하기 전에 여러 번 실행하십시오

단 한 번의 실행은 결과가 아니라 표본에 불과합니다. VPS는 디스크를 공유하므로, 이웃한 서버의 작업 부하가 높으면 10분 동안 지연 시간이 두 배로 늘어났다가 사라질 수 있습니다. 일부 플랫폼은 테스트 초기 몇 분 동안 성능이 매우 우수하게 보이도록 만드는 버스트 크레딧을 제공하기도 합니다. 하루 중 서로 다른 시간대에 동일한 명령을 3~4회 실행하여 가장 좋은 결과가 아닌 가장 나쁜 결과를 비교하십시오. 단 한 번의 나쁜 결과는 일시적인 현상일 뿐입니다. 패턴이 확인된다면 지원 티켓을 발행할 가치가 있는 결함이며, 타임스탬프가 찍힌 3개의 fio 출력 결과를 첨부하면 티켓의 신뢰도가 높아집니다. CPU와 네트워크를 포함한 디스크 전반의 더 넓은 상황을 파악하려면, 전체 VPS 벤치마크 실행을 통해 다른 하위 시스템에 대해서도 동일한 원칙을 적용하십시오.

결과를 어떻게 처리할 것인가

지연 시간이 NVMe 대역에 있다면 장치 이름에 대해 걱정하는 것을 멈추고 다음 단계로 넘어가십시오. vda는 성능 저하가 아닙니다. 이는 대부분의 호스트가 제공하는 가장 빠른 가상 디스크 드라이버이며, 여러분이 사용해야 할 드라이버입니다.

로컬 NVMe로 판매되는 플랜임에도 지연 시간이 네트워크 스토리지 대역에 있다면, 정확한 fio 명령어, 평균 완료 지연 시간, 테스트를 수행한 시간 등 구체적이고 재현 가능한 근거를 확보하십시오. 이는 포럼에서 논쟁할 문제가 아니라 기술 지원 티켓을 발행할 사안입니다. 티켓을 보내기 전에 디스크가 단순히 꽉 찼거나 심하게 파편화되지 않았는지 확인하고, 테스트 중에 서버의 다른 프로세스가 과도한 쓰기 작업을 수행하고 있지 않은지 확인하십시오.

이 점검은 성능이 느리다고 느껴질 때가 아니라 서버를 프로비저닝한 당일에 수행하여, 나중에 비교할 수 있는 기준점을 마련해 두십시오. 이 작업은 방화벽과 SSH 키를 설정하는 것과 함께 새 VPS를 위한 첫 10분 과정에 자연스럽게 포함됩니다. 스토리지 계층 간의 구분이 여전히 모호하다면, SSD VPS가 실제로 제공하는 것에서 이 내용의 기초가 되는 정보를 다루고 있습니다.

FAQ

lsblk는 왜 호스트가 NVMe를 제공한다고 하는데 /dev/vda로 표시합니까?

vda은 호스트의 하드웨어가 아니라 게스트의 virtio-blk 드라이버를 지칭하기 때문입니다. KVM 하이퍼바이저는 파일, 논리 볼륨 또는 데이터셋으로 구성된 반가상화 블록 장치를 제공하며, 게스트는 해당 저장소가 NVMe 드라이브에 위치하는지 알 수 없습니다. 장치 이름은 가상화 계층을 설명할 뿐입니다. 오직 지연 시간 측정만이 실제 매체의 성능을 나타냅니다.

rotational 0은 NVMe 디스크라는 증거입니까?

아닙니다. /sys/block/<dev>/queue/rotational에 0가 표시되는 것은 커널이 해당 장치를 회전식 플래터가 없는 것으로 간주한다는 의미일 뿐, VPS 내부에서는 이것이 측정값이 아닌 설정값입니다. virtio-blk에는 매체 유형을 나타내는 기능 비트가 없으며, Linux virtio-blk 드라이버는 별도의 설정이 없는 한 모든 디스크에 대해 1를 보고합니다. 따라서 0가 표시된다면 누군가 수동으로 설정했을 가능성이 큽니다. 이 값으로는 NVMe와 SATA SSD를 구분할 수 없으며, 로컬 플래시와 네트워크 볼륨도 구분할 수 없습니다. VPS 내부의 1는 하드 드라이브 여부도 증명하지 못하므로, 이 플래그가 아닌 fio 지연 시간 측정 결과를 기준으로 판단하십시오.

VPS에서 nvme list가 비어 있는 이유는 무엇입니까?

게스트에 노출된 NVMe 컨트롤러가 없기 때문입니다. nvme list와 lspci은 모두 가상 머신이 인식할 수 있는 장치만 읽어 들이는데, virtio-blk 또는 virtio-scsi 디스크는 열거할 수 있는 NVMe 컨트롤러를 제공하지 않습니다. 대부분의 VPS 플랜에서 빈 테이블이 출력되는 것은 정상이며, 호스트에 NVMe 드라이브가 없다는 증거가 아닙니다. sudo apt install -y nvme-cli로 nvme-cli를 설치하더라도 컨트롤러가 패스스루(passthrough)되지 않았다면 테이블은 비어 있게 됩니다.

어떤 fio 결과가 NVMe급 저장소입니까?

큐 깊이(queue depth) 1, 4k 랜덤 읽기, --direct=1 조건에서 평균 완료 지연 시간이 110 마이크로초에 가까우면 NVMe급이며, 대략 9,000 IOPS 수준의 성능이 나옵니다. 320 마이크로초 부근은 SATA SSD를 가리키며, 900 마이크로초 부근은 네트워크 연결 저장소를 가리킵니다. 네트워크 저장소의 경우 호스트 캐시를 거치지 않는 읽기 작업이 네트워크 홉을 통과하거나 호스트에 의해 볼륨 성능 제한이 걸려 있을 수 있습니다. 위 수치는 2026년 8월 기준의 일반적인 범위이므로 정확한 수치보다는 자릿수 단위의 차이를 비교하고, 결론을 내리기 전에 시간대를 달리하여 여러 번 테스트를 반복하십시오.