VirtualBox on Windows: USB passthrough needs --usb-ohci on; a Bluetooth dongle stays Captured until replugged
With only the EHCI controller enabled, VBoxManage usbattach fails with 'does not have a USB controller'; enabling OHCI fixed it. A cheap USB Bluetooth dongle also stuck at Captured with no attach and needed a physical replug after every VM restart.
virtualboxwindowsusbusbattachohcibluetoothvboxmanage History
Observed September to October 2026 on a Windows 10 host with VirtualBox 7.2.x and no Extension Pack, passing USB devices (a Wi-Fi adapter, then a Bluetooth dongle) into a headless Linux-based VM.
Symptom 1: usbattach fails with "does not have a USB controller"
VBoxManage.exe: error: The virtual machine does not have a USB controller
A second note records the same failure surfacing as VBOX_E_PDM_ERROR ... does not have a USB controller.
The first diagnosis was that the EHCI (USB 2) controller had been enabled in the VM settings while the VM was running, so the running instance had no controller, and that a power cycle was needed before controlvm <vm> usbattach could work. That explanation was incomplete. A later session found that with only EHCI enabled the guest never gets a USB controller at all, and that adding OHCI is what made passthrough work:
VBoxManage modifyvm <vm> --usb-ohci on
The same observation appears under both spellings, --usb-ohci (in a reference note) and --usbohci (in the session that applied it). The sources do not say which spelling 7.2 prefers; both were recorded as working notes, and the option list was not checked here.
Findings stated by the sources:
- With
--usb-ehci onalone, everyusbattachfailed, and a USB device filter added withusbfilter addhad no effect. - After
--usb-ohci onwas set, a USB filter worked for a headless VM. - The notes link OHCI to the absence of the Extension Pack (without the pack, only the OHCI controller is used for USB 1.1 devices). That reasoning is the notes' own and was not tested against a host that has the pack installed.
- Changing the controller needs the VM to be powered off and started again; whether a controller added to a running VM ever appears was not tested separately from the missing-OHCI cause.
VBoxManage list usbhost is the way to find the device's UUID before attaching.
Symptom 2: a Bluetooth dongle shows "Captured" but is never attached
Passing a cheap CSR8510-clone USB Bluetooth dongle (vendor and product id 0a12:0001) to a VM with usbfilter add and a running or rebooted VM produced this state:
VBoxManage list usbhostshowsCurrent State: Capturedfor the device.VBoxManage showvminfoshowsCurrently attached USB devices: <none>.VBoxManage controlvm <vm> usbattach <uuid>fails withis busy with a previous request. Please try again later, and retrying does not change it.
The note's explanation is that VirtualBox believes it owns the device while the hand-off from the Windows driver never completed. That is an inference from the symptom, not a result from a driver trace.
What fixed it: physically unplugging and replugging the dongle. Windows then enumerated it again and the VirtualBox USB monitor driver claimed it; the device's Address in list usbhost changed to a vid_80ee&pid_cafe path. The persistent filter then attached it to the VM automatically.
The fix was not permanent. A VM restart (even controlvm acpipowerbutton followed by startvm) returned the binding to the native Windows driver, so the replug was needed after every restart. The note observes that ordinary data or HID devices did not show this and attributes it to Windows' Bluetooth stack reclaiming the device, which is likewise an inference. With a soft restart the physical port is never power-cycled, which fits the need for a physical replug.
A software disable and re-enable of the device in Windows was not recorded as tried.
Related behaviour
The scenario that prompted the passthrough (a VM whose network had gone away) also showed that a Wi-Fi adapter given to the guest through passthrough dropped 33 percent of packets in one case, so a passthrough adapter was not a reliable replacement for a wired bridge. See the companion article on bridged networking for the bridge side.
Sources
- Observed directly on a Windows 10 host running VirtualBox 7.2.x with a headless Linux-based appliance VM, September 2026; the dongle behaviour was recorded in a lesson note the same month, the OHCI finding in a later session. No Extension Pack installed.