SMART blind spots: VMs, USB bridges, and drives you think you're watching

SMART monitoring is deployed, the dashboard is green, but some drives are invisible to smartctl. No alert fired. The pattern: expected physical drive count exceeds drives returning SMART data. The drives may be healthy or failing. You cannot tell because no telemetry is collected, and the monitoring system treats “smartctl returned no data” as “no problem.”

Four configurations create this gap: virtual machines, USB-attached drives, cloud block devices, and hardware RAID controllers. In each case, smartctl cannot reach the physical drive’s firmware. The fix is to move monitoring to where SMART data is accessible and use the correct device-type flags.

What a SMART blind spot is

This is a TICKET-level instrumentation gap, not a drive failure. No individual drive has necessarily failed. But drives can fail silently inside the blind spot, and you will not know until the filesystem reports I/O errors or the application loses data.

Detection requires two inputs: an inventory of expected physical drives per host (from the hardware manifest, RAID controller enumeration, lsscsi, lspci, or lsblk), and the set of drives where smartctl successfully returns SMART data. Any expected drive absent from the successful set is a blind spot.

The trap: most monitoring tools report absence of data as absence of problems. The dashboard stays green. No alert fires. A drive could accumulate hundreds of reallocated sectors while the monitoring system shows nothing wrong because it never collected data from that drive.

flowchart TD
    A[SMART data missing for a physical drive] --> B{How is the drive connected?}
    B -->|Inside a VM| C[Monitor on the hypervisor host]
    B -->|USB enclosure| D[Try -d sat, then vendor flags]
    B -->|Cloud block storage| E[No physical SMART to read]
    B -->|RAID controller| F[Use -d megaraid,N or cciss,N]

Virtual machines: the hypervisor wall

Hypervisors do not pass SMART commands to guest VMs. The VM sees a virtual disk (VMware Virtual disk, VBOX HARDDISK, Hyper-V virtual disk) that presents no SMART capability. Running smartctl -i inside the guest returns:

SMART support is: Unavailable - device lacks SMART capability.

The hypervisor presents a block device abstraction, not a physical drive. SMART commands operate below the virtualization layer and are not forwarded to the guest. Even when a physical disk is passed through via virtio or SCSI emulation, SMART commands may fail with “unsupported scsi opcode.” The virtualization layer translates block I/O but does not forward the ATA PASS-THROUGH or NVMe passthrough commands that smartctl relies on.

Run monitoring on the hypervisor host. For Proxmox, ESXi, or KVM, run smartctl on the host OS, not inside any guest. The hypervisor host has direct access to the physical SATA, SAS, or NVMe controllers.

PCIe controller passthrough is the only reliable VM-level option. Pass through the entire SATA or SAS controller to the guest via PCIe passthrough. The guest then talks directly to the hardware, and SMART commands reach the physical drives. Disk-level passthrough (passing individual drives via virtio or SCSI emulation) does not work for SMART.

USB bridges: the pass-through lottery

USB-to-SATA and USB-to-NVMe bridges are the most common source of SMART blind spots in backup servers and external storage. The bridge chip sits between the host and the drive, and not all bridges forward the ATA or NVMe commands that smartctl sends.

When smartctl cannot identify the USB bridge, it prints:

/dev/sdX: Unknown USB bridge [0xVENDOR:0xPRODUCT (0xREV)]

The bridge’s USB vendor/product ID pair is not in smartmontools’ drivedb.h database. The default auto-detection (-d auto) only works for USB IDs already catalogued there.

SATA drives behind USB

Try these device-type flags in order:

The -d sat,auto variant only uses SAT if the SCSI INQUIRY data reports a SATL (the vendor string is “ATA”). Otherwise it falls back to the SCSI device type. This can help avoid false matches on bridges that partially implement SAT.

NVMe drives behind USB

NVMe drives behind USB bridges require completely different flags. The -d sat flag does not work for NVMe and returns “unsupported scsi opcode.” The correct device type depends on the bridge chipset:

For dual-protocol enclosures that support both NVMe and SATA, smartctl 7.5 introduced combined flags like -d sntjmicron/sat and -d sntasmedia/sat. If the NVMe Identify command fails, the device type falls back to -d sat. This is useful when you are not sure whether the enclosure holds an NVMe or SATA drive.

Updating the drive database

If your bridge is unknown, run update-smart-drivedb to fetch the latest drivedb.h from the smartmontools repository. Newly added bridge IDs may be recognized without upgrading smartmontools itself. This is the first thing to try when you see “Unknown USB bridge” on a chipset that should be supported.

When nothing works

Some older bridge chips do not support SMART pass-through at all. No -d flag will help. The only option is to replace the enclosure with one that uses a known-compatible bridge, or connect the drive directly via SATA or SAS.

Cloud block devices: virtualized by design

AWS EBS, GCP Persistent Disk, and Azure Managed Disks are virtualized block devices. They do not expose physical drive SMART data because there is no single physical drive to report against. Running smartctl against these devices returns nothing meaningful or fails silently.

If your workload runs on cloud block storage, you cannot monitor disk health with SMART. Rely on the cloud provider’s volume health metrics, I/O error rates from the instance OS, and your application’s own error handling.

Exception: instance-store NVMe. AWS documents NVMe SSD instance store volumes on some instance types. They may expose standard SMART/Health data when the instance OS can issue NVMe admin commands; verify each instance type and AMI with smartctl -a /dev/nvme0n1. If it succeeds, monitor fields such as Available Spare, Percentage Used, and Media and Data Integrity Errors.

Hardware RAID controllers: the abstraction layer

RAID controllers (LSI/Broadcom MegaRAID, HP Smart Array, Adaptec) present a virtual SCSI device to the OS. Standard smartctl /dev/sda queries this virtual device, not the individual physical drives behind the controller. SMART is either unavailable or returns controller-level data that masks per-drive health.

Use controller-specific passthrough (requires root):

# MegaRAID / LSI / Broadcom: access physical drive N
smartctl -a -d megaraid,0 /dev/sda
smartctl -a -d megaraid,1 /dev/sda

# HP Smart Array (cciss-based)
smartctl -a -d cciss,0 /dev/sda

# SAT passthrough through MegaRAID for SATA drives behind the controller
smartctl -a -d sat+megaraid,0 /dev/sda

The number N is the physical drive slot as enumerated by the controller. Find the mapping with the controller’s management utility (storcli, megacli, or ssacli).

Even with correct passthrough flags, some controllers filter or cache SMART data. Results may be stale or incomplete compared to direct SATA or SAS access. Cross-check with the controller’s own health reporting, which tracks drive status, rebuild progress, and predictive failure at the controller level.

Detecting blind spots at fleet scale

1. Build a hardware inventory. Enumerate every expected physical drive per host using lsscsi, lspci (for NVMe), lsblk, or the RAID controller’s drive enumeration.
2. Query each expected device. Run smartctl with the correct -d flag for every drive, including RAID controller passthrough where needed.
3. Compare counts. Expected drive count vs. drives returning valid SMART data. Any gap is a blind spot.
4. Track changes over time. A new blind spot after infrastructure changes (new RAID controller, VM migration, enclosure swap) means the monitoring configuration needs updating.

# Enumerate block devices and their transport
lsblk -d -o NAME,TYPE,MODEL,TRAN

# First-pass SMART accessibility check for direct-attached devices.
# Does NOT detect drives behind RAID controllers; those need -d megaraid,N etc.
# Requires root. Globs match up to 26 SATA/SAS and 10 NVMe controllers.
for dev in /dev/sd? /dev/nvme?n?; do
    if [ -b "$dev" ]; then
        echo "=== $dev ==="
        sudo smartctl -i "$dev" 2>&1 | grep -iE "SMART support|Device Model|Product|Unavailable|Unknown USB"
    fi
done

Common blind spot triggers after infrastructure changes:

• New RAID controller installed. Existing smartctl configurations stop returning data unless updated with -d megaraid,N or equivalent. The controller presents virtual devices that respond to basic queries but return no per-drive SMART.
• Migration from bare metal to VM. SMART monitoring that worked on the physical host returns empty data inside the guest. The hypervisor wall blocks all SMART commands.
• New USB enclosures deployed. Different bridge chips require different -d flags. A configuration that worked with the previous enclosure may silently fail with the new one.

A monitoring system that silently collects no data for a drive is worse than no monitoring at all, because it creates a false sense of coverage. The dashboard says everything is fine, but only because it has no data to say otherwise.

How Netdata helps

• Device presence tracking. Netdata’s SMART collector runs smartctl on a schedule and tracks which devices return valid data. A device that previously reported and stops responding is visible as a gap.
• Telemetry blind spot detection. The SMART Telemetry Blind Spot signal compares expected physical drive count against successfully monitored drives. When the monitored count drops below expected, Netdata raises a TICKET-level alert flagging the instrumentation gap before it masks a real failure.
• Host-level I/O correlation. When a drive is in a blind spot, Netdata still collects host-level I/O metrics from the kernel. Latency spikes, I/O errors in dmesg, and queue depth changes may surface the problem even when SMART data is unavailable.
• Per-device flag configuration. Netdata’s collector supports custom smartctl arguments per device, so drives behind RAID controllers or USB bridges can be queried with the correct -d passthrough flag.
• Hypervisor host deployment. Netdata runs on the host OS. When installed on the hypervisor host (Proxmox, ESXi, KVM), it has direct access to physical drive SMART data, bypassing the VM blind spot entirely.

Related guides

• Reading the ATA error log: UNC, ICRC, ABRT, CCTO, IDNF, AMNF
• Command_Timeout climbing: the drive is taking too long to respond
• Warning and Critical Composite Temperature Time: past overheating that already did damage
• Current_Pending_Sector non-zero: unreadable sectors and I/O latency spikes
• Data Units Written vs rated TBW: computing SSD endurance runway
• Drive disappeared from the bus: sudden controller or electronics death
• Drive temperature too high: HDD, SATA SSD, and NVMe thresholds
• G-Sense_Error_Rate rising: shock and vibration reaching the drive
• SMART says PASSED but the drive is failing: why the health check lies
• I/O errors in dmesg with clean SMART: the failure the drive can’t see
• How S.M.A.R.T. actually works: a mental model for operators
• smartctl disk monitoring checklist: the SMART signals every server needs