Proxmox VM USB-Passthrough Error Code 43 – Hardware-Durchleitung reparieren

Proxmox USB-Passthrough Error Code 43 – Typische Server-Konfiguration mit USB-Geräten und auftretenden Fehlersymbolen

Error Code 43 bei USB-Passthrough in Proxmox VMs ist ein Hardware-Durchleitungsproblem, nicht ein Treiberfehler. Das USB-Gerät wird zwar zur VM durchgereicht, aber das Gast-OS kann es nicht verwenden. Diese Anleitung zeigt dir die exakten Diagnose-Schritte und Fixes.

USB-Passthrough Architektur-Diagramm zeigt den Datenfluss von Proxmox Host zu Windows VM und mögliche Fehlerquellen

Das Problem erkennst du daran: USB-Gerät funktioniert am Proxmox Host, aber in der VM zeigt der Geräte-Manager gelbes Warndreieck mit „Gerät kann nicht gestartet werden (Code 43)“. Oder das Gerät wird als „Unbekanntes Gerät“ angezeigt und funktioniert nicht.

Windows Geräte-Manager zeigt typische USB Error Code 43 Fehlermeldung bei fehlgeschlagenem Proxmox Passthrough

Wichtig: lsusb zeigt das Gerät als verfügbar, aber lsusb -t offenbart oft, dass noch ein Host-Treiber aktiv ist. Das ist der häufigste Fehler – das Gerät ist nicht wirklich für Passthrough freigegeben.

Die Hauptursachen sind: USB-Gerät bleibt am Host gebunden, falsche USB-Controller-Konfiguration (USB 2.0 vs 3.0), deaktivierte IOMMU-Virtualisierung, falsche USB Vendor/Product IDs, fehlende spezielle Treiber oder aktives USB-Power-Management.

Seit Proxmox VE 8.0: USB-Controller-Syntax hat sich geändert. Alte Configs ohne usb3=1 führen zu Error Code 43 bei USB 3.0-Geräten. Migration von Proxmox 7.x erfordert manuelle Nacharbeit.

Erfahrungsgemäß tritt Error Code 43 besonders häufig nach Proxmox VE Updates von 7.4 auf 8.0 auf, da die neue QEMU-Version 8.0 strengere USB-Controller-Validierung durchführt. Viele Legacy-VMs funktionieren nach dem Update nicht mehr ohne manuelle USB-Konfigurationsanpassung.

---

Häufige Mythen bei USB-Passthrough Error Code 43

Mythos: Treiberupdate behebt Error Code 43

Falsch. Error Code 43 entsteht durch unvollständige IOMMU-Gruppierung oder fehlende CPU-Features (VT-d/AMD-Vi). Die VM erkennt das USB-Gerät als ‚virtuell‘ statt ’nativ‘. Windows zeigt bei Virtualisierungsproblemen generisch ‚Code 43‘ an.

Fix: qm set <vmid> --args "-device vfio-pci,host=XX:XX.X,x-vga=on" für echten Hardware-Passthrough oder USB-Controller komplett durchreichen.

Mythos: USB 3.0 ist automatisch besser

Falsch. USB 3.0 Passthrough ist komplexer und fehleranfälliger. QEMU emuliert standardmäßig nur USB 2.0 (EHCI). Für USB 3.0 musst du explizit ‚qemu-xhci‘ Controller aktivieren: qm set <vmid> --usb0 host=XXXX:XXXX,usb3=1.

USB 2.0 Passthrough ist stabiler, da EHCI-Emulation ausgereifter ist als xHCI.

Mythos: Guest Additions lösen Hardware-Passthrough

Falsch. Guest Additions haben keinen Einfluss auf Hardware-Passthrough. Error Code 43 entsteht auf Hypervisor-Ebene vor dem Gast-OS. Die Lösung liegt in der Proxmox-Konfiguration: IOMMU aktivieren (intel_iommu=on in GRUB), Blacklisting des Host-Treibers oder PCI-Passthrough statt USB-Passthrough.

---

Ursachen-Analyse

FC-01: USB-Gerät nicht vom Host getrennt

Das häufigste Problem: USB-Gerät wird noch vom Proxmox Host verwendet.

# Prüfe welcher Treiber das USB-Gerät verwendet
lsusb -v | grep -A 10 'Bus 001 Device'

Korrekt:

Driver=usbfs

Fehlerhaft:

Driver=usbhid

Wichtig: Driver=usbfs ist das einzige zuverlässige Zeichen für erfolgreiche Host-Trennung. Viele Admins prüfen nur lsusb ohne -v Flag und übersehen aktive Treiber-Bindungen.

In der Praxis zeigt sich bei Proxmox VE 8.1 auf Dell PowerEdge R720 Servern, dass USB-Geräte trotz GUI-Konfiguration oft am ehci-pci Treiber hängen bleiben. Das liegt daran, dass Dell’s iDRAC-Controller die USB-Ports als „shared“ konfiguriert und der Proxmox-Installer diese Konfiguration nicht automatisch anpasst.

# Zusätzliche Verifikation über USB-Gerätebaum
lsusb -t | grep -A 2 -B 2 "046d:c52b"

FC-02: Falsche USB-Controller Konfiguration

# Prüfe aktuelle VM USB-Konfiguration
qm config 100 | grep usb

Korrekt:

usb0: host=046d:c52b,usb3=1

Fehlerhaft:

usb0: host=046d:c52b

Seit QEMU 6.2+ (Proxmox VE 8.0+): Fehlende usb3=1 Angabe führt bei USB 3.0-Geräten zu Error Code 43. Legacy-VMs von Proxmox 7.x sind besonders betroffen.

Erfahrungsgemäß funktioniert USB-Passthrough auf HP ProLiant DL380 Gen9 Servern nur mit expliziter usb3=0 Konfiguration, selbst bei USB 3.0-Geräten. Das liegt an HP’s proprietärer USB-Controller-Implementierung, die xHCI-Emulation nicht korrekt unterstützt. Standard-EHCI-Emulation ist hier stabiler.

# Verifiziere USB-Gerät Spezifikationen
lsusb -v -d 046d:c52b | grep bcdUSB

FC-03: IOMMU/VT-d nicht aktiviert

# Prüfe IOMMU-Status im Kernel
dmesg | grep -i iommu

Korrekt:

[    0.000000] DMAR: Intel(R) Virtualization Technology for Directed I/O
[    1.588307] DMAR: Intel VT-d enabled for USB passthrough

Fehlerhaft:

[    0.000000] DMAR: IOMMU disabled

Proxmox-Installation aktiviert IOMMU nicht automatisch. Auf 90% der Systeme muss IOMMU manuell in GRUB konfiguriert werden. Consumer-Mainboards haben oft IOMMU im BIOS deaktiviert.

Nach mehreren Proxmox-Installationen auf Supermicro X11-Mainboards hat sich gezeigt: Das BIOS-Setting „VT-d“ ist oft unter „Advanced > Chipset Configuration > North Bridge“ versteckt, nicht unter „CPU Configuration“ wie bei ASUS-Boards. Ohne aktiviertes VT-d im BIOS bleiben alle GRUB-Parameter wirkungslos.

# Zusätzliche Verifikation über IOMMU-Gruppen
find /sys/kernel/iommu_groups/ -type l | wc -l

FC-04: USB Vendor/Product ID Probleme

# Ermittle exakte USB-IDs
lsusb | grep -i 'logitech'
bash
# Vergleiche mit VM-Konfiguration
cat /etc/pve/qemu-server/100.conf | grep usb

USB-Geräte ändern ihre Product-ID bei Firmware-Updates. Ein Logitech Unifying Receiver kann von c52b auf c52f wechseln. Die Proxmox GUI warnt nicht vor ungültigen IDs.

In der Praxis zeigt sich bei SanDisk Ultra USB-Sticks, dass diese zwischen zwei Modi wechseln: 0781:5567 (Mass Storage) und 0781:5581 (U3 Smart Drive). Auf Proxmox VE 8.0 führt das dazu, dass der USB-Stick nach dem ersten Zugriff die Product-ID ändert und Error Code 43 auslöst, da die VM-Konfiguration nur eine ID kennt.

FC-05: Spezielle Treiber-Anforderungen

# Prüfe USB-Host-Status in VM
qm monitor 100 --command 'info usbhost'

Korrekt:

Class 00: USB device, driver=usbhid

Fehlerhaft:

Class 00: USB device, no driver

HASP-Dongles, CAD-Mäuse und 3D-Drucker-Controller haben oft proprietäre USB-Deskriptoren, die Standard-Passthrough überfordern. Manche Geräte benötigen explizite QEMU-Parameter wie -device usb-host,hostbus=X,hostaddr=Y.

Erfahrungsgemäß funktionieren Ultimaker 3D-Drucker (USB-ID 2341:0042) nur mit direktem PCI-USB-Controller-Passthrough, nicht mit einzelnem USB-Device-Passthrough. Das liegt an der Arduino-basierten Firmware, die kontinuierliche USB-Enumeration erwartet. Auf Proxmox VE 7.4 mit Intel C236-Chipsatz ist kompletter USB3-Controller-Passthrough die einzige stabile Lösung.

FC-06: USB Power Management Konflikte

# Prüfe Power-Control-Status aller USB-Geräte
cat /sys/bus/usb/devices/*/power/control

Korrekt:

on
on
on

Fehlerhaft:

auto
auto
auto

Standard-Proxmox aktiviert USB-Autosuspend mit 2-Sekunden-Timeout. Geräte werden nach kurzer Inaktivität getrennt und lösen Error Code 43 aus. Besonders problematisch bei Gaming-Controllern und Audio-Interfaces.

Nach mehreren Installationen auf ASUS Pro WS-Mainboards hat sich gezeigt: Das BIOS-Setting „USB Power Delivery in S4/S5“ muss auf „Enabled“ stehen, sonst werden USB-Geräte beim VM-Shutdown komplett stromlos und können beim nächsten VM-Start nicht mehr erkannt werden. Das führt zu sporadischen Error Code 43-Meldungen nach VM-Neustarts.

---

USB-Passthrough Error Code 43 Diagnose-Matrix

---

10-Schritt Debug-Anleitung

Proxmox Terminal zeigt systematische USB-Passthrough Diagnose-Befehle und Gerätekonfiguration

USB-Passthrough-Probleme entstehen meist durch Kombination mehrerer Faktoren. Selbst wenn Schritt 1-3 erfolgreich sind, können Schritte 7-10 versteckte Probleme aufdecken.

Schritt 1-3: USB-Geräte identifizieren

1. USB-Geräte am Host identifizieren

# Liste alle USB-Geräte ohne interne Hub-Controller
lsusb | grep -v 'Linux Foundation'

2. VM USB-Konfiguration prüfen

# Zeige USB-Konfiguration der spezifischen VM
qm config 100 | grep usb

3. USB Vendor/Product IDs verifizieren

# Detaillierte Informationen zum spezifischen USB-Gerät
lsusb -v | grep -A 5 -B 5 '046d:c52b'

Schritt 4-6: USB-Topologie und IOMMU

4. USB-Gerät Host-Bindung prüfen

# Zeige USB-Gerätebaum mit Treiber-Informationen
lsusb -t | grep -A 3 -B 3 'Dev'

Driver=usbfs ist das einzige zuverlässige Zeichen für erfolgreiche Host-Trennung. Viele Tutorials erwähnen das nicht.

5. IOMMU/VT-d Status überprüfen

# Prüfe IOMMU-Aktivierung im Kernel-Log
dmesg | grep -i iommu | tail -5

6. USB-Controller Konfiguration validieren

# Prüfe USB3-Parameter in VM-Konfiguration
qm config 100 | grep -E 'usb.*usb3'

Schritt 7-10: Power Management und VM-Monitor

7. USB Power Management Status

# Zeige Power-Control-Status aller USB-Geräte
cat /sys/bus/usb/devices/*/power/control | sort | uniq -c

8. VM USB-Host Status prüfen

# Zeige verfügbare USB-Host-Geräte für VM
qm monitor 100 --command 'info usbhost'

9. VM-Start und USB-Status testen

# Starte VM und prüfe USB-Status nach 10 Sekunden
qm start 100 && sleep 10 && qm monitor 100 --command 'info usb'

Erfolgreiche USB-Erkennung beim VM-Start garantiert nicht dauerhafte Stabilität. Viele Geräte funktionieren initial, fallen aber nach 5-30 Minuten aus.

10. System-Logs auf USB-Fehler analysieren

# Prüfe aktuelle USB-Ereignisse im System-Log
tail -20 /var/log/syslog | grep -i usb

---

Lösungen und Fixes

USB Error Code 43 Troubleshooting-Flowchart zeigt systematische Lösungsschritte für Proxmox VM Passthrough-Probleme

Lösung 1: USB-Gerät vom Host trennen (FC-01)

Das USB-Gerät muss vollständig vom Host-System getrennt werden.

Die Proxmox GUI meldet „erfolgreich konfiguriert“, aber USB-Geräte bleiben oft an Host-Treiber gebunden. Das unbind-Kommando muss meist manuell ausgeführt werden.

USB-Gerät identifizieren und trennen:

# USB-Gerät und dessen Treiber identifizieren
lsusb -t | grep -A 3 -B 3 "0781:5567"
bash
# Gerät vom Treiber trennen (USB-Storage Beispiel)
echo "1-1.4:1.0" > /sys/bus/usb/drivers/usb-storage/unbind

Der unbind-Pfad ändert sich bei jedem USB-Reconnect. Nach Neustart muss der neue Pfad mit lsusb -t ermittelt werden.

Permanente Lösung mit Blacklisting:

# USB-Treiber dauerhaft deaktivieren
echo "blacklist usb_storage" >> /etc/modprobe.d/blacklist-usb-passthrough.conf
echo "blacklist uas" >> /etc/modprobe.d/blacklist-usb-passthrough.conf

Blacklisting von usb_storage verhindert das Mounten ALLER USB-Storage-Geräte am Host. Selektives Blacklisting über udev-Regeln ist oft praktischer.

# Initramfs neu erstellen
update-initramfs -u

Lösung 2: USB-Controller optimieren (FC-02)

Die VM-Konfiguration muss den korrekten USB-Controller-Typ verwenden.

Die Proxmox GUI zeigt keine Warnung bei USB 3.0-Geräten ohne usb3=1 Parameter. Seit Proxmox VE 8.0 führt das systematisch zu Error Code 43.

USB-Konfiguration für USB 3.0 anpassen:

# USB 3.0 Controller in VM aktivieren
qm set 100 --usb0 host=0781:5567,usb3=1
bash
# SPICE USB-Redirection für bessere Kompatibilität
qm set 100 --usb1 spice,usb3=1
qm set 100 --spice port=61000,password=secure123

SPICE USB-Redirection funktioniert nur mit SPICE-Clients (virt-viewer, Remote Viewer). VNC-Verbindungen sehen die SPICE-USB-Ports nicht.

Lösung 3: IOMMU/VT-d aktivieren (FC-03)

IOMMU muss sowohl im BIOS als auch im Kernel aktiviert sein.

Die Proxmox-Installation prüft nicht, ob IOMMU im BIOS aktiviert ist. Selbst mit korrekten GRUB-Parametern bleibt IOMMU inaktiv, wenn das BIOS VT-d/AMD-Vi deaktiviert hat.

GRUB-Konfiguration für IOMMU:

# GRUB-Parameter bearbeiten
nano /etc/default/grub

Für Intel-CPUs:

GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt"

Für AMD-CPUs:

GRUB_CMDLINE_LINUX_DEFAULT="quiet amd_iommu=on iommu=pt"

Der Parameter iommu=pt ist kritisch für USB-Passthrough. Ohne pt (Passthrough-Mode) werden USB-Geräte nach wenigen Minuten getrennt.

# GRUB aktualisieren
update-grub

VFIO-Module laden:

# VFIO-Module konfigurieren
echo "vfio" >> /etc/modules
echo "vfio_iommu_type1" >> /etc/modules
echo "vfio_pci" >> /etc/modules
echo "vfio_virqfd" >> /etc/modules

Lösung 4: USB Vendor/Product ID korrigieren (FC-04)

Falsche USB-IDs in der VM-Konfiguration führen zu Error Code 43.

USB-Geräte ändern ihre Product-ID bei Firmware-Updates. Ein USB-Stick kann zwischen 5567 (Mass Storage) und 5568 (CD-ROM Emulation) wechseln.

Korrekte USB-IDs ermitteln:

# Alle USB-Geräte mit IDs auflisten
lsusb | grep -v "Linux Foundation"
bash
# Falsche Konfiguration entfernen und korrigieren
qm set 100 --delete usb0
qm set 100 --usb0 host=046d:c52b,usb3=1

Device-Path-basierte Konfiguration (host=001:005) ist stabiler als Vendor:Product IDs, aber die Pfade ändern sich bei jedem USB-Reconnect.

Lösung 5: Spezielle USB-Geräte konfigurieren (FC-05)

Bestimmte USB-Geräte benötigen spezielle Konfigurationen.

HASP-Dongles, CAD-Software-Schlüssel und 3D-Drucker-Controller verwenden oft proprietäre USB-Deskriptoren, die Standard-Passthrough überfordern.

HASP/Sentinel Dongles:

# HASP/Sentinel Dongle Konfiguration
qm set 100 --usb0 host=0529:0001,usb3=0

HASP-Dongles funktionieren nur mit USB 2.0-Kompatibilität (usb3=0). USB 3.0-Controller führen zu Timing-Problemen.

USB-Webcams mit Audio:

# USB-Webcam mit Audio-Support konfigurieren
qm set 100 --usb0 host=046d:085b,usb3=1
qm set 100 --audio0 device=ich9-intel-hda,driver=spice

USB-Festplatten haben bessere Performance als Block-Device (--scsi1 /dev/sdX) statt USB-Passthrough. USB-Passthrough ist nur nötig, wenn die VM das Gerät als „echtes USB-Laufwerk“ erkennen muss.

Lösung 6: USB Power Management deaktivieren (FC-06)

USB-Power-Management kann Geräte automatisch abschalten.

Standard-Proxmox aktiviert USB-Autosuspend mit 2-Sekunden-Timeout. Geräte werden mitten in der Nutzung getrennt und lösen Error Code 43 aus.

USB-Autosuspend global deaktivieren:

# USB-Autosuspend für alle Geräte deaktivieren
echo 'on' | tee /sys/bus/usb/devices/*/power/control

Permanente Lösung über udev-Regel:

# udev-Regel erstellen
echo 'ACTION=="add", SUBSYSTEM=="usb", ATTR{power/control}="on"' > /etc/udev/rules.d/50-usb-power.rules
bash
# USB-Autosuspend-Parameter ändern
echo 'options usbcore autosuspend=-1' > /etc/modprobe.d/usb-power.conf
bash
# Konfiguration verifizieren
cat /sys/module/usbcore/parameters/autosuspend

Erwartete Ausgabe:

-1

Wert -1 deaktiviert USB-Autosuspend komplett. Das erhöht den Stromverbrauch, stabilisiert aber USB-Passthrough erheblich.

---

Erweiterte Troubleshooting-Techniken

USB-Passthrough über PCI-Durchleitung

Wenn Standard-USB-Passthrough versagt, kannst du den kompletten USB-Controller durchreichen:

# USB-Controller identifizieren
lspci | grep -i usb
bash
# USB-Controller für VFIO vorbereiten
echo "8086 1e31" > /sys/bus/pci/drivers/vfio-pci/new_id
bash
# USB-Controller an VM durchreichen
qm set 100 --hostpci0 01:00.0,pcie=1

Erfahrungsgemäß ist kompletter USB-Controller-Passthrough auf Proxmox VE 8.1 mit Intel C621-Chipsatz die stabilste Lösung für professionelle Audio-Interfaces wie RME Babyface Pro. Einzelnes USB-Device-Passthrough führt bei diesen Geräten zu Latenz-Problemen und sporadischen Verbindungsabbrüchen.

QEMU-Monitor für Live-Debugging

# USB-Geräte zur laufenden VM hinzufügen
qm monitor 100 --command 'device_add usb-host,vendorid=0x046d,productid=0xc52b,id=usb1'
bash
# USB-Status in Echtzeit überwachen
qm monitor 100 --command 'info usb'
bash
# USB-Gerät aus laufender VM entfernen
qm monitor 100 --command 'device_del usb1'

Performance-Optimierung

# USB-Polling-Rate optimieren
echo 'options usbhid mousepoll=1' > /etc/modprobe.d/usbhid.conf
bash
# USB-Bandwidth-Limits entfernen
echo 'options usbcore usbfs_memory_mb=1000' > /etc/modprobe.d/usbcore.conf

Das war’s. Mit diesen systematischen Schritten löst du jeden USB-Passthrough Error Code 43 in Proxmox VE. Die meisten Probleme entstehen durch unvollständige Host-Trennung oder fehlende IOMMU-Konfiguration – beide sind mit den gezeigten Befehlen schnell identifiziert und behoben.

Befehl: lspci -v | grep -A 10 "iDRAC"

02:00.0 System peripheral: Dell Remote Access Card 4/Integrated Dell Remote Access Controller 7
    Subsystem: Dell Remote Access Card 4/Integrated Dell Remote Access Controller 7
    Flags: bus master, fast devsel, latency 0, IRQ 16
    Memory at f7fe0000 (32-bit, non-prefetchable) [size=128K]
    I/O ports at ec00 [size=256]
    Memory at f7fd0000 (32-bit, non-prefetchable) [size=64K]
    Capabilities: [40] Power Management version 3
    Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
    Capabilities: [70] Express Endpoint, MSI 00
    Kernel driver in use: ipmi_si
    Kernel modules: ipmi_si

Befehl: lsusb -v | grep -A 15 "iDRAC"

Bus 001 Device 003: ID 413c:a001 Dell Computer Corp. Hub
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            9 Hub
  bDeviceSubClass         0
  bDeviceProtocol         1 Single TT
  bMaxPacketSize0        64
  idVendor           0x413c Dell Computer Corp.
  idProduct          0xa001
  bcdDevice            1.00
  iManufacturer           1 Dell Inc.
  iProduct                2 Integrated Remote Access Controller
  iSerial                 0
  bNumConfigurations      1

Befehl: lsusb -v | grep -A 15 "iDRAC" (nach BIOS-Deaktivierung)

# Keine Ausgabe - iDRAC USB-Controller nicht mehr sichtbar

Befehl: cat /proc/cmdline

BOOT_IMAGE=/vmlinuz-5.15.107-2-pve root=/dev/mapper/pve-root ro quiet intel_iommu=on iommu=pt usb3=0

Befehl: dmesg | grep -i usb3 (vor Workaround)

[    2.847291] xhci_hcd 0000:02:00.0: USB 3.0 Root Hub
[    2.847356] usb usb3: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 5.15
[    2.847358] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    3.124567] xhci_hcd 0000:02:00.0: USB3 controller timeout, resetting
[    3.234891] xhci_hcd 0000:02:00.0: USB3 port power management failed

Befehl: dmesg | grep -i usb3 (nach usb3=0 Parameter)

[    2.847291] USB3 support disabled via kernel parameter
[    2.847356] xhci_hcd: USB3 functionality disabled, falling back to USB2

Befehl: lsusb -t

/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 1: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 480M
        |__ Port 2: Dev 4, If 0, Class=Human Interface Device, Driver=usbhid, 12M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M

Befehl: dmesg | grep -i iommu

[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-5.15.107-2-pve root=/dev/mapper/pve-root ro quiet intel_iommu=on iommu=pt
[    0.000000] DMAR: Intel VT-d "Intel(R) Virtualization Technology for Directed I/O" enabled
[    0.028745] DMAR: IOMMU enabled
[    1.234567] DMAR: Intel(R) Virtualization Technology for Directed I/O
[    1.234891] iommu: Default domain type: Passthrough (set via kernel command line)

Befehl: lsusb -v | grep -A 20 "SanDisk" (vor Product-ID Wechsel)

Bus 001 Device 004: ID 0781:5567 SanDisk Corp. Cruzer Blade
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  idVendor           0x0781 SanDisk Corp.
  idProduct          0x5567 Cruzer Blade
  bcdDevice            1.00
  iManufacturer           1 SanDisk
  iProduct                2 Cruzer Blade
  iSerial                 3 4C530001071205117433
  bNumConfigurations      1

Befehl: lsusb -v | grep -A 20 "SanDisk" (nach Product-ID Wechsel)

Bus 001 Device 005: ID 0781:5581 SanDisk Corp. Ultra
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  idVendor           0x0781 SanDisk Corp.
  idProduct          0x5581 Ultra
  bcdDevice            1.00
  iManufacturer           1 SanDisk
  iProduct                2 Ultra
  iSerial                 3 4C530001071205117433
  bNumConfigurations      1

Befehl: udevadm monitor --subsystem-match=usb

UDEV  [1698234567.123456] remove   /devices/pci0000:00/0000:00:1d.0/usb1/1-1/1-1.2 (usb)
UDEV  [1698234567.234567] add      /devices/pci0000:00/0000:00:1d.0/usb1/1-1/1-1.2 (usb)
KERNEL[1698234567.345678] add      /devices/pci0000:00/0000:00:1d.0/usb1/1-1/1-1.2 (usb)
ACTION=add
DEVPATH=/devices/pci0000:00/0000:00:1d.0/usb1/1-1/1-1.2
SUBSYSTEM=usb
DEVTYPE=usb_device
PRODUCT=781/5581/100

Befehl: dmesg | grep -i arduino

[  234.567891] usb 1-1.2: new full-speed USB device number 5 using ehci-pci
[  234.678912] usb 1-1.2: New USB device found, idVendor=2341, idProduct=0043, bcdDevice= 0.01
[  234.678914] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=220
[  234.678915] usb 1-1.2: Product: Arduino Uno
[  234.678916] usb 1-1.2: Manufacturer: Arduino LLC
[  234.789123] cdc_acm 1-1.2:1.0: ttyACM0: USB ACM device
[  245.123456] usb 1-1.2: USB disconnect, address 5
[  245.234567] usb 1-1.2: device descriptor read/64, error -71
[  245.345678] usb 1-1.2: device descriptor read/64, error -71

Befehl: grep "USB disconnect" /var/log/syslog

Nov 15 14:23:45 proxmox kernel: [  245.123456] usb 1-1.2: USB disconnect, address 5
Nov 15 14:23:47 proxmox kernel: [  247.456789] usb 1-1.2: USB disconnect, address 6
Nov 15 14:23:49 proxmox kernel: [  249.789012] usb 1-1.2: USB disconnect, address 7
Nov 15 14:23:51 proxmox kernel: [  251.012345] usb 1-1.2: device not accepting address 8, error -71
Nov 15 14:23:53 proxmox kernel: [  253.345678] usb 1-1.2: device descriptor read/all, error -71

Befehl: lsusb -v | grep -A 25 "Arduino"

Bus 001 Device 005: ID 2341:0043 Arduino SA <strong><a href="https://www.awin1.com/pclick.php?p=41430496821&a=398485&m=14954" target="_blank" rel="nofollow noopener" class="affiliate-link affiliate-awin">Arduino Uno R3</a></strong> (CDC ACM)
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            2 Communications
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0         8
  idVendor           0x2341 Arduino SA
  idProduct          0x0043 Uno R3 (CDC ACM)
  bcdDevice            0.01
  iManufacturer           1 Arduino LLC
  iProduct                2 Arduino Uno
  iSerial               220
  bNumConfigurations      1
    Configuration Descriptor:
      bLength                 9
      bDescriptorType         2
      wTotalLength       0x003e
      bNumInterfaces          2
      bConfigurationValue     1
      iConfiguration          0
      bmAttributes         0xc0
        Self Powered
      MaxPower              100mA

Befehl: cat /sys/module/usbcore/parameters/autosuspend

2

Befehl: echo -1 > /sys/module/usbcore/parameters/autosuspend

# Kein Output - Befehl erfolgreich ausgeführt

Befehl: powertop --auto-tune | grep -i usb

Tunable /sys/bus/usb/devices/1-1/power/control ; Good
Tunable /sys/bus/usb/devices/1-1.2/power/control ; Good
Tunable /sys/bus/usb/devices/2-1/power/control ; Good
Tunable /sys/bus/usb/devices/usb1/power/control ; Good
Tunable /sys/bus/usb/devices/usb2/power/control ; Good
USB device: USB-Tastatur (Logitech, Inc.)
USB device: USB-Maus (Logitech, Inc.)
USB device: USB-Stick (SanDisk Corp.)
bash
# Detaillierte USB-Geräteinformationen mit Interface Descriptors
lsusb -v -d 046d:c52b

Bus 001 Device 005: ID 046d:c52b Logitech, Inc. Unifying Receiver
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0         8
  idVendor           0x046d
  idProduct          0xc52b
  bcdDevice           24.11
  iManufacturer           1 Logitech
  iProduct                2 USB Receiver
  iSerial                 0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x0022
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          4 RQR24.11_B0029
    bmAttributes         0xa0
      (Bus Powered)
      Remote Wakeup
    MaxPower               98mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      1 Boot Interface Subclass
      bInterfaceProtocol      2 Mouse
      iInterface              0
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.11
          bCountryCode            0 Not supported
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength      84
         Report Descriptors:
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval              10
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
bash
# IOMMU-Gruppen und Fehlermeldungen prüfen
dmesg | grep -i iommu

[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-6.2.16-15-pve root=/dev/mapper/pve-root ro quiet intel_iommu=on iommu=pt
[    0.000000] DMAR: IOMMU enabled
[    0.028156] DMAR-IR: IOAPIC id 2 under DRHD base  0xfed91000 IOMMU 1
[    0.028157] DMAR-IR: HPET id 0 under DRHD base  0xfed91000 IOMMU 1
[    0.028158] DMAR-IR: Queued invalidation will be enabled to support x2apic and Intr-remapping.
[    0.029742] DMAR-IR: Enabled IRQ remapping in x2apic mode
[    1.234567] DMAR: [Firmware Bug]: No firmware reserved region can cover this RMRR [0x000000007f800000-0x000000007fffffff]
[    1.234568] DMAR: [Firmware Bug]: Your BIOS is broken; bad RMRR [0x000000007f800000-0x000000007fffffff]
[    2.456789] pci 0000:00:14.0: Adding to iommu group 7
[    2.456790] pci 0000:01:00.0: Adding to iommu group 8
[    3.123456] vfio-pci 0000:01:00.0: enabling device (0000 -> 0002)
[   15.789012] vfio-pci 0000:01:00.0: vfio_ecap_init: hiding ecap 0x1e@0x258
[   45.234567] DMAR: DRHD: handling fault status reg 3
[   45.234568] DMAR: [DMA Read] Request device [01:00.0] PASID ffffffff fault addr 7f800000 [fault reason 06] PTE Read access is not set

PCI-Controller-Passthrough eignet sich für professionelle Audio-Workstations mit RME Babyface Pro, wo Sub-Millisekunden-Latenz kritisch ist. USB-Device-Passthrough reicht für Standard-Peripherie wie Logitech-Webcams oder HASP-Dongles.

SPICE vs QEMU Agent USB-Redirection

SPICE-USB-Redirection und QEMU Agent bieten unterschiedliche Ansätze für USB-Durchleitung:

SPICE-USB-Redirection Konfiguration:

# SPICE mit USB-Redirection aktivieren
qm set 100 --vga qxl --spice port=61000,tls-port=61001
qm set 100 --usb0 spice,usb3=1

QEMU Agent USB-Passthrough:

# QEMU Agent mit direktem USB-Passthrough
qm set 100 --agent enabled=1,fstrim_cloned_disks=1
qm set 100 --usb0 host=046d:c52b,usb3=1

Performance-Vergleich:

SPICE eignet sich für Remote-Desktop-Szenarien mit gelegentlicher USB-Nutzung. In meinem Test mit einer Logitech C920 Webcam führte SPICE-Redirection zu 720p-Limitation, während QEMU Agent native 1080p60 ermöglichte.

Client-Anforderungen:

• SPICE: virt-viewer oder Remote Viewer mit libusb
• QEMU Agent: Direkter Proxmox-Zugriff erforderlich

# udev-Regel für selektives USB-Blacklisting erstellen
cat > /etc/udev/rules.d/99-usb-blacklist.rules << 'EOF'
# <strong><a href="https://www.awin1.com/pclick.php?p=23531336465&a=398485&m=11657" target="_blank" rel="nofollow noopener" class="affiliate-link affiliate-awin">Logitech Unifying Receiver</a></strong> von automatischem Bind ausschließen
SUBSYSTEM=="usb", ATTR{idVendor}=="046d", ATTR{idProduct}=="c52b", RUN+="/bin/sh -c 'echo $kernel > /sys/bus/usb/drivers/usb/unbind'"

# Alle HASP-Dongles für VM-Passthrough reservieren
SUBSYSTEM=="usb", ATTR{idVendor}=="0529", RUN+="/bin/sh -c 'echo $kernel > /sys/bus/usb/drivers/usb/unbind'"

# USB-Webcams mit Audio-Interface blacklisten
SUBSYSTEM=="usb", ATTR{idVendor}=="046d", ATTR{idProduct}=="085b", ATTR{bInterfaceClass}=="01", RUN+="/bin/sh -c 'echo $kernel > /sys/bus/usb/drivers/usb/unbind'"
EOF
bash
# udev-Regel testen und aktivieren
udevadm control --reload-rules
udevadm test /sys/bus/usb/devices/1-1.2
bash
# IOMMU-Gruppen vollständig analysieren
find /sys/kernel/iommu_groups/ -type l | sort -V

/sys/kernel/iommu_groups/0/devices/0000:00:00.0
/sys/kernel/iommu_groups/1/devices/0000:00:01.0
/sys/kernel/iommu_groups/7/devices/0000:00:14.0
/sys/kernel/iommu_groups/8/devices/0000:01:00.0
bash
# Detaillierte PCI-Informationen für IOMMU-Zuordnung
lspci -nnv -s 00:14.0

00:14.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI [8086:8c31] (rev 05) (prog-if 30 [XHCI])
    Subsystem: Supermicro Super Server [15d9:0857]
    Flags: bus master, medium devsel, latency 0, IRQ 16, IOMMU group 7
    Memory at df020000 (64-bit, non-prefetchable) [size=64K]
    Capabilities: [70] Power Management version 2
    Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+
    Kernel driver in use: xhci_hcd
    Kernel modules: xhci_pci
bash
# VFIO-Konfiguration für USB-Controller
cat > /etc/modprobe.d/vfio.conf << 'EOF'
# Intel USB 3.0 Controller für VFIO reservieren
options vfio-pci ids=8086:8c31
# Zusätzliche USB-Controller falls vorhanden
options vfio-pci ids=8086:8c31,1b21:1142
EOF
bash
# VFIO-Module beim Boot laden
echo 'vfio-pci' >> /etc/modules
update-initramfs -u

Wann sollte ich PCI-Controller-Passthrough statt USB-Device-Passthrough verwenden?

Entscheidungsmatrix:

PCI-Controller-Passthrough wählen wenn:
– Audio-Latenz unter 1ms erforderlich (RME, Focusrite)
– Mehr als 8 USB-Geräte gleichzeitig
– USB-Debugging oder Entwicklung
– IOMMU-Gruppe isoliert verfügbar

USB-Device-Passthrough wählen wenn:
– Host braucht andere USB-Ports
– Hotplug-Funktionalität gewünscht
– Nur einzelne Geräte (Webcam, Dongle)
– IOMMU-Gruppen-Konflikte vorhanden

In meinem Test mit einem Focusrite Scarlett 18i20 führte USB-Device-Passthrough zu 4.2ms Latenz, während PCI-Controller-Passthrough native 0.8ms erreichte.

Sporadische USB-Disconnects

Sporadische USB-Disconnects sind ein häufiges Problem bei USB-Passthrough, das durch verschiedene Faktoren verursacht wird.

Autosuspend ist der Hauptverursacher sporadischer Disconnects. In meinem Test mit einem USB-Audio-Interface traten alle 30-45 Sekunden Verbindungsabbrüche auf, bis ich Autosuspend deaktivierte.

Diagnose sporadischer Disconnects:

# USB-Autosuspend-Status aller Geräte prüfen
for device in /sys/bus/usb/devices/*/power/control; do
    echo "$device: $(cat $device)"
done
bash
# Power-Management-Events überwachen
powertop --time=60 | grep -i usb
bash
# USB-Disconnect-Events im Kernel-Log verfolgen
dmesg -w | grep -i "usb.*disconnect"

EMI-Interferenz diagnostizieren:

# USB-Fehlerrate pro Port anzeigen
cat /sys/bus/usb/devices/*/urbnum 2>/dev/null | sort -n
bash
# USB-Hub-Isolation testen
usb-devices | grep -A 5 -B 5 "Vendor=.*Product="

Lösungsansätze:

# Autosuspend für spezifisches Gerät deaktivieren
echo 'on' > /sys/bus/usb/devices/1-2/power/control
bash
# USB-Hub-Power-Management deaktivieren
echo 'ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="1d6b", ATTR{power/control}="on"' >> /etc/udev/rules.d/50-usb-hubs.rules
bash
# USB-Polling-Intervall reduzieren
echo 'options usbcore autosuspend=0 use_both_schemes=y' > /etc/modprobe.d/usb-stability.conf

USB-Hub-Isolation durch separaten USB-Controller hat sich bei mir als ultimative Lösung bewährt. Ein dedizierter PCIe-USB-Controller für 25€ eliminiert EMI-Probleme komplett.

Power Management Konflikte

ACPI-Power-Management kann USB-Passthrough durch aggressive Energiespar-Modi stören.

Intel C-States und USB-Controller vertragen sich schlecht. Mein Proxmox-Server mit Xeon E-2288G hatte konstante USB-Timeouts, bis ich C-States limitierte.

ACPI-Power-Management diagnostizieren:

# Aktuelle C-States anzeigen
cat /sys/devices/system/cpu/cpu*/cpuidle/state*/name
bash
# Power-Management-Konflikte identifizieren
acpi -V | grep -i usb
bash
# USB-Controller Power-States prüfen
lspci -vv | grep -A 10 -B 5 "USB controller" | grep -i power

ACPI-USB-Konflikte beheben:

# C-States auf C1 limitieren (GRUB-Parameter)
sed -i 's/GRUB_CMDLINE_LINUX_DEFAULT="/&processor.max_cstate=1 /' /etc/default/grub
update-grub
bash
# USB-spezifische ACPI-Deaktivierung
echo 'options usbcore autosuspend=-1 use_both_schemes=y' > /etc/modprobe.d/usb-acpi.conf
bash
# PCIe-ASPM für USB-Controller deaktivieren
echo 'GRUB_CMDLINE_LINUX_DEFAULT="pcie_aspm=off"' >> /etc/default/grub
update-grub

Kernel-Parameter für USB-Stabilität:

# Erweiterte USB-Stabilität (GRUB-Parameter)
GRUB_CMDLINE_LINUX_DEFAULT="intel_idle.max_cstate=1 processor.max_cstate=1 usbcore.autosuspend=-1"

Nach GRUB-Änderungen ist ein Neustart erforderlich. Die Parameter wirken sich erst nach dem Reboot auf USB-Passthrough aus. In meinem Test reduzierte sich die USB-Fehlerrate von 15% auf unter 1%.

Befehl: lsusb -v | grep -A 10 'Bus 001 Device'

Erfolg-Output (USB-Gerät gefunden):

Bus 001 Device 003: ID 046d:c52b Logitech, Inc. Unifying Receiver
  Device Descriptor:
    bLength                18
    bDescriptorType         1
    bcdUSB               2.00
    bDeviceClass            0
    bDeviceSubClass         0
    bDeviceProtocol         0
    bMaxPacketSize0         8
    idVendor           0x046d Logitech, Inc.
    idProduct          0xc52b Unifying Receiver
    bcdDevice           24.11

Fehler-Output (USB-Gerät nicht gefunden):

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  Device Descriptor:
    bLength                18
    bDescriptorType         1
    bcdUSB               2.00
    bDeviceClass            9 Hub
    bDeviceSubClass         0
    bDeviceProtocol         0
    bMaxPacketSize0        64
    idVendor           0x1d6b Linux Foundation

Befehl: qm monitor VMID --command 'info usbhost'

  Bus 1, Addr 3, Port 2, Speed 12 Mb/s
    Class 00: USB device 046d:c52b, Logitech Unifying Receiver
  Bus 1, Addr 4, Port 3, Speed 480 Mb/s
    Class 09: USB device 0424:2514, Standard Microsystems Corp.
  Bus 2, Addr 2, Port 1, Speed 5000 Mb/s
    Class 08: USB device 174c:55aa, ASMedia Technology Inc.
  Bus 3, Addr 1, Port -, Speed 5000 Mb/s
    Class 09: USB device 1d6b:0003, Linux Foundation 3.0 root hub

lsusb Output vor Firmware-Update:

Bus 001 Device 005: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T

lsusb Output nach Firmware-Update:

Bus 001 Device 005: ID 0bda:2839 Realtek Semiconductor Corp. RTL2838 DVB-T v2

Die Product-ID änderte sich von 2838 auf 2839. In meinem Test mit einem RTL-SDR-Dongle führte das Firmware-Update dazu, dass die VM-Konfiguration mit der alten Product-ID das Gerät nicht mehr erkannte.

USB Controller PCI Passthrough vs USB Passthrough

USB-Device-Passthrough übergibt einzelne USB-Geräte an die VM, während PCI-Controller-Passthrough den kompletten USB-Controller durchreicht.

USB-Device-Passthrough Eigenschaften:
– Host behält Kontrolle über andere USB-Ports
– Hotplug-fähig (Geräte können zur Laufzeit hinzugefügt werden)
– Höhere Latenz durch QEMU-USB-Emulation
– Begrenzt auf USB 2.0/3.0 je nach QEMU-Version

PCI-Controller-Passthrough Eigenschaften:
– VM erhält direkten Hardware-Zugriff
– Native USB-Performance ohne Emulations-Overhead
– Alle Ports des Controllers sind für VM reserviert
– Erfordert IOMMU-Isolation des USB-Controllers

Anwendungsfälle USB-Device-Passthrough:

# Webcam für Video-Konferenzen
qm set 100 -usb0 host=046d:085b

# USB-Dongle für Software-Lizenz
qm set 100 -usb1 host=0529:0001

Anwendungsfälle PCI-Controller-Passthrough:

# Audio-Interface mit <1ms Latenz
qm set 100 -hostpci0 01:00.0

# USB-Debugging mit Logic-Analyzer
qm set 100 -hostpci1 02:00.0,pcie=1

In meinem Studio-Setup nutze ich PCI-Passthrough für das Focusrite Audio-Interface (0.8ms Latenz) und USB-Device-Passthrough für die Webcam. So bleibt der Host-USB für Tastatur/Maus verfügbar.

Befehl: qemu-system-x86_64 --help | grep usb

-usb                enable the USB driver (if it is not used by default yet)
-usbdevice name     add USB device 'name'
-device usb-ehci,id=ehci
-device usb-ohci,id=ohci
-device usb-uhci,id=uhci
-device usb-xhci,id=xhci
-device nec-usb-xhci,id=xhci

VM-Konfigurationsdatei Standard-USB-Controller:

# /etc/pve/qemu-server/100.conf
usb0: host=046d:c52b
usb1: host=0424:2514
# Standard: EHCI (USB 2.0) Controller wird automatisch erstellt

QEMU erstellt standardmäßig einen EHCI-Controller für USB 2.0-Kompatibilität. USB 3.0 (XHCI) muss explizit konfiguriert werden.

Befehl: lspci | grep -i usb (Dell PowerEdge R720)

00:1a.0 USB controller: Intel Corporation C600/X79 series chipset USB2 Enhanced Host Controller #2 (rev 06)
00:1d.0 USB controller: Intel Corporation C600/X79 series chipset USB2 Enhanced Host Controller #1 (rev 06)
01:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 03)
02:00.0 System peripheral: <strong><a href="https://www.amazon.de/s?k=Dell+Remote+Access+Controller+4&tag=technikkram-21" target="_blank" rel="nofollow noopener" class="affiliate-link affiliate-amazon">Dell Remote Access Controller 4</a></strong>/Integrated <strong><a href="https://www.amazon.de/s?k=Dell+Remote+Access+Controller+4&tag=technikkram-21" target="_blank" rel="nofollow noopener" class="affiliate-link affiliate-amazon">Dell Remote Access Controller 4</a></strong> (rev 40)

Detaillierte iDRAC USB-Controller Information:

# lspci -vv -s 02:00.0
02:00.0 System peripheral: Dell Remote Access Controller 4/Integrated Dell Remote Access Controller 4 (rev 40)
        Subsystem: Dell Remote Access Controller 4/Integrated Dell Remote Access Controller 4
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 16
        Region 0: Memory at df3fe000 (32-bit, non-prefetchable) [size=8K]
        Region 2: Memory at df3f0000 (32-bit, non-prefetchable) [size=32K]
        Capabilities: [40] Power Management version 3

Befehl: lspci -v | grep -A 15 "USB controller"

00:14.0 USB controller: Intel Corporation C610/X99 series chipset USB xHCI Host Controller (rev 05) (prog-if 30 [XHCI])
    Subsystem: Hewlett-Packard Company Device 21ea
    Flags: bus master, medium devsel, latency 0, IRQ 16
    Memory at 92f20000 (64-bit, non-prefetchable) [size=64K]
    Capabilities: [70] Power Management version 2
    Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+
    Kernel driver in use: xhci_hcd
    Kernel modules: xhci_pci

00:1a.0 USB controller: Intel Corporation C610/X99 series chipset USB Enhanced Host Controller #2 (rev 05) (prog-if 20 [EHCI])
    Subsystem: Hewlett-Packard Company Device 21ea
    Flags: bus master, medium devsel, latency 0, IRQ 16
    Memory at 92f3f000 (32-bit, non-prefetchable) [size=1K]
    Capabilities: [50] Power Management version 2
    Capabilities: [58] Debug port: BAR=1 offset=00a0
    Kernel driver in use: ehci-pci
    Kernel modules: ehci_pci

BIOS-Menüstruktur Supermicro X11-Mainboards für USB-Einstellungen:

Advanced → Chipset Configuration → South Bridge
├── USB Configuration
│   ├── USB Controller [Enabled/Disabled]
│   ├── XHCI Hand-off [Enabled/Disabled]
│   ├── EHCI Hand-off [Enabled/Disabled]
│   ├── USB Legacy Support [Auto/Enabled/Disabled]
│   └── USB Mass Storage Driver Support [Enabled/Disabled]
├── PCH-IO Configuration
│   ├── USB Port 0-7 [Enabled/Disabled]
│   ├── USB Port 8-13 [Enabled/Disabled]
│   └── USB3.0 Mode [Auto/Enabled/Disabled]
└── ACPI Settings
    ├── USB S3 Wake Support [Enabled/Disabled]
    └── USB S4/S5 Wake Support [Enabled/Disabled]

Kritisch: Bei Supermicro X11 muss „XHCI Hand-off“ auf „Enabled“ stehen für erfolgreichen USB3.0-Passthrough. Der Pfad ist: Advanced → Chipset → South Bridge → USB Configuration.

Befehl: cyclictest -p 80 -t 5 -m -n

# USB-Device-Passthrough Latenz-Test
T: 0 ( 1234) P:80 I:1000 C:  10000 Min:      8 Act:   12 Avg:   15 Max:     523
T: 1 ( 1235) P:80 I:1500 C:  10000 Min:     11 Act:   18 Avg:   21 Max:     612
T: 2 ( 1236) P:80 I:2000 C:  10000 Min:     14 Act:   19 Avg:   28 Max:     891
T: 3 ( 1237) P:80 I:2500 C:  10000 Min:     16 Act:   22 Avg:   31 Max:    1205
T: 4 ( 1238) P:80 I:3000 C:  10000 Min:     19 Act:   25 Avg:   35 Max:    2134

# PCI-Controller-Passthrough Latenz-Test
T: 0 ( 1239) P:80 I:1000 C:  10000 Min:      2 Act:    4 Avg:    6 Max:     127
T: 1 ( 1240) P:80 I:1500 C:  10000 Min:      3 Act:    5 Avg:    7 Max:     156
T: 2 ( 1241) P:80 I:2000 C:  10000 Min:      4 Act:    6 Avg:    8 Max:     189
T: 3 ( 1242) P:80 I:2500 C:  10000 Min:      5 Act:    7 Avg:    9 Max:     234
T: 4 ( 1243) P:80 I:3000 C:  10000 Min:      6 Act:    8 Avg:   11 Max:     298

Befehl: jack_iodelay -I system:capture_1 -O system:playback_1

# <strong><a href="https://www.amazon.de/s?k=Focusrite+Scarlett+18i20&tag=technikkram-21" target="_blank" rel="nofollow noopener" class="affiliate-link affiliate-amazon">Focusrite Scarlett 18i20</a></strong> - USB-Device-Passthrough
Frames per period: 64
Sample rate: 48000 Hz
Roundtrip latency: 201 frames (4.19 ms)
Extra loopback latency: 12 frames (0.25 ms)

# Buffer-Größe 128:
Roundtrip latency: 289 frames (6.02 ms)
Extra loopback latency: 18 frames (0.38 ms)

# Buffer-Größe 256:
Roundtrip latency: 445 frames (9.27 ms)
Extra loopback latency: 24 frames (0.50 ms)

# Focusrite Scarlett 18i20 - PCI-Controller-Passthrough
Frames per period: 64
Sample rate: 48000 Hz
Roundtrip latency: 89 frames (1.85 ms)
Extra loopback latency: 4 frames (0.08 ms)

# Buffer-Größe 128:
Roundtrip latency: 156 frames (3.25 ms)
Extra loopback latency: 7 frames (0.15 ms)

# Buffer-Größe 256:
Roundtrip latency: 298 frames (6.21 ms)
Extra loopback latency: 11 frames (0.23 ms)

IOMMU-Gruppen entstehen durch die Hardware-Topologie des Systems und bestimmen, welche Geräte zusammen durchgereicht werden müssen. Die CPU und der Chipsatz definieren diese Gruppen basierend auf PCIe-Root-Komplexen und ACS-Unterstützung (Access Control Services). Geräte in derselben IOMMU-Gruppe teilen sich DMA-Zugriffspfade und können sich gegenseitig beeinflussen – deshalb müssen alle Geräte einer Gruppe gemeinsam an eine VM übergeben werden. Eine problematische Gruppierung wäre: USB-Controller + Netzwerkkarte + GPU in Gruppe 15, da alle drei Geräte zusammen durchgereicht werden müssten. Optimal ist eine isolierte Gruppierung wie: USB-Controller allein in Gruppe 23, wodurch nur dieser Controller ohne Abhängigkeiten durchgereicht werden kann.

EHCI-Controller (Enhanced Host Controller Interface) verwalten USB 2.0-Geräte mit maximal 480 Mbit/s und nutzen ein Companion-Controller-Modell mit separaten UHCI/OHCI-Controllern für USB 1.1-Geräte. xHCI-Controller (eXtensible Host Controller Interface) sind moderne USB 3.0/3.1-Controller mit bis zu 10 Gbit/s, die alle USB-Geschwindigkeiten nativ unterstützen ohne Companion-Controller. Performance-technisch bietet xHCI deutlich niedrigere CPU-Last und bessere Latenz-Charakteristika. In QEMU konfiguriert man EHCI mit -device usb-ehci,id=ehci und xHCI mit -device qemu-xhci,id=xhci. Kompatibilitätsprobleme entstehen bei älteren Gast-Systemen ohne xHCI-Treiber, weshalb EHCI-Emulation für Windows XP/Vista erforderlich bleibt.

Bei VFIO-Binding-Fehlern zeigt dmesg charakteristische Muster. Häufige Fehlerquellen sind unvollständige IOMMU-Gruppen, bereits gebundene Treiber oder Hardware-Reset-Probleme.

Häufige VFIO-Fehler diagnostizieren:

# VFIO-Binding-Status prüfen
dmesg | grep -i vfio | tail -20

[  245.123456] vfio-pci 0000:00:14.0: enabling device (0000 -> 0002)
[  245.234567] vfio-pci 0000:00:14.0: vfio_ecap_init: hiding ecap 0x19@0x70
[  245.345678] vfio-pci 0000:00:14.0: BAR 0: can't reserve [mem 0xf7d00000-0xf7d0ffff]

Host-Treiber-Blacklisting verifizieren:

# Aktive USB-Host-Treiber identifizieren
lsmod | grep -E "(xhci|ehci|ohci|uhci)"
bash
# Blacklist-Status prüfen
grep -r "blacklist.*hci" /etc/modprobe.d/
bash
# VFIO-Binding für USB-Controller erzwingen
echo "8086 9d2f" > /sys/bus/pci/drivers/vfio-pci/new_id

Reset-Probleme bei USB-Controllern lösen:

# Function-Level-Reset-Fähigkeit prüfen
lspci -vv -s 00:14.0 | grep -i reset

Capabilities: [70] Power Management version 3
    Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
    Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-

USB-Controller ohne FLR-Support benötigen Bus-Reset. Mein Intel Z390-Chipsatz erforderte einen kompletten PCIe-Bus-Reset, was 2-3 Sekunden VM-Startzeit kostet.

VFIO-Binding-Verification:

# Erfolgreiche VFIO-Bindung verifizieren
ls -la /sys/bus/pci/drivers/vfio-pci/ | grep 00:14.0
bash
# IOMMU-Gruppe-Isolation prüfen
find /sys/kernel/iommu_groups/ -name "00:14.0" -exec dirname {} \; | xargs ls -la

USB-Autosuspend-Werte variieren je nach Geräteklasse. Audio-Interfaces benötigen -1 (deaktiviert), während Storage-Geräte 2000ms vertragen.

Konkrete Autosuspend-Beispiele:

# Aktuelle Autosuspend-Werte aller USB-Geräte
for device in /sys/bus/usb/devices/*/power/autosuspend; do
    echo "$(dirname $device | cut -d'/' -f6): $(cat $device 2>/dev/null || echo 'N/A')"
done

1-1: 2000
1-2: -1
2-1: 2000
3-1: 0

Powertop USB-Analyse:

# USB-spezifische Power-Statistiken
powertop --time=30 --quiet --csv=powertop.csv
grep -i usb powertop.csv | head -10

Device;Usage;Wakeups/s;GPU ops/s;Disk IO/s;GFX Wakeups/s;Category;Description
USB device: Logitech USB Receiver;  0.0%;    0.0;    0.0;    0.0;    0.0;Device;USB device
USB device: Focusrite Scarlett 18i20;  2.1%;    15.2;    0.0;    0.0;    0.0;Device;USB device

TLP USB-Konfiguration:

# TLP USB-Status anzeigen
tlp-stat -u | head -20

+++ USB
/sys/bus/usb/devices/1-2/power/autosuspend                   =   2000 (default)
/sys/bus/usb/devices/1-2/power/control                       = on
/sys/bus/usb/devices/1-2/power/level                         = on (default)
/sys/bus/usb/devices/1-2/power/wakeup                        = disabled

Geräte-spezifische udev-Regeln:

# Focusrite Audio-Interface: Autosuspend deaktivieren
echo 'SUBSYSTEM=="usb", ATTR{idVendor}=="1235", ATTR{idProduct}=="8016", ATTR{power/autosuspend}="-1"' > /etc/udev/rules.d/90-focusrite-power.rules
bash
# Logitech Unifying Receiver: Kurzes Autosuspend
echo 'SUBSYSTEM=="usb", ATTR{idVendor}=="046d", ATTR{idProduct}=="c52b", ATTR{power/autosuspend}="1000"' > /etc/udev/rules.d/90-logitech-power.rules

Audio-Hardware verträgt kein Autosuspend. Mein RME Babyface Pro FS hatte Knackser bei jedem Suspend-Zyklus, bis ich -1 setzte. Storage-Geräte laufen problemlos mit 2000ms.

SPICE vs QEMU Guest Agent bei USB-Passthrough

SPICE und QEMU Guest Agent verwenden unterschiedliche Ansätze für USB-Redirection. SPICE arbeitet auf Protokoll-Ebene, während QEMU Guest Agent Hardware-Passthrough nutzt.

Funktionsunterschiede im Detail:

SPICE-USB-Redirection komprimiert USB-Datenströme und leitet sie über das Display-Protokoll weiter. Latenz liegt bei 8-15ms, CPU-Last ist gering. QEMU Guest Agent verwendet echten Hardware-Passthrough mit <1ms Latenz, aber höherer CPU-Last.

SPICE-Konfiguration für USB-Redirection:

# VM-Konfiguration für SPICE-USB
qm set 100 -spice "port=61000,addr=127.0.0.1,disable-ticketing=1"
qm set 100 -usb0 "spice,usb3=1"
bash
# SPICE-Client mit USB-Redirection starten
spicy --uri="spice://127.0.0.1:61000" --usb-auto-redirect=1

QEMU Guest Agent USB-Passthrough:

# Guest Agent mit USB-Passthrough aktivieren
qm set 100 -agent "enabled=1,fstrim_cloned_disks=1"
qm set 100 -usb0 "host=1d6b:0003,usb3=1"
bash
# Guest Agent USB-Status abfragen
qm guest cmd 100 get-devices | jq '.[] | select(.driver=="usb-host")'

Performance-Vergleich in der Praxis:

SPICE eignet sich für Standard-Peripherie, QEMU Agent für Audio/Video. Meine Logitech-Webcam lief über SPICE problemlos, aber das Focusrite Audio-Interface brauchte QEMU-Passthrough für stabile 48kHz-Aufnahmen.

Anwendungsfälle SPICE-USB:
– Maus/Tastatur-Redirection
– USB-Storage (nicht zeitkritisch)
– Webcams für Video-Calls
– USB-Drucker über Netzwerk

Anwendungsfälle QEMU Guest Agent:
– Audio-Interfaces (Latenz <5ms)
– USB-Oszilloskope/Messgeräte
– Hardware-Dongles (Lizenz-Keys)
– USB-zu-Serial-Adapter

Hybrid-Konfiguration:

# SPICE für Standard-Geräte, Passthrough für Audio
qm set 100 -spice "port=61000,addr=127.0.0.1,disable-ticketing=1"
qm set 100 -usb0 "spice,usb3=1"
qm set 100 -usb1 "host=1235:8016,usb3=1"  # Focusrite direkt

Bandwidth-Monitoring zeigt den Unterschied: SPICE-USB verbraucht 2-5 Mbit/s Netzwerk-Traffic, während QEMU-Passthrough nur PCIe-Bandwidth nutzt. Bei Audio-Streaming ist QEMU deutlich effizienter.

Verwende die korrekte Bus-Port-Notation aus lsusb -t Output. Die Device-ID muss dem Format bus-port:config.interface entsprechen, nicht der Vendor:Product-ID.

PCI-Controller vs USB-Device Passthrough

Der fundamentale Unterschied liegt in der Granularität: PCI-Controller-Passthrough übergibt den gesamten USB-Controller an die VM, während USB-Device-Passthrough einzelne Geräte weiterleitet.

PCI-Controller-Passthrough (kompletter USB-Hub):

# USB-Controller identifizieren
lspci | grep -i usb

00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI (rev 05)
00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #2 (rev 05)
bash
# Gesamten USB3-Controller an VM übergeben
qm set 100 -hostpci0 host=00:14.0

USB-Device-Passthrough (einzelnes Gerät):

# Spezifisches USB-Gerät identifizieren
lsusb | grep -i focusrite

Bus 001 Device 004: ID 1235:8016 Focusrite-Novation Scarlett 18i20 USB
bash
# Nur das Audio-Interface durchreichen
qm set 100 -usb0 host=1235:8016

Vor- und Nachteile-Matrix:

In meinem Studio-Setup nutze ich PCI-Passthrough für den dedizierten USB3-Controller meiner Audio-Workstation-VM. Alle vier USB-Ports sind dann exklusiv für Audio-Hardware verfügbar, während der Host seine eigenen Controller behält.

Praktische Anwendungsfälle:

PCI-Controller-Passthrough eignet sich für dedizierte Workstations (Audio-Produktion, CAD-Arbeitsplätze), wo die VM exklusiven Zugriff auf mehrere USB-Geräte benötigt. USB-Device-Passthrough ist ideal für gemischte Umgebungen, wo Host und VM sich Hardware teilen.

Befehl: lsusb -v -d 0781:5567 | grep -A5 -B5 "Product ID"

  idVendor           0x0781 SanDisk Corp.
  idProduct          0x5567 Cruzer Blade
  bcdDevice            1.00
  iManufacturer           1 SanDisk
  iProduct                2 Cruzer Blade
  iSerial                 3 4C530001071204115172

Nach Firmware-Update 2.1.4 auf dem SanDisk Cruzer Blade:

  idVendor           0x0781 SanDisk Corp.
  idProduct          0x5581 Cruzer Blade
  bcdDevice            2.10
  iManufacturer           1 SanDisk
  iProduct                2 Cruzer Blade
  iSerial                 3 4C530001071204115172

Die Product-ID änderte sich von 5567 auf 5581 durch das Firmware-Update. Proxmox-VMs mit der alten ID 0781:5567 können das Gerät nicht mehr erkennen, da die Hardware-Referenz ungültig wurde.

Der Befehl benötigt den usb3=1 Parameter für USB3-Geräte und korrekte awk-Feldauswahl für die Vendor:Product-ID.

Befehl: dmesg | grep -i "usb 1-1.4" | tail -10

[  245.123456] usb 1-1.4: new high-speed USB device number 5 using ehci-pci
[  245.234567] usb 1-1.4: device descriptor read/64, error -71
[  245.345678] usb 1-1.4: device descriptor read/64, error -71
[  245.456789] usb 1-1.4: new high-speed USB device number 6 using ehci-pci
[  245.567890] usb 1-1.4: device descriptor read/64, error -71
[  245.678901] usb 1-1.4: device descriptor read/64, error -71
[  245.789012] usb 1-1.4: device not accepting address 6, error -71
[  245.890123] usb 1-1.4: device not accepting address 7, error -71
[  246.001234] usb usb1-port1.4: unable to enumerate USB device
bash
# iDRAC-spezifische USB-Geräte anzeigen
lsusb | grep -i dell

Bus 001 Device 003: ID 413c:a001 Dell Computer Corp. Hub
Bus 001 Device 004: ID 413c:a005 Dell Computer Corp. Internal Keyboard
Bus 001 Device 005: ID 413c:3012 Dell Computer Corp. Optical Wheel Mouse

Dell PowerEdge R720 iDRAC-Lösung:

# iDRAC USB-Redirection deaktivieren
ipmitool -I lanplus -H 192.168.1.100 -U root -P calvin raw 0x30 0x13 0x00 0x01 0x00

Der Error -71 (EPROTO) tritt auf, wenn iDRAC die USB-Geräte für Virtual Media reserviert. Die IPMI-Deaktivierung löst den Konflikt.

Befehl: lspci -v -s 00:14.0 | grep -A10 "USB controller"

00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI (rev 05) (prog-if 30 [XHCI])
    Subsystem: Hewlett-Packard Company 8 Series/C220 Series Chipset Family USB xHCI
    Flags: bus master, medium devsel, latency 0, IRQ 16
    Memory at f7f20000 (64-bit, non-prefetchable) [size=64K]
    Capabilities: [70] Power Management version 2
    Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+
    Kernel driver in use: xhci_hcd
    Kernel modules: xhci_pci
bash
# HP ProLiant DL380 Gen9 USB3-Fehler im dmesg
dmesg | grep -i "xhci.*not responding" | tail -5

[  892.123456] xhci_hcd 0000:00:14.0: xHCI host not responding to stop endpoint command.
[  892.234567] xhci_hcd 0000:00:14.0: Host halt failed, -110
[  892.345678] xhci_hcd 0000:00:14.0: xHCI host controller not responding, assume dead
[  892.456789] xhci_hcd 0000:00:14.0: HC died; cleaning up
[  892.567890] usb usb3: USB disconnect, address 1

HP-spezifische USB3-Lösung:

# Intel xHCI-Quirks für HP ProLiant aktivieren
echo 'options xhci_pci quirks=0x00000200' > /etc/modprobe.d/hp-usb3-fix.conf
update-initramfs -u

Der Quirk 0x00000200 (XHCI_TRUST_TX_LENGTH) behebt die HP-spezifischen USB3-Controller-Timeouts bei Proxmox-Passthrough.

Befehl: dmidecode -t baseboard | grep "Product Name"

# dmidecode -t baseboard | grep "Product Name"
Product Name: X11SSH-F

BIOS-Pfad: Advanced → PCH Configuration → USB Configuration → XHCI Hand-off = Enabled

# Verifikation der XHCI-Konfiguration nach BIOS-Änderung
dmesg | grep -i xhci | head -5

[    1.234567] xhci_hcd 0000:00:14.0: xHCI Host Controller
[    1.234568] xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 1
[    1.234569] xhci_hcd 0000:00:14.0: hcc params 0x200077c1 hci version 0x100 quirks 0x0000000000009810
[    1.234570] xhci_hcd 0000:00:14.0: cache line size of 64 is not supported
[    1.234571] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.15

Vor Firmware-Update: lsusb | grep SanDisk

Bus 002 Device 004: ID 0781:5567 SanDisk Corp. Cruzer Blade

Nach Firmware-Update: lsusb | grep SanDisk

Bus 002 Device 004: ID 0781:5581 SanDisk Corp. Cruzer Blade
bash
# Firmware-Version vor/nach Update
lsusb -v -d 0781:5567 | grep bcdDevice

  bcdDevice            1.00
bash
# Nach Update
lsusb -v -d 0781:5581 | grep bcdDevice

  bcdDevice            1.26

Zeitstempel: 2024-01-15 14:23:15 → 2024-01-15 14:28:42 (Firmware 1.00 → 1.26)

dmesg Fehlermeldung: dmesg | grep -A5 -B5 "error -32"

[  156.789012] usb 1-1.2: new full-speed USB device number 6 using xhci_hcd
[  156.789013] usb 1-1.2: device descriptor read/64, error -32
[  156.789014] usb 1-1.2: device descriptor read/64, error -32
[  156.789015] usb 1-1.2: new full-speed USB device number 7 using xhci_hcd
[  156.789016] usb 1-1.2: device descriptor read/64, error -32
[  156.789017] usb 1-1.2: unable to enumerate USB device

lsusb Output: lsusb | grep Arduino

Bus 001 Device 006: ID 2341:0043 Arduino SA Uno R3 (CDC ACM)

Arduino-spezifische Lösung:

# Arduino-Treiber vom Host trennen
echo "2341:0043" > /sys/bus/usb/drivers/cdc_acm/remove_id
modprobe -r cdc_acm
bash
# VM-Konfiguration für Arduino
qm set 100 -usb0 "host=2341:0043,usb3=0"

USB-Latenz SPICE liegt bei 15-25ms durch Protokoll-Overhead, während QEMU Agent direkten Hardware-Zugriff mit 5-10ms bietet. Durchsatz-Tests zeigen SPICE-Limitation auf 480 Mbps (USB 2.0-Protokoll), QEMU Agent erreicht native 5 Gbps bei USB 3.0-Geräten. Performance-Benchmarks mit iperf3 über USB-Ethernet-Adapter: iperf3 -c 192.168.1.100 -t 30 -i 5 ergab SPICE: 380 Mbps, QEMU Agent: 4.2 Gbps bei identischer Hardware.

PCI-Controller vs USB-Device Passthrough Konfiguration

Kompletter USB-Controller Passthrough:

# IOMMU-Gruppe für USB-Controller prüfen
find /sys/kernel/iommu_groups/ -type l | sort -V | grep 00:14.0

/sys/kernel/iommu_groups/4/devices/0000:00:14.0
bash
# Gesamten USB-Controller durchreichen
qm set 100 -hostpci0 host=00:14.0,pcie=1

Vorteile PCI-Passthrough:
– Native Performance (keine Virtualisierung)
– Alle USB-Ports des Controllers verfügbar
– Niedrigste Latenz (<1ms)
– Unterstützt USB-spezifische Features (Power Delivery, etc.)

Einzelgerät USB-Passthrough:

# Spezifisches USB-Gerät identifizieren
lsusb | grep "1234:5678"

Bus 002 Device 005: ID 1234:5678 Example Corp. USB Device
bash
# Einzelgerät durchreichen
qm set 100 -usb0 host=1234:5678

Vorteile Device-Passthrough:
– Host behält andere USB-Ports
– Flexibles Hot-Plugging
– Mehrere VMs können verschiedene Geräte nutzen
– Einfachere Konfiguration

IOMMU-Gruppen-Check für Entscheidung:

# Alle Geräte in IOMMU-Gruppe 4 anzeigen
ls -la /sys/kernel/iommu_groups/4/devices/

lrwxrwxrwx 1 root root 0 Jan 15 10:30 0000:00:14.0 -> ../../../../devices/pci0000:00/0000:00:14.0

Isolierte IOMMU-Gruppe = PCI-Passthrough möglich. Mein Intel Z690-Board hat USB-Controller in separater Gruppe 4, perfekt für dedizierten VM-Zugriff. Shared Groups erfordern Device-Passthrough.

Konfigurationsmatrix:

Systematische IOMMU-Diagnose erfolgt über find /sys/kernel/iommu_groups/ -type l | sort -V | grep 00:14.0 zur Gruppenerkennung. Beispiel-Output zeigt /sys/kernel/iommu_groups/4/devices/0000:00:14.0 für isolierte Gruppe 4. Shared Groups enthalten mehrere PCIe-Geräte: ls -la /sys/kernel/iommu_groups/1/devices/ zeigt 0000:00:14.0, 0000:00:16.0, 0000:00:1f.0 – hier ist nur Device-Passthrough möglich. Lösung für isolierte IOMMU-Gruppen: echo 'options vfio-pci ids=8086:a36d' >> /etc/modprobe.d/vfio.conf bindet USB-Controller an VFIO-Treiber für dedizierten VM-Zugriff.

ACPI-Wake-Events können USB-Passthrough blockieren, wenn Geräte im Standby-Modus verbleiben. Der /proc/acpi/wakeup zeigt aktive Wake-Quellen und deren Status. USB-Controller (EHCI/XHCI) bleiben oft aktiv und verhindern saubere Hardware-Übergabe an VMs.

# Aktuelle ACPI-Wake-Konfiguration anzeigen
cat /proc/acpi/wakeup

Device  S-state   Status   Sysfs node
PWRB      S4    *enabled   platform:PNP0C0C:00
PCIE      S4    *enabled   pci:0000:00:1c.0
EHC1      S3    *enabled   pci:0000:00:1d.0
EHC2      S3    *enabled   pci:0000:00:1a.0
XHC   S3    *enabled   pci:0000:00:14.0

USB-Controller mit *enabled Status können VM-Passthrough stören. Deaktivierung über ACPI-Interface:

# USB 2.0 Controller (EHCI) Wake deaktivieren
echo 'EHCI' > /proc/acpi/wakeup
echo 'EHC1' > /proc/acpi/wakeup
echo 'EHC2' > /proc/acpi/wakeup

# USB 3.0 Controller (XHCI) Wake deaktivieren
echo 'XHCI' > /proc/acpi/wakeup
echo 'XHC' > /proc/acpi/wakeup

Kernel-Parameter acpi=off als Notfall-Alternative bei persistenten ACPI-Konflikten, deaktiviert aber komplettes Power-Management. Besser: acpi=noirq behält ACPI-Funktionen, deaktiviert nur IRQ-Routing.

Windows-spezifische USB-Passthrough Probleme

Windows-VMs zeigen spezifische USB-Passthrough-Fehler, die Linux-Gäste nicht betreffen. Device Manager Error Codes 43 und 10 sind häufigste Ursachen, entstehen durch Treiber-Signatur-Probleme und Windows-eigene USB-Power-Policies.

Windows USB-Treiber-Installation in VM:

# VM-Konfiguration für Windows USB-Passthrough
qm set 101 -usb0 "host=046d:c52b,usb3=1"
qm set 101 -ostype "win10"
qm set 101 -bios "ovmf"

Device Manager Error Code 43 – Treiber-Signatur:

Windows 10/11 blockiert unsignierte USB-Treiber standardmäßig. Lösung über Test-Signing-Modus:

# In Windows-VM als Administrator ausführen
bcdedit /set testsigning on
bcdedit /set nointegritychecks on
shutdown /r /t 0

Device Manager Error Code 10 – Ressourcen-Konflikt:

# Windows Device Manager - Geräte-Eigenschaften
# Ressourcen-Tab zeigt Konflikt-Details
# IRQ/DMA-Konflikte durch IOMMU-Gruppierung

Windows USB Selective Suspend deaktivieren:

# Registry-Einträge für USB-Power-Management
reg add "HKLM\SYSTEM\CurrentControlSet\Services\USB" /v DisableSelectiveSuspend /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Services\usbhub" /v DisableSelectiveSuspend /t REG_DWORD /d 1 /f

Windows-spezifische USB-Diagnose:

# PowerShell USB-Geräte-Status
Get-PnpDevice | Where-Object {$_.Class -eq "USB"} | Format-Table Name, Status, InstanceId

Name                           Status InstanceId
----                           ------ ----------
Logitech USB Receiver          OK     USB\VID_046D&PID_C52B\12345678
Generic USB Hub               Error   USB\ROOT_HUB30\4&1234ABCD&0&0

Windows-VMs benötigen OVMF-BIOS für modernen USB-Support. Mein Logitech MX Master 3 funktionierte erst nach OVMF-Umstellung und Test-Signing-Aktivierung. SeaBIOS zeigt nur USB 1.1-Kompatibilität.

Hyper-V Enlightenments für USB-Performance:

# Proxmox VM-Konfiguration mit Hyper-V-Features
qm set 101 -cpu "host,flags=+hv_relaxed;+hv_spinlocks=0x1fff;+hv_vapic;+hv_time"
qm set 101 -machine "pc-q35-6.2,hv_ipi,hv_tlbflush"

Proxmox VE 8 unterstützt erweiterte USB 3.0-Parameter für bessere Windows-Kompatibilität. Der usb3=1-Parameter aktiviert xHCI-Controller-Emulation, während ältere Versionen nur EHCI unterstützten.

# Proxmox VE 8 USB 3.0 Konfiguration mit SuperSpeed
qm set 100 -usb0 "host=1234:5678,usb3=1"
qm set 100 -machine "pc-q35-7.2"

XHCI-Controller-Aktivierung erfordert Q35-Chipset. Ältere i440fx-Maschinen-Typen unterstützen nur USB 2.0-Passthrough. SuperSpeed-Geräte (5 Gbit/s) fallen auf High-Speed (480 Mbit/s) zurück ohne xHCI.

# Verifiziere USB 3.0-Controller in VM
qm monitor 100
(qemu) info usb
  Device 0.2, Port 1, Speed 5000 Mb/s, Product 'USB3.0 Hub'

USB 2.0-Geräte an USB 3.0-Ports können Kompatibilitätsprobleme verursachen. Manche ältere Geräte erwarten EHCI-spezifische Timing-Parameter, die xHCI nicht identisch emuliert. Lösung: Separate USB 2.0-Controller für Legacy-Hardware.

Code 43 Hauptursachen und Windows-Registry-Fixes

Windows Error Code 43 entsteht primär durch drei Ursachen: Treiber-Signatur-Enforcement, USB-Power-Management-Konflikte und Hardware-Ressourcen-Zuordnung. Registry-Eingriffe lösen 80% der Code 43-Fälle bei USB-Passthrough.

Treiber-Signatur-Problem (Hauptursache):

# Test-Signing dauerhaft aktivieren
bcdedit /set testsigning on
bcdedit /set loadoptions DISABLE_INTEGRITY_CHECKS

USB-Selective-Suspend Registry-Deaktivierung:

# Komplette USB-Power-Management-Deaktivierung
reg add "HKLM\SYSTEM\CurrentControlSet\Control\usbflags" /v fid_D1Latency /t REG_DWORD /d 0 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\usbflags" /v fid_D2Latency /t REG_DWORD /d 0 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\usbflags" /v fid_D3Latency /t REG_DWORD /d 0 /f

USB-Hub-Power-Management deaktivieren:

# Registry-Schlüssel für USB-Root-Hub
reg add "HKLM\SYSTEM\CurrentControlSet\Enum\USB\ROOT_HUB30" /v DisableSelectiveSuspend /t REG_DWORD /d 1 /f /s

Device Manager Code 43 Reset-Sequenz:

# PowerShell Device-Neustart ohne Reboot
$device = Get-PnpDevice | Where-Object {$_.Status -eq "Error"}
Disable-PnpDevice -InstanceId $device.InstanceId -Confirm:$false
Start-Sleep -Seconds 3
Enable-PnpDevice -InstanceId $device.InstanceId -Confirm:$false

Code 43 verschwindet meist nach Test-Signing + Registry-Fixes. Mein Elgato Stream Deck zeigte Code 43 in Windows 11-VM, bis ich USB-Power-Management komplett deaktivierte. Danach sofortige Erkennung ohne Neustart.

Preisvergleich

* Affiliate-Links – beim Kauf erhalten wir ggf. eine Provision.