Storage controllers

Virtio block device context

A protocol/device-family context for virtio block storage in a guest. It deliberately has no exact PCI identity: virtio can use different transports and does not identify the host’s physical SSD or RAID controller.

On this page
  1. Overview & identity
  2. Driver & binding
  3. Firmware
  4. Read-only diagnostics
  5. Limitations & related issues
  6. References

Overview & identity

The virtio block driver matches VIRTIO_ID_BLOCK on the virtio bus. A guest-visible vd device is a virtual block interface whose backing storage may be a host file, logical volume or another storage system.

This is an explicit class, transport or driver-context profile. It is not an exact numeric product match.

A numeric match establishes a candidate family within the reviewed evidence. Marketing names, board variants, subsystem conditions and successful operation remain separate questions.

Driver & binding

virtio_blk is the block driver; a PCI virtio transport is a separate layer. A virtio_pci module alone does not prove that a particular device is block storage or that the guest has the correct block driver.

  • virtio_blk — kernel driver/module candidate

Detected, bound, operational: learn the difference

Firmware

No host payload established here

No guest-loaded controller firmware file is established for this virtual block protocol. Host physical-device firmware is outside the guest’s virtio identity and cannot be inferred from this profile.

Inspect firmware packaging on your distribution

Read-only diagnostics

Run one displayed command at a time. Replace uppercase placeholders with the affected device, interface or module from your own output. Commands are never executed here. Read-only output can still contain private identifiers.

Inspect visible block-device identities

lsblk -d -o NAME,MODEL,TRAN,HCTL

MODEL describes a block device or a controller-presented logical volume; it is not a PCI-controller identity. HCTL helps distinguish SCSI targets. TRAN can be absent, and this list does not establish the complete physical disk topology.

Read controller and transport messages

sudo journalctl -k -b --no-pager

Elevated access may be needed. Root reads the current boot kernel journal. Associate virtio_blk messages, port/host identifiers and timeout/reset timestamps with the actual controller. A reset message alone does not prove a bad disk or a firmware defect.

Inspect guest module presence

lsmod

Look for virtio_blk and a transport such as virtio_pci. Presence does not prove binding to a particular disk, and a built-in driver is absent from lsmod; use sysfs if that distinction matters.

Limitations & related issues

The guest cannot deduce host cable errors, SSD firmware or array member health from a virtio block ID. Guest I/O delays can originate in scheduling, quotas or the backing storage and need host evidence.

These guides are linked for relevant observations, not as known defects of every device in this family.

Choose a hardware diagnostic workflow · Inspect a log excerpt in Fix Lab

References

Source review records a checked implementation or document, not a reproduced hardware test. Version-specific tables do not establish a minimum kernel or guaranteed operation.