Paano I-monitor ang Disk Health ng VPS

Ano talaga ang nakikita ng disk health monitoring sa isang VPS

Nagsisimula ang disk health monitoring sa isang VPS sa katotohanang iniiwasan ng karamihan sa mga guide: hindi sa iyo ang disk. Virtual block device ang nakikita ng guest mo. Sa host pagmamay-ari ang physical drive at lahat ng counter na naka-store dito. Hindi nagfa-fail ang smartctl /dev/vda dahil mali ang pag-type mo ng command. Nagfa-fail ito dahil walang makasagot sa tanong na iyon sa likod ng device.

Ang SMART (self-monitoring, analysis and reporting technology) ay isang table ng mga counter na naka-store mismo sa drive: reallocated sectors, pending sectors, power-on hours, at media errors. Para mabasa ang table na ito, kailangan ng path para makarating sa aktuwal na hardware ang mga ATA o NVMe (non-volatile memory express) command. Walang ganoong path ang paravirtual disk, kaya storage na walang telemetry ang natatanggap ng guest.

Mga epekto, hindi hardware, ang mino-monitor ng isang tenant. Apat na signal ang makikita mula sa loob ng guest: mga I/O (input/output) error sa kernel log, filesystem na nagre-remount bilang read-only, latency na unti-unting tumataas, at space na nauubos. Maaaring lagyan ng alert ang lahat ng apat ngayon, at lumilitaw ang mga ito bago magreklamo ang user. I-set up muna ang mga iyon. Sa huli ilalatag ang paghahati ng responsibilidad, dahil binabago nito kung saan dapat ilaan ang effort.

Tukuyin kung ano ang inilalantad ng sarili mong server

Huwag ipagpalagay kung aling sitwasyon ang iyong kinasasangkutan. Suriin muna, pagkatapos ay basahin ang seksyong tumutugma rito.

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

virtio-blk, ang karaniwang KVM (kernel-based virtual machine) disk. Ang device ay /dev/vda at humihinto ang smartctl bago ito magpadala ng anuman:

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

Ang virtio-blk ay paravirtual transport na walang ATA o SCSI command set sa likod nito, kaya walang channel na magdadala ng SMART request. Parehong pumapalya ang -d sat at -d scsi dahil transport ang problema, hindi ang flag.

Emulated SATA o SCSI disk. Ang device ay /dev/sda at sapat ang nararating ng smartctl upang matukoy ito. Ang model line ay QEMU HARDDISK. Sapat nang sagot sa tanong ang string na iyon: device na ginawa ng emulator ang binabasa mo, at wala itong magagamit na SMART capability.

NVMe namespace. Nagbabalik ang sudo nvme smart-log /dev/nvme0n1 ng kumpletong log, at dito nalilinlang ang mga tao. Suriin muna ang controller identity gamit ang sudo nvme id-ctrl /dev/nvme0 | grep -E '^(mn|sn)'. Kung ang model number ay tumutukoy sa isang network storage product, software ang controller. Ibig sabihin, inilalarawan ng percentage_used at media_errors ang emulation na iyon, hindi ang flash storage na kinaroroonan ng iyong data. Kung gusto mong malaman kung ano talaga ang storage mo, i-verify ang NVMe disk sa Linux sa halip na umasa sa plan description.

Container, gaya ng LXC (Linux containers) o OpenVZ. Wala kang sariling block device. Ipinapakita ng lsblk ang mga device ng host o wala itong ipinapakita, at tinatanggihan ang smartctl dahil hindi hawak ng container ang CAP_SYS_RAWIO:

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

Isang babala tungkol sa sitwasyong gumagana ito. Kung nagbabalik ang smartctl sa isang VPS ng kumpletong attribute table, basahin muna ang serial number bago kumilos. May ilang host na naglalantad ng passthrough device node, at ang mga counter na iyon ay kabilang sa hardware na pinaghahatian ng bawat tenant sa machine na iyon. Ang tumataas na Reallocated_Sector_Ct ay dapat ituring na support ticket. Hindi ito pahayag tungkol sa iyong data.

Signal 1: Mga I/O error sa kernel log

Ito ang pinakamahalagang signal na makukuha ng tenant, at hindi ito nangangailangan ng 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'

Ganito ang hitsura ng failed request mula sa virtual disk:

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

Humingi ang block layer sa host ng write, pero nagbalik ang host ng failure. Sa isang VPS, bihira itong sanhi ng sirang flash cell. Karaniwan itong problema sa host storage layer o sa network path papunta sa network-attached storage, kaya provider-side event ito. Isama sa ticket ang timestamp, device name, at sector. Magagamit ito ng storage team para itugma sa sarili nilang logs.

Ang pinakamahalagang ext4 sequence ay ang pares na ito:

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

Ang ikalawang linya ang pinakamalubha dahil nananatiling up ang machine. Sumasagot ito sa ping, sumasagot ito sa SSH, pero nagfa-fail ang bawat write. Patuloy na pumapasa ang plain HTTP check habang nagbabalik ng error ang application sa bawat request.

Sa halip, tina-shutdown ng XFS ang 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 ang kasalukuyang boot lang ang binabasa maliban kung naka-store sa disk ang journal. Maraming image ang may volatile journal na nasa RAM. I-enable ang persistence, o mawawala ang ebidensiya sa mismong reboot na gagawin mo habang nagta-troubleshoot.

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

Pagkatapos ng susunod mong reboot, dapat maglista ang journalctl --list-boots ng higit sa isang boot. Kahit naka-enable ang persistence, hindi maitatala ng filesystem na naging read-only ang mga sumunod na pangyayari. Ito ang malinaw na dahilan para magpadala ng logs palabas ng box.

Signal 2: pagtukoy sa read-only remount

Gawing malinaw ang failure bago mo ito subukang tukuyin.

findmnt -no SOURCE,FSTYPE,OPTIONS /

Hanapin ang errors=remount-ro sa options. Itinatakda ito ng Ubuntu at Debian cloud images sa /etc/fstab, kaya ginagawang read-only ng metadata error ang filesystem sa halip na ipagpatuloy ang operasyon kahit may damage. Kung wala ito, idagdag sa root entry sa /etc/fstab, o itakda sa superblock gamit ang sudo tune2fs -e remount-ro /dev/vda1. Mas mabuti ang malinaw na paghinto kaysa sa tahimik na corruption.

Hindi patunay ang mount flag. Mag-test sa pamamagitan ng pagsusulat:

touch /var/tmp/.disk-probe

Sa read-only root, eksaktong ito ang output:

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

Gamitin ang /var/tmp, hindi ang /tmp. Sa karamihan ng images, ang /tmp ay tmpfs na nasa memory, kaya walang napapatunayan ang matagumpay na pagsusulat doon tungkol sa disk mo.

Pagsamahin ang write test at space check, at magpadala lamang ng heartbeat kapag pumasa ang lahat ng check:

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

Sa huling linya, nangangahulugang gumagana ang buong chain ang probe-ok. Dahil pinapahinto ng set -eu ang execution kapag may failed check at nagbabalik ito ng non-zero bago tumakbo ang curl line, walang heartbeat na maipapadala. Iyan ang mahalagang inversion: nagiging red ang monitor dahil walang dumating, at hindi mapagkakatiwalaang ilarawan ng server ang sarili nitong problema kung hindi ito makapagsulat. Gumagana pa rin ang read operations sa read-only filesystem, kaya nagsisimula pa rin ang script mismo.

Patakbuhin ito gamit ang 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

Dapat ipakita ng systemctl list-timers ang unit na may NEXT time na wala pang limang minuto ang layo. Lumilitaw ang failed run sa journalctl -u disk-probe.service kasama ang sariling error text ng shell, kaya matutukoy mo kung read-only filesystem o full filesystem ang problema nang hindi nagla-login.

Ang push URL na iyon ay isang Uptime Kuma push monitor. Gumawa ng monitor na may type na Push, kopyahin ang token nito sa script, at itakda ang heartbeat interval ng monitor nang bahagyang mas mahaba kaysa sa timer interval upang hindi ka ma-page sa 03:00 dahil lamang sa isang mabagal na run. Kung wala ka pang status page, ang self-hosted na Uptime Kuma instance ang pinakamurang paglalagyan ng check na ito.

Dalawang mahalagang limitasyon. Kinukumpirma ng probe na tinanggap ang write, pero hindi nito kinukumpirma na nakarating ang bytes sa durable storage, dahil maaaring ihatid ang read back mula sa page cache. Tumatakbo rin ito sa machine na mino-monitor nito, kaya magiging tahimik ang server na tuluyang nag-hang sa halip na mag-ulat ng diagnosis.

Mga palatandaan 3: mga trend sa latency at throughput

sudo apt install -y sysstat
iostat -xdz 5 3

Basahin muna ang r_await at w_await. Ito ang average na millisecond na ginugol ng isang read o write, kasama ang oras ng paghihintay sa queue. Sunod na basahin ang aqu-sz, ang average na bilang ng mga request na kasalukuyang pinoproseso. Huwag pansinin ang %util sa isang virtual disk: nangangahulugan lamang ito na hindi walang laman ang queue. Ang device na sabay-sabay na nagse-serve ng maraming request ay maaaring nasa halos 100 percent kahit malayo pa ito sa limitasyon nito. Ang await ang numerong tumutugma sa latency na nararanasan ng mga user.

Mas mahalaga ang sarili mong baseline kaysa sa absolute values, kaya mag-record ng isang oras na tahimik ang server at itago ito bilang reference. Ang /proc/diskstats ang raw source kung mas gusto mong ikaw mismo ang mangolekta ng mga counter.

Para sa isang sadyang pagsukat:

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

Basahin ang block na clat percentiles, lalo na ang 99th percentile. Nilalampasan ng --direct=1 ang page cache ng iyong proseso. Hindi nito nilalampasan ang cache ng host, kaya inilalarawan ng resulta ang buong path mula sa iyong process hanggang sa storage ng platform. Patakbuhin ito habang idle ang server, dahil nakikipagkumpitensya ito sa sarili mong workload.

Ang tumataas na await nang walang error sa kernel log ay karaniwang hindi palatandaan ng sirang drive. Contention ito sa host—ang katumbas sa storage ng CPU steal time mula sa maingay na katabing tenant. Kung bumabalik ito sa parehong oras araw-araw at malinis ang resulta ng ticket mo, ang solusyon ay plan na hindi ganoon ang paraan ng pagbabahagi ng I/O. Ganito ang sitwasyon ng storage VPS kumpara sa regular na VPS kapag disk-bound ang workload.

Mga Signal 4: mga filesystem check na maaari mong patakbuhin habang naka-mount

Nagtatago ang ext4 ng error counter sa superblock, at nananatili ito kahit mag-reboot ang system, kahit mawala na ang mga log.

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

Ang healthy na filesystem ay nagpi-print ng Filesystem state: clean at FS Error count: 0. Ang clean with errors at count na hindi zero ay nangangahulugang may metadata error na natukoy ang kernel, kahit walang nakapansin at na-roll over na ang log. Dapat kasama ang command na ito sa weekly check.

Hindi mo maaaring patakbuhin ang fsck sa naka-mount na root filesystem, at ang e2fsck -n sa live filesystem ay nag-uulat ng mga problemang dulot lamang ng patuloy na pagbabago ng data. Para pilitin ang aktuwal na check, idagdag ang fsck.mode=force fsck.repair=yes sa kernel command line para sa isang boot mula sa console ng provider. Pagkatapos, pinapatakbo ng systemd-fsck ang check bago i-mount ang root bilang read-write.

Walang online check ang XFS. Tumanggi ang xfs_repair -n /dev/vda1 na tumakbo laban sa naka-mount na filesystem, kaya dapat itong gamitin sa rescue mode. Binabawi ito ng XFS sa pamamagitan ng malinaw na pag-aksyon: isinasara nito ang filesystem kapag may metadata error, sa halip na ipagpatuloy ang operasyon.

May built-in at persistent na mga counter ang Btrfs.

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

Ang write_io_errs o corruption_errs na higit sa zero ay totoong event, at pinananatili ng mga counter ang kanilang mga value sa mga reboot hanggang i-reset mo ang mga ito. Muling binabasa ng scrub ang bawat block at bini-verify ang checksum nito. Ito ang pinakamalapit sa media test na available sa isang virtual disk. Mabigat ito sa I/O, kaya i-schedule ito sa oras na kaunti ang aktibidad.

Signal 5: libreng space, kasama ang mga bahaging hindi ipinapakita ng df

Ang pagkaubos ng space ay nakakasira ng server tulad ng sirang disk, at mas madalas itong mangyari.

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

No space left on device habang ipinapakita ng df -h ang libreng space ay nangangahulugang naubusan ka ng inodes, hindi bytes, at ipinapakita ng df -i na nasa 100 percent ang IUse%. Nagdudulot nito ang milyun-milyong maliliit na file sa cache directory o mail spool, at hindi makakatulong ang pagbura ng malalaking file.

Ang space na hindi bumabalik matapos mag-delete ay karaniwang nagmumula sa deleted file na hawak pa rin ng isang tumatakbong process. Inililista ng sudo lsof +L1 ang mga file na umabot na sa zero ang link count. Kapag ni-restart ang process na may hawak nito, mare-release ang space.

Karaniwang tahimik na kumokonsumo ng space ang journal. Iniuulat ng journalctl --disk-usage kung gaano karami ang hawak nito. Limitahan ito gamit ang SystemMaxUse=200M sa /etc/systemd/journald.conf, na sinusundan ng sudo systemctl restart systemd-journald, at bawiin agad ang space gamit ang sudo journalctl --vacuum-size=200M.

May isang sitwasyong mukhang bug pero hindi. Sa thin provisioned host storage, maaaring mapuno ang pool ng host habang ipinapakita pa rin ng iyong df na may libreng gigabytes. Mabibigo ang mga write mo na may I/O errors sa kernel log, at walang space warning saanman sa loob ng guest. Ang mga error kahit hindi puno ang filesystem ay isang kombinasyong dapat i-ticket sa loob ng parehong oras.

Pagkonekta ng mga signal sa metrics agent

Ang push probe ay sumasagot ng oo o hindi. Kailangan ng metrics agent para makita ang mga trend, at ine-export na ng Prometheus node_exporter ang lahat ng nasa itaas nang walang karagdagang configuration. Ito ang mga metric name na gagamitin:

• Kapag naging 1 ang node_filesystem_readonly, read-only ang mount. Ito ang alarm para sa remount.
• Sinasaklaw ng node_filesystem_avail_bytes at node_filesystem_files_free nang magkahiwalay ang bytes at inodes.
• Ibinibigay ng node_disk_io_time_seconds_total at node_disk_read_time_seconds_total ang busy time at latency bilang mga counter na maaaring i-graph.

Dalawang rule ang tumutukoy sa mga sitwasyong aktuwal na nagti-trigger ng 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

Nati-trigger ang pangalawang rule kapag aabot sa zero ang kasalukuyang trend sa loob ng apat na araw. Sa ganitong paraan, makakatanggap ka ng babala ilang araw bago ito mangyari, sa halip na kapag 95 percent nang puno ang storage at ilang minuto na lang ang natitira.

Sino ang responsable sa ano

Pagmamay-ari ng provider ang mga physical drive. Sila ang nagbabasa ng SMART, nagpapatakbo ng array, at nagpapalit ng drive na dumarami ang reallocated sector, karaniwan nang hindi ka sinasabihan, dahil sinasalo ng array ang failure. Iyan ang gamit ng RAID 10 sa ilalim ng iyong VPS: ang nasirang drive ay nagiging rebuild sa halip na outage. Wala kang nakikitang anuman dito, at malaking bahagi ng dahilan ng pagbabayad para sa abstraction na ito ang pagrenta ng virtual server.

Ikaw ang may-ari ng iyong data, at hindi ka rin mapoprotektahan ng drive telemetry. Ang mga pangyayaring aktuwal na sumisira sa data ng tenant ay isang maling rm, isang maling deploy, isang intruder na may SSH key mo, at isang platform incident na sumasama sa array. Wala sa mga iyon ang kayang hulaan ng SMART attributes.

Kaya ang tunay na proteksiyon ng tenant ay backup na nasa labas ng server at restore na ikaw mismo ang nagsagawa. Maginhawa ang provider snapshots, at nasa kaparehong platform ang mga ito kung nasaan ang pinoprotektahan nila. Ito ang dahilan kung bakit magkaibang proteksiyon ang snapshots at backups. Magtakda ng drill sa calendar: isang beses bawat quarter, i-restore ang pinakabagong backup sa isang bagong VPS, simulan ang application, at itala kung gaano katagal ito. Ang numerong iyon ang aktuwal mong recovery time. Palaging mas mabagal ang unang drill kaysa sa inaasahan ng lahat.

Kailan naaangkop sa iyo ang SMART

Tama ang mga gabay na nagtuturo ng smartctl, at naaangkop ang mga ito kapag tunay na sa iyo ang hardware:

• Dedicated o bare metal server, kung saan ibinabalik ng sudo smartctl -a /dev/sda ang buong attribute table at maaaring magpadala sa iyo ng email ang smartd kapag may nagbago sa isang attribute.
• Mga storage plan na direktang nagpa-pass through ng physical disk sa guest. Malinaw itong idinodokumento ng mga provider dahil selling point ito.
• Hardware na pagmamay-ari mo, nasa bahay man o nasa rack space na inuupahan mo.
• Disk na nasa likod ng RAID controller at naa-access gamit ang sudo smartctl -a -d megaraid,0 /dev/sda, o USB enclosure na may -d sat.

Sa aktuwal na NVMe, iniuulat ng sudo smartctl -a -d nvme /dev/nvme0 at sudo nvme smart-log /dev/nvme0n1 ang critical_warning at percentage_used mula mismo sa drive. Sa aktuwal na SATA, ang mga attribute na nagsasaad ng posibleng failure ay Reallocated_Sector_Ct (5), Current_Pending_Sector (197), Offline_Uncorrectable (198), at Reported_Uncorrect (187). Kapag lumampas sa zero ang alinman sa mga ito, magplano ng replacement. Paulit-ulit na lumalabas ang parehong maikling listahang ito sa malalaking pag-aaral ng mga drive, at karaniwang noise lamang ang karamihan sa ibang attribute.

Patakbuhin ang daemon sa halip na magsuri nang mano-mano.

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

Dapat ipakita ng self-test log ang Completed without error para sa run na kasisimula mo lang. Ipinapadala ng Ubuntu at Debian ang /etc/smartd.conf na may linyang DEVICESCAN, na kasalukuyang tama noong August 2026, kaya awtomatikong nakukuha ng daemon ang bawat disk na nakikita nito at nagpapadala ng email sa root kapag may pagbabago. Walang gumagana sa mga ito sa virtual disk, kaya umiiral ang natitirang bahagi ng gabay na ito.

FAQ

Bakit hindi gumagana ang smartctl sa aking VPS?

Dahil virtual ang disk. Sa KVM guest na gumagamit ng virtio-blk, nagpi-print ang smartctl -a /dev/vda ng /dev/vda: Unable to detect device type, dahil walang ATA o SCSI command channel ang paravirtual disk na mapaglalagyan ng SMART request. Sa emulated disk, naaabot mo ang device na ang model ay QEMU HARDDISK, at wala itong usable na SMART data. Sa loob ng container, tahasang tinatanggihan ang smartctl dahil walang CAP_SYS_RAWIO. Hindi misconfiguration ang alinman sa mga ito, at walang -d flag na makapaglulutas sa mga ito.

Paano ko malalaman kung pumapalya ang disk ng aking VPS?

Bantayan ang mga epekto, hindi ang hardware. Suriin ang sudo journalctl -k -p err -b para sa mga linyang blk_update_request: I/O error at para sa Remounting filesystem read-only. Patakbuhin ang sudo dumpe2fs -h /dev/vda1 | grep -i 'error count' upang mahanap ang mga error na nawala na sa logs. Subaybayan ang r_await mula sa iostat -xdz 5 at ihambing ito sa baseline na naitala mo noong maayos ang system. Sa VPS, karaniwang nangangahulugan ang I/O error ng problema sa storage ng host, hindi ng sirang drive, kaya dapat itong ilagay sa support ticket kasama ang timestamp at sector.

Para saan ako dapat mag-set ng alert para sa kalusugan ng disk ng VPS?

Apat na alert ang sapat. Isang read-only mount mula sa node_filesystem_readonly == 1 o isang write probe na pumapalya. Free space at free inodes na papalapit sa zero. Anumang kernel I/O error sa nakaraang interval. Isang heartbeat mula sa server, upang mag-page ang monitoring system kapag hindi na sumasagot ang machine. Huwag gumamit ng anumang galing sa SMART, dahil sa virtual disk, maaaring walang laman ang mga value na ito o inilalarawan lamang nila ang emulation ng hypervisor.

Bakit na-remount bilang read-only ang aking filesystem?

Sinasadya ito ng ext4 kapag naka-mount gamit ang errors=remount-ro at nakatagpo ito ng metadata error: itinitigil nito ang pagsusulat sa halip na ipagpatuloy ang operasyon sa ibabaw ng damage. Makikita ang trigger sa kernel log kaagad bago ang remount line, karaniwang isang EXT4-fs error tungkol sa na-abort na journal matapos magbalik ang underlying device ng I/O error. Kung ire-remount ito bilang read-write nang hindi sinusuri ang filesystem, maitatago lamang ang sintomas at mananatili ang sanhi. I-save ang log, pagkatapos ay suriin ang filesystem habang unmounted mula sa rescue mode gamit ang e2fsck -fy /dev/vda1.

Maaari ba akong makabasa ng SMART data sa virtual server?

Sa ilang partikular na sitwasyon, oo. Nagbibigay ang dedicated at bare metal server ng mga totoong attribute. Ganito rin ang mga storage plan na direktang nagpapasa ng physical disk sa guest, pati ang anumang host na ikaw mismo ang nagmamay-ari. May ilang platform na nagpe-present ng NVMe controller sa guest at nagbabalik ng log ang nvme smart-log, kaya patakbuhin muna ang sudo nvme id-ctrl /dev/nvme0: kung ang model number ay tumutukoy sa isang network storage service, nangangahulugan itong mula sa software controller ang mga counter na iyon. At kung may passthrough node na naglalantad ng totoong counter sa isang shared machine, inilalarawan ng mga ito ang hardware na ginagamit din ng ibang tenant, kaya support ticket lamang ang kapaki-pakinabang na aksyon.