Es wird erkannt, lässt sich aber nicht durchreichen: Die ESXi-USB-WLAN-Falle, in die jeder tappt

Auf dem Papier hätte das einfach sein sollen: USB-WLAN-Adapter einstecken, USB-Passthrough auf ESXi 8.0.3 aktivieren, an eine VM anhängen, fertig.

Stattdessen starren Sie auf Folgendes:

• Realtek RTL8188GU erscheint in lsusb
• Es wird als Driver CDROM Mode erkannt
• esxcli hardware usb passthrough device list zeigt: Enabled: false Can Connect to VM: no (passthrough disabled)
• Sie aktivieren es
• Fügen den USB-Quirk (UQ_NET_IGNORE) hinzu
• Starten neu

Und es kommt trotzdem als deaktiviert zurück. Das ist frustrierend, liegt aber nicht an Ihrer Konfiguration, sondern an einer Limitierung der Plattform.

Was tatsächlich passiert

Ihr Adapter:

0bda:1a2b Realtek RTL8188GU 802.11n WLAN Adapter (Driver CDROM Mode)

Der Teil „Driver CDROM Mode“ ist der Schlüssel. Viele Realtek-USB-WLAN-Adapter booten zuerst in einen Mass-Storage-Modus und geben sich als gefälschtes CD-ROM mit Windows-Treibern aus. Erst nachdem der Treiber geladen ist, was unter Windows passiert, wechseln sie in den eigentlichen WLAN-Modus.

Mit diesem Modus-Wechsel kommt ESXi schlecht zurecht. Und es ist ohnehin extrem wählerisch, welche USB-Geräte es durchreicht. Wie jemand unverblümt antwortete:

Nur weil ESXi USB-Passthrough hat, heißt das nicht, dass jedes USB-Gerät funktioniert, nur Geräte auf der USB-HCL funktionieren.

USB-WLAN-Adapter stehen fast nie auf dieser HCL.

Warum Ihr UQ_NET_IGNORE es nicht behoben hat

Sie haben Folgendes versucht:

esxcli system settings advanced set -o /USB/quirks -s 0xbda:0x1a2b:0:0xffff:UQ_NET_IGNORE

Damit sagen Sie ESXi: „Versuche nicht, das als USB-NIC zu behandeln.“ Das ist korrekt, ändert aber nichts daran, dass das Gerät im CDROM-Modus steckt, dass der USB-Stack von ESXi seine Grenzen hat und dass diese Geräteklasse für Passthrough oft überhaupt nicht unterstützt wird.

Deshalb steht nach dem Neustart weiterhin da:

Enabled: false
Can Connect to VM: no (passthrough disabled)

Der USB-Stack des Hosts beansprucht das Gerät einfach weiter für sich.

Die größere Realität: ESXi und USB-WLAN führen fast immer in die Sackgasse

Einen Schritt zurück: ESXi ist für Datacenter-NICs, Storage-Geräte und unterstützte USB-Controller gebaut. Consumer-USB-WLAN-Adapter in VMs durchzureichen, gehört nicht dazu.

Selbst wenn Sie eine Verbindung hinbekommen, bleibt die Performance unvorhersehbar, USB-Resets brechen die Verbindung, Neustarts können sie trennen, und manche Chipsätze enumerieren nie vollständig korrekt. Sie kämpfen also gegen die Design-Philosophie des Hypervisors.

Die einzigen zwei Wege, die funktionieren könnten

Option 1: Den gesamten USB-Controller durchreichen (PCI-Passthrough)

Reichen Sie statt einzelner USB-Geräte den ganzen Controller durch:

1. Gehen Sie zu Host, dann Hardware, dann PCI Devices
2. Finden Sie den USB-Controller
3. Aktivieren Sie Passthrough
4. Starten Sie neu
5. Fügen Sie das PCI-Gerät der VM hinzu

Das klappt manchmal, weil die VM den USB-Stack direkt verwaltet und ESXi sich nicht mehr einmischt.

Dafür gehört der gesamte USB-Controller jetzt der VM, alles, was an ihm hängt, verschwindet vom Host, und nicht alle Motherboards isolieren USB-Controller sauber. Trotzdem ist das Ihre beste Chance.

Option 2: Kein USB-WLAN mehr nutzen

Ich weiß, das wollen Sie nicht hören, aber meistens ist es die richtige Antwort.

Wenn Sie einer VM WLAN-Zugang geben, Traffic isolieren oder im Lab testen wollen, gibt es bessere Ansätze: einen kabelgebundenen Uplink mit VLAN-Segmentierung, einen kleinen Reiserouter als WLAN-Bridge, eine unterstützte PCIe-WLAN-Karte, die Sie durchreichen, oder eine separate physische Box als WLAN-Client, deren Traffic Sie routen.

ESXi dazu zu überreden, sich wie ein Desktop-Hypervisor zu verhalten, ist ein schmerzhafter Weg.

Das Realtek-spezifische Problem

Realtek-USB-Chipsätze sind berüchtigt für merkwürdiges Enumerationsverhalten, Modus-Wechsel, herstellerspezifische Eigenheiten und schlechtes Treiberverhalten auf Linux-Ebene. Schon auf Linux-Hosts kämpfen Leute mit diesen Adaptern, und auf ESXi stapelt sich Inkompatibilität auf Inkompatibilität.

Warum es nach dem Neustart weiterhin als deaktiviert angezeigt wird

Achten Sie darauf, wie sich Ihr Gerät nach dem Neustart bewegt hat, von:

Bus 1 Device 9

zu:

Bus 1 Device 3

Die USB-Topologie wurde also neu enumeriert, die Geräteadresse hat sich geändert, und Ihre Passthrough-Bindung hält das nicht aus. Ein weiteres Warnsignal, dass ESXi mit diesem Gerät nicht glücklich ist.

Die ehrliche Antwort

Zum Laufen bringen können Sie das vielleicht, wenn Sie den gesamten USB-Controller durchreichen, der Chipsatz keinen Modus-Wechsel braucht, das VM-Betriebssystem damit korrekt umgeht und Ihnen Zuverlässigkeit nicht wichtig ist.

Produktionsstabil wird es nicht, jedenfalls nicht mit diesem Adapter und nicht auf ESXi.

Falls das ein Lab ist

Wenn Sie in einem Homelab experimentieren wollen, probieren Sie PCI-Passthrough des USB-Controllers, testen Sie es in einer Linux-VM, und wenn es scheitert, stecken Sie keine weitere Zeit hinein. Im Weg stehen dann die Design-Beschränkungen der Plattform, nicht Ihre Befehle.

Fazit

Sie haben nichts falsch konfiguriert, Sie sind an die Grenze dessen gestoßen, was ESXi unterstützen soll. USB-Passthrough gibt es, aber USB-WLAN-Adapter sind selten kompatibel, besonders Realtek-Modelle, die im CDROM-Modus booten.

Wenn Sie das sauber und stabil haben wollen, nutzen Sie richtige Networking-Hardware, oder reichen Sie einen ganzen Controller durch und leben mit den Kompromissen. Alles andere fühlt sich an wie ein Ringkampf mit dem Hypervisor, und der gewinnt meistens.