Cara Memantau Kesehatan Disk pada VPS

Pemantauan kesehatan disk yang benar-benar dapat dilihat pada VPS

Pemantauan kesehatan disk pada VPS dimulai dari fakta yang sering diabaikan oleh banyak panduan: disk tersebut bukan milik Anda. Guest Anda melihat perangkat blok virtual. Drive fisik dan setiap penghitung yang tersimpan di dalamnya adalah milik host. smartctl /dev/vda gagal bukan karena Anda salah mengetik perintah. Kegagalan terjadi karena tidak ada perangkat di balik device tersebut yang dapat menjawab pertanyaan itu.

SMART (self-monitoring, analysis and reporting technology) adalah tabel penghitung yang disimpan langsung pada drive: sektor yang dialokasikan ulang, sektor tertunda, jam sejak dinyalakan, dan error media. Pembacaan tabel tersebut memerlukan jalur agar perintah ATA atau NVMe (non-volatile memory express) dapat mencapai hardware fisik. Disk paravirtual tidak menyediakan jalur itu, sehingga guest menerima storage tanpa telemetri tersebut.

Tenant memantau dampaknya, bukan hardwarenya. Ada empat sinyal yang terlihat dari dalam guest: error I/O (input/output) pada log kernel, filesystem yang di-mount ulang sebagai read-only, latensi yang terus meningkat, dan ruang penyimpanan yang habis. Keempatnya dapat dipantau dengan alert saat ini, dan semuanya muncul sebelum pengguna mengeluh. Siapkan pemantauan tersebut terlebih dahulu. Pembagian tanggung jawab dijelaskan di bagian akhir karena hal itu menentukan tempat Anda harus memusatkan upaya.

Buktikan apa yang diekspos server Anda sendiri

Jangan berasumsi mengenai kondisi server Anda. Periksa terlebih dahulu, lalu baca bagian yang sesuai.

sudo apt update && sudo apt install -y smartmontools nvme-cli
lsblk -o NAME,TYPE,SIZE,MODEL,TRAN
sudo smartctl -a /dev/vda

virtio-blk, disk KVM (kernel-based virtual machine) yang umum. Perangkatnya adalah /dev/vda dan smartctl berhenti sebelum mengirimkan apa pun:

/dev/vda: Unable to detect device type
Please specify device type with the -d option.

virtio-blk adalah transport paravirtual dengan tidak ada set perintah ATA atau SCSI di belakangnya. Karena itu, tidak ada saluran untuk membawa permintaan SMART. -d sat dan -d scsi gagal dengan cara yang sama karena masalahnya terletak pada transport, bukan pada flag.

Disk SATA atau SCSI yang diemulasikan. Perangkatnya adalah /dev/sda dan smartctl berhasil mengidentifikasinya. Baris model berisi QEMU HARDDISK. String tersebut sudah menjawab pertanyaannya: Anda sedang membaca perangkat yang dibuat oleh emulator, dan perangkat itu tidak melaporkan kemampuan SMART yang dapat digunakan.

Namespace NVMe. sudo nvme smart-log /dev/nvme0n1 mengembalikan log lengkap. Di sinilah banyak orang keliru. Periksa identitas controllernya terlebih dahulu dengan sudo nvme id-ctrl /dev/nvme0 | grep -E '^(mn|sn)'. Nomor model yang menyebut produk penyimpanan jaringan berarti controller tersebut adalah perangkat lunak. Jadi, percentage_used dan media_errors menjelaskan emulasi itu, bukan flash yang menyimpan data Anda. Jika ingin mengetahui jenis storage yang sebenarnya, verifikasi disk NVMe di Linux alih-alih mempercayai deskripsi paket.

Container, seperti LXC (Linux containers) atau OpenVZ. Anda tidak memiliki block device sendiri. lsblk menampilkan perangkat milik host atau tidak menampilkan apa pun, dan smartctl ditolak karena container tidak memiliki CAP_SYS_RAWIO:

Smartctl open device: /dev/sda failed: Permission denied

Ada satu peringatan untuk kondisi ketika perintah tersebut memang berhasil. Jika smartctl pada VPS mengembalikan tabel atribut lengkap, baca nomor serialnya sebelum mengambil tindakan. Beberapa host mengekspos node perangkat passthrough, dan penghitung tersebut berasal dari hardware yang digunakan bersama oleh semua tenant pada mesin itu. Nilai Reallocated_Sector_Ct yang meningkat merupakan alasan untuk membuat tiket dukungan. Nilai tersebut bukan pernyataan tentang data Anda.

Sinyal 1: Error I/O di log kernel

Ini adalah sinyal paling bernilai bagi tenant dan tidak memerlukan agent.

sudo journalctl -k -p err -b
sudo journalctl -k --since "7 days ago" | grep -iE 'i/o error|remount|ext4-fs error|buffer i/o'

Kegagalan request dari virtual disk terlihat seperti ini:

blk_update_request: I/O error, dev vda, sector 2101248 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0

Block layer meminta host melakukan penulisan, tetapi host mengembalikan kegagalan. Pada VPS, penyebabnya jarang berupa sel flash yang rusak. Biasanya penyebabnya adalah storage layer pada host atau jalur jaringan menuju network attached storage. Jadi, ini merupakan kejadian di sisi provider. Salin timestamp, nama device, dan sektor ke dalam tiket Anda karena tim storage dapat mencocokkan data tersebut dengan log mereka.

Urutan ext4 yang paling penting adalah pasangan berikut:

EXT4-fs error (device vda1): ext4_journal_check_start:83: comm cron: Detected aborted journal
EXT4-fs (vda1): Remounting filesystem read-only

Baris kedua adalah bagian yang paling berdampak karena mesin tetap berjalan. Mesin masih merespons ping dan SSH, tetapi setiap penulisan gagal. Pemeriksaan HTTP biasa tetap berhasil, sementara aplikasi Anda menghasilkan error pada setiap request.

XFS mematikan filesystem:

XFS (vda1): metadata I/O error in "xfs_trans_read_buf_map+0x1c0/0x2e0" at daddr 0x2 len 1 error 5
XFS (vda1): I/O Error Detected. Shutting down filesystem

journalctl -k hanya membaca boot saat ini, kecuali journal disimpan pada disk. Banyak image menggunakan journal volatile yang berada di RAM. Aktifkan persistence, atau bukti tersebut akan hilang tepat saat reboot yang Anda lakukan selama troubleshooting.

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald
journalctl --list-boots

Setelah reboot berikutnya, journalctl --list-boots seharusnya menampilkan lebih dari satu boot. Meskipun persistence telah diaktifkan, filesystem yang sudah menjadi read-only tidak dapat mencatat kejadian berikutnya. Ini merupakan alasan yang kuat untuk mengirim log ke luar mesin.

Sinyal 2: mendeteksi remount read-only

Buat kegagalan terlihat jelas sebelum mencoba mendeteksinya.

findmnt -no SOURCE,FSTYPE,OPTIONS /

Cari errors=remount-ro di dalam opsi. Image cloud Ubuntu dan Debian menetapkannya di /etc/fstab, sehingga error metadata membuat filesystem menjadi read-only, bukan terus berjalan dengan kerusakan. Jika opsi tersebut tidak ada, tambahkan ke entri root di /etc/fstab, atau tetapkan di superblock dengan sudo tune2fs -e remount-ro /dev/vda1. Penghentian yang jelas lebih baik daripada korupsi yang tidak terlihat.

Mount flag bukan bukti. Uji dengan menulis:

touch /var/tmp/.disk-probe

Pada root read-only, perintah tersebut mencetak tepat:

touch: cannot touch '/var/tmp/.disk-probe': Read-only file system

Gunakan /var/tmp, bukan /tmp. Pada sebagian besar image, /tmp adalah tmpfs yang disimpan di memori, sehingga keberhasilan menulis di sana tidak membuktikan apa pun tentang disk Anda.

Gabungkan pengujian penulisan dengan pemeriksaan ruang, lalu kirim heartbeat hanya jika semua pemeriksaan berhasil:

sudo tee /usr/local/sbin/disk-probe >/dev/null <<'EOF'
#!/bin/sh
set -eu
probe=/var/tmp/.disk-probe
echo ok > "$probe"
test "$(cat "$probe")" = ok
rm -f "$probe"
used=$(df --output=pcent / | tail -n1 | tr -dc '0-9')
test "$used" -lt 90
inodes=$(df --output=ipcent / | tail -n1 | tr -dc '0-9')
test "$inodes" -lt 90
curl -fsS --max-time 10 "https://status.example.com/api/push/REPLACE_TOKEN?status=up&msg=OK" >/dev/null
EOF
sudo chmod 755 /usr/local/sbin/disk-probe
sudo /usr/local/sbin/disk-probe && echo probe-ok

probe-ok pada baris terakhir berarti seluruh rangkaian perintah berhasil. set -eu membuat setiap pemeriksaan yang gagal keluar dengan status non-zero sebelum baris curl dijalankan, sehingga tidak ada heartbeat yang dikirim. Inversi ini adalah intinya: monitor berubah merah karena tidak ada heartbeat yang masuk, dan server yang tidak dapat menulis tidak dapat dipercaya untuk menjelaskan masalahnya sendiri. Operasi baca tetap berfungsi pada filesystem read-only, sehingga script tetap dapat dijalankan.

Jalankan dari systemd timer.

# /etc/systemd/system/disk-probe.service
[Unit]
Description=Disk writability and space probe

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/disk-probe

# /etc/systemd/system/disk-probe.timer
[Unit]
Description=Run the disk probe every five minutes

[Timer]
OnBootSec=2min
OnUnitActiveSec=5min

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now disk-probe.timer
systemctl list-timers disk-probe.timer
journalctl -u disk-probe.service -n 20 --no-pager

systemctl list-timers seharusnya menampilkan unit tersebut dengan waktu NEXT yang kurang dari lima menit lagi. Eksekusi yang gagal muncul di journalctl -u disk-probe.service bersama teks error dari shell, sehingga Anda dapat membedakan filesystem read-only dari filesystem penuh tanpa login ke server.

URL push tersebut adalah push monitor Uptime Kuma. Buat monitor dengan tipe Push, salin tokennya ke dalam script, lalu tetapkan interval heartbeat monitor sedikit lebih panjang daripada interval timer agar satu eksekusi yang lambat tidak mengirim notifikasi pada pukul 03:00. Jika Anda belum memiliki status page, instance Uptime Kuma self-hosted adalah tempat termurah untuk menempatkan pemeriksaan ini.

Ada dua batasan yang perlu dipahami. Probe ini memastikan bahwa penulisan diterima, bukan bahwa byte tersebut telah mencapai penyimpanan persisten, karena pembacaan ulang dapat dilayani dari page cache. Selain itu, probe berjalan pada mesin yang dipantaunya, sehingga server yang benar-benar macet akan menjadi diam, bukan melaporkan diagnosis.

Tren latensi dan throughput

sudo apt install -y sysstat
iostat -xdz 5 3

Baca r_await dan w_await terlebih dahulu. Keduanya menunjukkan rata-rata waktu dalam milidetik yang diperlukan untuk menyelesaikan operasi baca atau tulis, termasuk waktu tunggu dalam antrean. Selanjutnya, baca aqu-sz, yaitu rata-rata jumlah permintaan yang sedang diproses. Abaikan %util pada disk virtual: nilai ini hanya berarti antrean tidak kosong. Perangkat yang melayani banyak permintaan secara paralel dapat berada di sekitar 100 persen meskipun belum mendekati batasnya. await adalah angka yang mencerminkan apa yang dirasakan pengguna.

Nilai absolut kurang penting dibandingkan baseline Anda sendiri. Karena itu, catat kondisi selama satu jam yang tenang dan simpan catatan tersebut. /proc/diskstats adalah sumber mentah jika Anda ingin mengumpulkan counter sendiri.

Untuk pengukuran terkontrol:

sudo apt install -y fio
fio --name=readlat --filename=/var/tmp/fio.probe --size=512M --rw=randread --bs=4k --iodepth=1 --direct=1 --runtime=30 --time_based --group_reporting
rm -f /var/tmp/fio.probe

Baca blok clat percentiles, terutama nilai persentil ke-99. --direct=1 melewati page cache Anda. Namun, perintah ini tidak melewati cache milik host, sehingga hasilnya menggambarkan seluruh jalur dari proses Anda hingga storage pada platform. Jalankan saat server tidak sibuk karena pengukuran ini bersaing dengan workload Anda sendiri.

Kenaikan await tanpa error dalam log kernel biasanya bukan tanda drive yang rusak. Penyebabnya biasanya adalah kontensi pada host, yaitu versi storage dari CPU steal time akibat tetangga yang membebani host. Jika kondisi ini kembali muncul pada jam yang sama setiap hari dan pemeriksaan tiket Anda tidak menemukan masalah, solusinya adalah menggunakan paket dengan I/O yang tidak dibagi dengan cara yang sama. Hal ini berlaku pada storage VPS dibandingkan VPS biasa ketika workload bergantung pada disk.

Pemeriksaan filesystem yang dapat dijalankan saat filesystem terpasang

ext4 menyimpan penghitung error di superblock. Penghitung ini tetap ada setelah reboot, meskipun log sudah tidak tersedia.

sudo dumpe2fs -h /dev/vda1 2>/dev/null | grep -iE 'filesystem state|error count|first error|last error'

Filesystem yang sehat menampilkan Filesystem state: clean dan FS Error count: 0. clean with errors dan jumlah yang bukan nol berarti kernel pernah menemukan error metadata, meskipun tidak ada yang menyadarinya dan log sudah tergantikan. Masukkan satu perintah tersebut ke dalam pemeriksaan mingguan.

Anda tidak dapat menjalankan fsck pada filesystem root yang sedang terpasang. Selain itu, e2fsck -n pada filesystem aktif dapat melaporkan masalah yang sebenarnya hanya disebabkan oleh perubahan data selama pemeriksaan berlangsung. Untuk memaksa pemeriksaan yang benar, tambahkan fsck.mode=force fsck.repair=yes ke command line kernel untuk satu kali boot melalui console provider Anda. Setelah itu, systemd-fsck menjalankan pemeriksaan sebelum root dipasang dalam mode read-write.

XFS tidak memiliki pemeriksaan online. xfs_repair -n /dev/vda1 menolak dijalankan pada filesystem yang sedang terpasang, sehingga perintah ini harus dijalankan dalam rescue mode. XFS mengimbanginya dengan memberikan indikasi yang jelas: filesystem dimatikan saat terjadi error metadata, bukan terus digunakan.

Pada Btrfs, penghitung tersebut sudah tersedia secara bawaan dan bersifat persisten.

sudo btrfs device stats /
sudo btrfs scrub start -B /

write_io_errs atau corruption_errs di atas nol menunjukkan kejadian nyata. Nilai penghitung tetap dipertahankan setelah reboot sampai Anda meresetnya. scrub membaca ulang setiap block dan memverifikasi checksum-nya. Ini adalah pengujian yang paling mendekati pemeriksaan media pada virtual disk. Operasi ini menggunakan I/O secara intensif, jadi jadwalkan pada jam yang sepi.

Sinyal 5: ruang kosong, termasuk bagian yang disembunyikan df

Kehabisan ruang merusak server dengan cara yang sama seperti disk yang rusak, dan hal ini jauh lebih sering terjadi.

df -h /
df -i /
sudo du -xh --max-depth=1 / | sort -h | tail -n 20

No space left on device sedangkan df -h menampilkan ruang kosong berarti inode habis, bukan byte. df -i menampilkan IUse% pada 100 persen. Jutaan file kecil dalam direktori cache atau spool email dapat menyebabkan kondisi ini, dan menghapus file besar tidak akan membantu.

Ruang yang tidak kembali setelah file dihapus biasanya disebabkan file tersebut masih terbuka dan ditahan oleh proses yang berjalan. sudo lsof +L1 mencantumkan file yang jumlah link-nya telah mencapai nol. Restart proses yang menahan file tersebut untuk melepaskan ruangnya.

Journal sering menjadi pengguna ruang yang tidak terlihat. journalctl --disk-usage melaporkan ruang yang digunakan journal. Batasi ukurannya dengan SystemMaxUse=200M dalam /etc/systemd/journald.conf, kemudian gunakan sudo systemctl restart systemd-journald dan pulihkan ruangnya sekarang dengan sudo journalctl --vacuum-size=200M.

Satu kondisi terlihat seperti bug, tetapi sebenarnya bukan. Pada penyimpanan host yang menggunakan thin provisioning, pool milik host dapat penuh meskipun df Anda masih menampilkan gigabyte yang tersedia. Penulisan data kemudian gagal dengan error I/O di log kernel, tanpa peringatan kehabisan ruang di dalam guest. Error tanpa filesystem yang penuh adalah kombinasi yang layak dilaporkan melalui tiket pada jam yang sama.

Menghubungkan sinyal ke metrics agent

Push probe hanya memberikan jawaban ya atau tidak. Untuk melihat tren, Anda memerlukan metrics agent. Prometheus node_exporter sudah mengekspor semua metrik di atas tanpa konfigurasi tambahan. Nama metrik yang dapat digunakan:

• node_filesystem_readonly bernilai 1 ketika mount bersifat read-only. Ini menjadi alarm remount.
• node_filesystem_avail_bytes dan node_filesystem_files_free mencakup byte dan inode secara terpisah.
• node_disk_io_time_seconds_total dan node_disk_read_time_seconds_total memberikan waktu sibuk dan latensi sebagai counter yang dapat Anda buat grafiknya.

Dua rule berikut menangani kondisi yang benar-benar memicu page:

- alert: FilesystemReadOnly
  expr: node_filesystem_readonly{fstype!~"tmpfs|overlay"} == 1
  for: 2m
- alert: FilesystemFillingUp
  expr: predict_linear(node_filesystem_avail_bytes{mountpoint="/"}[6h], 4*24*3600) < 0
  for: 30m

Rule kedua aktif ketika tren saat ini mencapai nol dalam empat hari. Dengan demikian, Anda menerima peringatan beberapa hari sebelumnya, bukan saat penggunaan mencapai 95 persen dan waktu yang tersisa hanya beberapa menit.

Siapa yang bertanggung jawab atas apa

Penyedia Anda memiliki drive fisik. Mereka membaca SMART, menjalankan array, dan mengganti drive yang mengalami peningkatan jumlah sektor yang direalokasi, biasanya tanpa memberi tahu Anda, karena array menanggung kegagalan tersebut. Itulah fungsi RAID 10 pada VPS Anda: drive yang mati menjadi proses rebuild, bukan outage. Anda tidak dapat melihat semua proses itu, dan membayar abstraksi tersebut merupakan salah satu alasan utama menyewa server virtual.

Anda bertanggung jawab atas data Anda, dan telemetri drive juga tidak akan melindunginya. Peristiwa yang benar-benar menghancurkan data tenant adalah rm yang keliru, deploy yang bermasalah, penyusup yang memiliki SSH key Anda, serta insiden platform yang turut menghentikan array. Atribut SMART tidak dapat memprediksi satu pun dari peristiwa tersebut.

Jadi, perlindungan nyata bagi tenant adalah backup yang disimpan di luar server dan proses restore yang telah Anda lakukan sendiri. Snapshot dari penyedia memang praktis dan berada pada platform yang sama dengan hal yang dilindunginya. Karena itu, snapshot dan backup adalah perlindungan yang berbeda. Jadwalkan latihan: sekali setiap kuartal, restore backup terbaru ke VPS baru, jalankan aplikasi, lalu catat waktu yang diperlukan. Angka tersebut adalah waktu pemulihan nyata Anda. Latihan pertama selalu lebih lama daripada perkiraan siapa pun.

Kapan SMART berlaku untuk Anda

Panduan yang mengajarkan smartctl memang benar, dan berlaku segera setelah perangkat keras tersebut benar-benar menjadi milik Anda:

• Server dedicated atau bare metal, yang membuat sudo smartctl -a /dev/sda mengembalikan tabel atribut lengkap dan smartd dapat mengirim email kepada Anda saat sebuah atribut berubah.
• Paket penyimpanan yang meneruskan disk fisik langsung ke guest. Penyedia layanan biasanya mendokumentasikan hal ini secara eksplisit karena merupakan keunggulan produk.
• Perangkat keras milik Anda sendiri, di rumah atau di rack space yang Anda sewa.
• Disk di balik RAID controller yang dapat diakses dengan sudo smartctl -a -d megaraid,0 /dev/sda, atau enclosure USB dengan -d sat.

Pada NVMe fisik, sudo smartctl -a -d nvme /dev/nvme0 dan sudo nvme smart-log /dev/nvme0n1 melaporkan critical_warning dan percentage_used langsung dari drive. Pada SATA fisik, atribut yang memprediksi kegagalan adalah Reallocated_Sector_Ct (5), Current_Pending_Sector (197), Offline_Uncorrectable (198), dan Reported_Uncorrect (187). Jika salah satunya berubah dari nol, rencanakan penggantian. Studi drive berskala besar terus menghasilkan daftar singkat yang sama, dan sebagian besar atribut lainnya hanya noise.

Jalankan daemon, bukan memeriksanya secara manual.

sudo systemctl enable --now smartd
sudo smartctl -t short /dev/sda
sudo smartctl -l selftest /dev/sda

Log self-test seharusnya menampilkan Completed without error untuk proses yang baru saja Anda mulai. Ubuntu dan Debian menyertakan /etc/smartd.conf dengan baris DEVICESCAN, yang berlaku hingga August 2026, sehingga daemon memeriksa setiap disk yang dapat dilihatnya dan mengirim email kepada root saat terjadi perubahan. Semua itu tidak berfungsi pada disk virtual. Karena itu, panduan ini berlanjut ke bagian berikutnya.

FAQ

Mengapa smartctl tidak berfungsi pada VPS saya?

Karena disk tersebut bersifat virtual. Pada guest KVM yang menggunakan virtio-blk, smartctl -a /dev/vda mencetak /dev/vda: Unable to detect device type karena disk paravirtual tidak memiliki kanal perintah ATA atau SCSI untuk meneruskan permintaan SMART. Pada disk yang diemulasikan, Anda mengakses perangkat dengan model yang membaca QEMU HARDDISK, tanpa data SMART yang dapat digunakan di baliknya. Di dalam container, smartctl ditolak sepenuhnya karena tidak memiliki CAP_SYS_RAWIO. Tidak satu pun kondisi ini merupakan kesalahan konfigurasi, dan tidak ada flag -d yang dapat memperbaikinya.

Bagaimana cara mengetahui apakah disk VPS saya bermasalah?

Pantau dampaknya, bukan perangkat kerasnya. Periksa sudo journalctl -k -p err -b untuk mencari baris blk_update_request: I/O error dan Remounting filesystem read-only. Jalankan sudo dumpe2fs -h /dev/vda1 | grep -i 'error count' untuk menemukan error yang sudah tidak tersedia di log. Pantau r_await dari iostat -xdz 5 dan bandingkan dengan baseline yang Anda catat saat sistem masih sehat. Pada VPS, error I/O biasanya menunjukkan masalah storage pada host, bukan drive yang rusak. Karena itu, sertakan masalah tersebut dalam tiket dukungan bersama timestamp dan sektor yang terkait.

Apa yang harus dipantau sebagai alert untuk kesehatan disk VPS?

Empat alert sudah mencukupi. Mount read-only, baik yang berasal dari node_filesystem_readonly == 1 maupun probe penulisan yang gagal. Ruang kosong dan inode kosong yang terus mendekati nol. Setiap I/O error kernel dalam interval terakhir. Heartbeat dari server, sehingga tidak adanya respons akan memicu halaman ketika server berhenti merespons. Jangan gunakan nilai yang berasal dari SMART, karena pada disk virtual nilai tersebut tidak tersedia atau hanya menjelaskan emulasi hypervisor.

Mengapa filesystem saya di-mount ulang sebagai read-only?

ext4 yang di-mount dengan errors=remount-ro sengaja melakukan hal ini ketika menemukan error metadata. Filesystem berhenti menulis agar kerusakan tidak berlanjut. Pemicu masalah terdapat di log kernel, tepat di atas baris remount. Biasanya berupa EXT4-fs error tentang journal yang dibatalkan setelah perangkat yang mendasarinya mengembalikan error I/O. Melakukan remount sebagai read-write tanpa memeriksa filesystem hanya menyembunyikan gejala dan mempertahankan penyebabnya. Simpan log tersebut, lalu periksa filesystem dalam keadaan unmounted dari rescue mode menggunakan e2fsck -fy /dev/vda1.

Apakah saya dapat membaca data SMART pada server virtual?

Dalam kondisi tertentu, ya. Server dedicated dan bare metal menyediakan atribut perangkat yang sebenarnya. Demikian juga paket storage yang meneruskan disk fisik ke guest, serta host yang Anda miliki sendiri. Beberapa platform menyediakan controller NVMe kepada guest dan nvme smart-log mengembalikan sebuah log. Karena itu, jalankan sudo nvme id-ctrl /dev/nvme0 terlebih dahulu. Nomor model yang mencantumkan layanan network storage berarti penghitung tersebut berasal dari software controller. Jika node passthrough memang menampilkan penghitung perangkat yang sebenarnya pada mesin bersama, penghitung tersebut menggambarkan hardware yang digunakan bersama tenant lain. Dalam kondisi itu, tindakan yang berguna hanya membuat tiket dukungan.