Zuverlässige Zuordnung identischer USB-Geräte

Detlef Paschke

Renowned Member
Feb 12, 2019
163
27
68
Cottbus
helpdesk.schabau.eu
Hallo,
ich habe nach einem Kernelupdate gerade eine etwas unschöne Beobachtung bei Proxmox 8.4.14 gemacht, welche wohl auch auf anderen Proxmox-Versionen so gegeben sein wird. Es geht um ein Problem beim durchreichen von USB-Geräten von dem ich bisher verschont wurde, weil ich in der Regel die Hersteller/Geräte ID (Vendor/Device ID) für die Zuordnung verwende.
Nun habe ich ein USB-Gerät (Sonoff Zigbee 3.0 USB Dongle Plus V2 (10c4:ea60)) zwei mal, von welchen jeweils eines zu einer VM und das andere zu einer anderen VM durchgereicht werden muss. Auch wenn es baugleiche Geräte sind, dürfen sie nicht vertauscht werden, da sie in der VM exakt identifiziert werden.

Weil es sich um identische Geräte handelt, habe ich in der Hardwareeinstellungen der VMs, für diese Geräte den jeweiligen USB-Port verwendet. Nach einem Kernelupdate und dem anschließenden Neustart von Proxmox wurde aus den bisherigen USB-Ports 1-1.1 und 1-1.2 für diese Geräte aber die Ports 2-1.1 und 2.1.2. Die Geräte wurden somit nicht mehr in den VMs zur Verfügung gestellt. Nachdem mir das aufgefallen ist, habe ich zunächst die veränderten USB-Ports neu angegeben, dann aber testweise einen weiteren Neustart von Proxmox durchgeführt. Und wieder waren die USB-Ports nicht an ihrer (neuen) Position sondern wieder an der ursprünglichen.
Das alte udev-Problem schlägt hier also mit aller Macht durch.

Wie könnte ich diese identischen USB-Geräte zuverlässig zuordnen?
Bei Resource Mapping sehe ich auch keine alternative, denn die Zuordnung ist dort ja auch nur nach Port oder Vendor/Device ID gegeben.

Viele Grüße
Detlef Paschke
 
was sagt den lsusb -vvv zu deinem Device, haben die vielleicht unterschiedliche iSerial,
ich hab z.B. drei USV die ich damit eindeutig zuweise bzw per udev bekomme die dann neue Name das ich weiß welche USV welches Gerät ist
zum besser auslesen
 
du könntest dann in /etc/udev/rules.d eine Datei erstellen sonoff.rules mit folgendem Inhalt

Code:
# Sonoff1
KERNEL=="hiddev*", ATTRS{manufacturer}=="manufacturer", ATTRS{serial}=="iSeriel  ", OWNER="root", SYMLINK+="usb/sonoff1"
# Sonoff2
KERNEL=="hiddev*", ATTRS{manufacturer}=="manufacturer", ATTRS{serial}=="iSeriel  ", OWNER="root", SYMLINK+="usb/sonoff2"

manufacturer und iSeriel natürlich ersetzten
danach systemctl restart systemd-udevd

dann sollte unter /dev/usb/ deine Somoff als sonoff1 und sonoff2 auftauchen die du dann im der vm zuweisen kannst so sind es dann immer die richtigen Geräte

bei mir unter /dev/usb sieht es so aus z.B.

Code:
lrwxrwxrwx  1 root root      7  2. Nov 15:30 ups-dl-180 -> hiddev3
lrwxrwxrwx  1 root root      7  2. Nov 15:30 ups-pc -> hiddev1
lrwxrwxrwx  1 root root      7  2. Nov 15:30 ups-pve -> hiddev2

mein Eintrag in meiner ups.rules sieht so aus

Code:
# Server PVE-SRV

KERNEL=="hiddev*", ATTRS{manufacturer}=="American Power Conversion", ATTRS{serial}=="X4546O21877  ", OWNER="root", SYMLINK+="usb/ups-pve"

ah ne mist, unter pve selber sieht man ja leider die Namen nicht der geht ja nur über den Port direkt wenn man ein USB Gerät hinzufügen möchte
aber schau mal hier ob das hilft
USB_Physical_Port_Mapping

die Ports sollten aber auch nach einem Reboot gleich bleiben eigentlich
 
Last edited:
An udev als Möglichkeit habe ich auch gedacht, abgesehen davon, dass ich udev-rules zutiefst verabscheue.
Udev hat seit Anbeginn mehr Ärger als Freude gemacht und die gemachten Regeln hat man ohnehin vergessen bevor man ein defektes Gerät tauschen muss.
 
Alle bisherigen Versuche von mir, scheinen nicht wirklich sauber zu funktionieren.
Proxmox scheint ausschließlich den Kernel-Port oder Vendor/Device ID zu verwenden und schließt das unvorhersehbare Verhalten von udev völlig aus.

Das Problem scheint auch nicht selten angefragt zu werden und so stellt sich die Frage, ob nicht zumindest als "args:" eine genauere Identifizierung von (USB) Geräten in Proxmox eingebaut werden sollte.

Viele Grüße
Detlef Paschke
 
aber schau mal hier ob das hilft
USB_Physical_Port_Mapping

Das unvorhersehbare verhalten von udev ist auch dort nicht berücksichtigt.
Seit diesem schei... udev kann /dev/sda alles mögliche sein und der USB-Ports 1-1.1ist beim nächsten Systemstart evtl. USB-Ports 2-1.1.
Wenn man dann so doof ist und von einem Gerät mit dem man zufrieden ist ein zweites kaufen, wird es bei Proxmox aktuell schwierig.

Viele Grüße
Detlef Paschke
 
Last edited:
Seit diesem schei... udev kann /dev/sda alles mögliche sein und der USB-Ports 1-1.1ist beim nächsten Systemstart evtl. USB-Ports 2-1.1.

Falls es jemand braucht:
Ich habe eine Lösung gefunden die für mich funktioniert.
Ich habe in den VMs (VM1: Home Assistant, VM2: Zigbee2MQTT) jeweils beide USB Ports 1-1.1 UND 2-1.1 bzw. 1-1.2 UND 2-1.2 durchgereicht. Wenn durch UDEV beim Start der USB Bus wechselt ist es den VMs egal.

Es gab nur ein Problem bei mir, dass etwas Zeit und Nerven gekostet hat. Meine APC-USV war an USB 2-1.1 oder eben 1-1.1 angeschlossen. Die USV darf (zumindest hier) nicht an einem USB-Port angeschlossen sein der in die VM durchgereicht wird. Ich habe alles mögliche versucht aber das Ergebnis war auch mit UDEV Rules für die USV immer STATUS : COMMLOST von apcupsd, wenn der elektrische USB-Port in eine VM durchgereicht wurde. Ich habe die USV "elektrisch" Umgesteckt und sie an 1-1.3 bzw. 2-1.3 angeschlossen. Damit funktionieren die beiden identischen Sonoff Zigbee USB Dongle und die APC Back-UPS nach jedem Systemstart ohne Probleme. UDEV kann hier Tanzen wie es will.

Mir ist bei diesem ganzen Ärger mit zwei identischen Geräte/Hersteller IDs ein ganz verrückter Gedanke durch den Kopf gegangen.
Wenn die Hersteller so etwas ähnliches wie eine Seriennummer einpflegen würden, müsste man sich in Proxmox nicht nur auf den USB-Port oder Geräte/Hersteller ID beschränken sondern könnte hunderte identische Geräte problemlos an beliebig viele VMs durchreichen.
Okay, ist ein verrückter Gedanke von mir aber in ein zwei Generationen wird evtl. über so etwas gelacht weil die dann sagen, "...das ist doch selbstverständlich, warum sind die dazumal nicht selber darauf gekommen?". ;)

Viele Grüße
Detlef Paschke