Dennis HilkLinux-DiagnoseEN

Speichercontroller

Kontext für virtio-Blockgeräte

Ein Protokoll-/Gerätefamilienkontext für virtio-Blockspeicher in einem Gast. Bewusst ohne genaue PCI-Identität: virtio kann unterschiedliche Transporte verwenden und identifiziert weder die physische Host-SSD noch dessen RAID-Controller.

Redaktionelle Quellenprüfung: Öffentliches Profil teilenIm Erkennungswerkzeug öffnen
Auf dieser Seite
  1. Überblick und Identität
  2. Treiber und Bindung
  3. Firmware
  4. Lesende Diagnose
  5. Grenzen und passende Fehlerhilfen
  6. Quellen

Überblick und Identität

Der virtio-Blocktreiber gleicht VIRTIO_ID_BLOCK auf dem virtio-Bus ab. Ein vd-Gerät im Gast ist eine virtuelle Blockschnittstelle; dahinter können Hostdatei, logischer Datenträger oder ein anderes Speichersystem liegen.

Dies ist ausdrücklich ein Klassen-, Transport- oder Treiberkontextprofil. Es identifiziert kein exaktes numerisches Produkt.

Ein numerischer Match belegt eine Kandidatenfamilie im geprüften Quellenrahmen. Verkaufsnamen, Platinenvarianten, Subsystembedingungen und erfolgreiche Funktion bleiben getrennte Fragen.

Treiber und Bindung

virtio_blk ist der Blocktreiber; ein PCI-virtio-Transport ist eine getrennte Schicht. virtio_pci allein beweist weder ein Blockgerät noch den passenden Blocktreiber im Gast.

  • virtio_blk — Kernel-Treiber-/Modulkandidat

Erkannt, gebunden, funktionsfähig: Unterschiede verstehen

Firmware

Hier keine Host-Datei belegt

Für dieses virtuelle Blockprotokoll wird keine vom Gast geladene Controllerfirmwaredatei belegt. Die Firmware physischer Hostgeräte liegt außerhalb der virtio-Identität des Gasts und folgt nicht aus diesem Profil.

Firmwarepakete deiner Distribution prüfen

Lesende Diagnose

Führe jeden angezeigten Befehl einzeln aus. Ersetze Großbuchstaben-Platzhalter durch betroffenes Gerät, Schnittstelle oder Modul aus deiner Ausgabe. Hier wird nichts ausgeführt. Auch lesende Ausgaben können private Kennungen enthalten.

Sichtbare Blockgeräte identifizieren

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

MODEL beschreibt ein Blockgerät oder ein vom Controller präsentierter logischer Datenträger; es ist keine PCI-Controlleridentität. HCTL unterscheidet SCSI-Ziele. TRAN kann fehlen; die Liste beweist keine vollständige physische Datenträgertopologie.

Controller- und Transportmeldungen lesen

sudo journalctl -k -b --no-pager

Erhöhte Rechte können nötig sein. Root liest das Kerneljournal des aktuellen Starts. Meldungen von virtio_blk, Port-/Hostkennungen und Zeitpunkte von Timeouts/Resets dem tatsächlichen Controller zuordnen. Ein Reset allein beweist keinen defekten Datenträger oder Firmwarefehler.

Vorhandene Gastmodule ansehen

lsmod

Auf virtio_blk und einen Transport wie virtio_pci achten. Vorhandensein beweist keine Bindung an ein bestimmtes Laufwerk; fest eingebaute Treiber fehlen in lsmod. Falls relevant, über sysfs unterscheiden.

Grenzen und passende Fehlerhilfen

Der Gast kann aus einer virtio-Blockkennung keine Host-Kabelfehler, SSD-Firmware oder Arraymitgliedszustände ableiten. Gast-I/O-Verzögerungen können aus Planung, Grenzen oder Hintergrundspeicher stammen und benötigen Hostbelege.

Diese Anleitungen passen zu relevanten Befunden und behaupten keinen Fehler bei jedem Gerät dieser Familie.

Hardware-Diagnoseweg wählen · Log-Auszug im Fix Lab prüfen

Quellen

Eine Quellenprüfung hält geprüfte Implementierung oder Dokumentation fest, keinen reproduzierten Hardwaretest. Versionsbezogene Tabellen belegen weder Mindestkernel noch garantierte Funktion.