USB Passthrough not working for Windows 7 guest

I suffer from the same issue using QEMU 1.1. I tried 5 different USB thumbdrives and none of them worked. Interesting was that a USB 1.1 mouse was working though.

Same problem here, using:
qemu-kvm 0.13
kernel 2.6.36.2
kvm-intel

Guest:
Windows 7 Enterprise x64

INFO USBHOST:
  Device 2.2, speed 480 Mb/s
    Class 00: USB device 054c:02a5, Storage Media

INFO USB:
Device 0.3, Speed 480 Mb/s, Product Storage Media

Device appears in Windows 7 but in Error Code 10.

Ugh... I have just realized that KVM only supports UHCI, so not USB 2.0 support

two years passed... nothihg changed....
qemu 0.14.1+win7(32/64) the problem persist

Just found this problem with Win7 guest, both 32 and 64-bit, using qemu-kvm 1.01. WinXP is absolutely fine.

How can this /possibly/ not be a priority to fix?

This is an issue for me with Win7 SP1 64-bit guest on Ubuntu 12.10 (qemu-kvm 1.2.0+noroms)

Waiting on a microsoft license, hoping to be able to test this in the next 2 weeks.

This is also affecting Windows Server 2008 and happens with all usb storage devices I tested.

Bug #1033727 is specifically about qemu-kvm 1.2.0 and higher, see comment #8 on that bug for example. This bug is about earlier versions, including the version in 12.04 LTS.

This maybe not a duplicate as we're using 1.3.1 and Windows 7 isn't working there either. All other Operating systems are working though.

@Wessel: I believe the bug you pointed out as duplicate is saying that USB passthrough isnt working on any guest OS, but this bug is specifically targeted about Windows 7 not working.

I don't recall saying there was a duplicate of this bug? I merely objected to #1033727 being marked a duplicate.

Lol weird it's not marked as duplicate anymore anyway, guess it was not you then. Don't know what happened.

Can this bug be fixed in KVM or is it really to Windows specific? Else I may have a look at it, never did any KVM development though, should be fun.

@Serge: Did you get the license already and had a look at this bug?

@Sam,

I have the license now, but haven't had a chance to reproduce yet, sorry. It's on my list.

Upstream git head still gives me this problem, as does back to 0.14.0.

Note however that the same qemu builds, with the same usb stick, work fine using a linux guest.

The same stick, inserted to the same windows version on native hardware also works.

So it's not bad hardware, it's not hardware unsupported by windows, and qemu *is* passing the usb device through sufficiently that windows SHOULD be able to make use of it.

So this appears to be something specific that windows wants.

I've seen mention of windows registry tricks involving removal of top and bottom filters for the device... I haven't tested that to see if that would be a workaround.

Is there any workaround?

We're currently evaluating different RTOS systems. One is Linux RT with KVM/QEMU with Windows 7. This bug breaks the latency measurement setup and Linux RT is out of race. It there anyway to fix the issue?

Hi Jens,

could you tell us exactly what you are trying to pass through, what commands you've tried, and with what version of qemu (and, if hand-built, which options were passed to configure).

1.5 came with a new passthrough implementation, but alongside the old. So I wonder whether choosing the libusb based implementation would help.

Hi Serge,

for your information. I sent a mail to the devel mailing list. See below.

I've tried to passthrough special Vector automotive usb in house devices.
Look here: http://vector.com/vi_vn1600_en.html.

What do you mean with "what commands you've tried"?

I've tried three QEMU versions:

1. Ubuntu 13.04 64-bit prebuild qemu-kvm package (qemu 1.4.0)
2. Ubuntu 13.10 64-bit prebuild qemu-kvm package (qemu 1.5.0)
3. Hand builded QEMU 1.6.1 with standard configure call
    $ ./configure --prefix=/opt/kvm && make -j

Next, I want to build qemu from git?

I use virt-manager or virsh to start/stop my guest. The QEMU command line is:

qemu-system-x86_64 -machine accel=kvm:tcg -name VRTP1_win -S -M pc-
i440fx-1.4 -cpu SandyBridge -m 3072 -smp 2,sockets=1,cores=2,threads=1
-uuid 8ee5add7-f1a9-d697-9c18-2c1b4967c00e -no-user-config -nodefaults
-chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/VRTP1_win.monitor,server,nowait
-mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime
-no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2
-device ahci,id=ahci0,bus=pci.0,addr=0x6 -drive
file=/var/lib/libvirt/images/VN8912_Development_0.9.2.bin,if=none,id
=drive-sata0-0-0,format=raw -device ide-hd,bus=ahci0.0,drive=drive-
sata0-0-0,id=sata0-0-0,bootindex=1 -netdev
tap,fd=27,id=hostnet0,vhost=on,vhostfd=28 -device virtio-net-
pci,netdev=hostnet0,id=net0,mac=52:54:00:71:f5:45,bus=pci.0,addr=0x3
-chardev pty,id=charserial0 -device isa-
serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -vnc
127.0.0.1:0 -vga std -device intel-hda,id=sound0,bus=pci.0,addr=0x4
-device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device usb-
host,hostbus=3,hostaddr=18,id=hostdev0 -device virtio-balloon-
pci,id=balloon0,bus=pci.0,addr=0x5

Mail to devel list:

Hi all,

we're currently evaluating different RTOS systems (Windows CE, Intime, RTX, etc.).
One system is Linux RT + KVM/QEMU with a Windows 7 guest. Up to now all
works fine, Linux RT has good latency and KVM/Qemu setup was easy. But one QEMU bug
breaks my measurement setup and evaluation.

I've some usb devices for the Windows 7 guest. I configure them as USB passthrough.
The devices appears in the device manager of Windows 7, but with
"Error code 10": device cannot start". The Windows driver fails on USB set configuration.
The driver creates a IRP and send it via IOCTRL to lower layer. The IOCTRL fails with
invalid parameter.

driver log:
00000009 0.65470564 vnCDrvUsbControlRequestSetConfiguration, WdfUsbTargetDeviceSelectConfig single interface failed 0xc000000d
00000010 0.65472370 vnCDrvUsbIFPrepareHardwareState, vnCDrvUsbControlRequestSetConfiguration failed: 0xc000000d
00000011 0.65473646 vnCDrvDevConPrepareHardware, vnCDrvUsbIFPrepareHardwareState failed 0xc000000d
00000012 0.65474838 vnCDrvEvtDevicePrepareHardware, vnCDrvDevConPrepareHardware failed 0xc0000001
00000013 0.6547

This bug breaks my latency measurement setup and Linux RT is out of the evaluationg
race. Windows CE should not win :-), it there anyway workaround or hack to fix the issue?

My setup:

Ubuntu 64-bit
Windows 7 Embedded Guest
Linux Kernel: 3.10.10-rt7
QEMU: 1.4.0, 1.6.1

thanks...

All devices work on other hypervisors like VMware Workstation etc...

I have the same problem. I tried it with qemu 1.4 and the last 1.6.0-dfsg-2 on a debian testing system. Win 7 says always "This device cannot start. (Code 10)". I tried a lot of usb sticks but always the same...
I hope there will be sometime a solution for this :( I wait over a year in the hope that this will work.

@FanFan,

if you start such a vm and do 'ps -ef | grep kvm' should see the kvm command line which is working for you.

I think you should appoint the usb bus which according to your usb type, such as:
-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2
 -device usb-ehci,id=usb1,bus=pci.0,addr=0x4
 -device usb-hub,id=hub0,bus=usb.0,port=2
 -device usb-tablet,id=input0,bus=usb.0,port=1
 -device usb-host,hostbus=2,hostport=2,id=hostdev0,bus=usb1.0

Hi, I had the same problem. Tested a lot. My solution to passthrough usb devices to a windows 7 x64 guest:

parameter part:

-device usb-ehci,id=usb,bus=pci.0,addr=0x4 -device usb-host,vendorid=0x{},productid=0x{},id=hostdev0,bus=usb.0

I also tried the device
piix4-usb-uhci

instead of usb-ehci

piix4-usb-uhci caused the Code 10 error in the windows device manager.

lsusb will give you a list of plugged in usb devices. eg.

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

1d6b:0002
and
1d6b:0003

are vendorid:prouctid

replace {} with the ids and it should work. I tested it with

- ssd usb 3.0 drive
- retail usb seagate usb 2.0 hdd drive.

followup:

my understanding is there are a bunch of usb interfaces:

uhci is usb 1.0
ehci is usb 2.0
xhci is usb 3.0
…

-device piix3-usb-uhci will create an usb 1.0 interface. I guess usb 1.0 is insufficent for modern usb devices so windows errors with code 10. ehci have enough to bring full support for modern usb devices.

qemu is like LEGO where you can wire it all together :-)

refference:
https://github.com/qemu/qemu/blob/master/docs/usb2.txt
https://en.wikipedia.org/wiki/Host_controller_interface_(USB,_Firewire)#USB

Quoting Manuel Baesler (<email address hidden>):
> followup:
>
> my understanding is there are a bunch of usb interfaces:
>
> uhci is usb 1.0
> ehci is usb 2.0
> xhci is usb 3.0
> …
>
> -device piix3-usb-uhci will create an usb 1.0 interface. I guess usb 1.0
> is insufficent for modern usb devices so windows errors with code 10.
> ehci have enough to bring full support for modern usb devices.
>
> qemu is like LEGO where you can wire it all together :-)
>
> refference:
> https://github.com/qemu/qemu/blob/master/docs/usb2.txt
> https://en.wikipedia.org/wiki/Host_controller_interface_(USB,_Firewire)#USB

Thanks - so (this isn't documented in the qemu man page) am I to assume
that given " -usbdevice host:0781:5150" as the original bug submitter is
doing means "give me usb 1.0" ?

Max, does it work for you if you use (...taking a wild guess) :

 -device usb-ehci,id=usb,bus=pci.0,addr=0x4 \
 -device usb-host,vendorid=0x0781,productid=0x5150,id=hostdev0,bus=usb.0

or perhaps

 -device usb-ehci,id=usb,bus=pci.0,addr=0x4 \
 -usbdevice tablet \
 -device usb-host,vendorid=0x0781,productid=0x5150,id=hostdev0,bus=usb.0

You also might try xhci in place of ehci.

(If this does turn out to be the answer, then the bug title should be
changed to include 'usb2.0 and usb3.0 devices', to aid people in
finding this gem in the future)

 status: incomplete

RIght, with '-usb' qemu creates then 'piix3-usb-uhci' device:

00:01.2 USB controller: Intel Corporation 82371SB PIIX3 USB [Natoma/Triton II] (rev 01)

I can connect to network with qemu 2.0 with and win 7 pro 64bit guest.

qemu-system-x86_64 -machine accel=kvm -smp 2 -m 1024 -net none -device usb-ehci,id=usb,bus=pci.0,addr=0x4 -device usb-host,vendorid=0x0b95,productid=0x772b,id=hostdev0,bus=usb.0 -usb -usbdevice tablet -hda /srv/rhev/virtual.qcow -soundhw hda -boot c

Bus 007 Device 014: ID 0b95:772b ASIX Electronics Corp.

Unfortunately there is lack of automation and documentation. Ideally you would use something like
qemu-system-x86_64 -machine accel=kvm -smp 2 -m 1024 -net none -usb2 -usbdevice host:0b95:772b -usbdevice tablet -hda /srv/rhev/virtual.qcow -soundhw hda -boot c

Tthe usb device info from Linux should be enough to determine if the device is to be connected to usb1 or usb2, right?

So the RightWay(tm) to fix this is to download http://git.qemu.org/?p=qemu.git;a=blob_plain;f=docs/ich9-ehci-uhci.cfg;hb=HEAD

and run

qemu-system-x86_64 -net none -readconfig ich9-ehci-uhci.cfg -device usb-host,vendorid=0x0b95,productid=0x772b -device usb-tablet <extra options here>

Thanks Michal,

so at sounds like at least that file should be distributed with the qemu package. I don't know the best place for that, or how cleanly we can integrate it to make it easiest on the end-user...

Actually, in qemu 2.0.0 the file is packaged. However, it is packaged in the qemu package rather than qemu-system package so users are unlikely to have the file.

The file seems to be in qemu-system-common (at least in Ubuntu 14.10).

The next question is how to best help the user to run the right command. Should it go into the manpage?

Comment No. 23 by Manuel Baesler worked for me in Windows 10.
lsusb gave me:
Bus 001 Device 040: ID 8564:1000 Transcend Information, Inc. JetFlash
Qemu Flags used:
-device usb-ehci,id=usb,bus=pci.0,addr=0x4 -device usb-host,vendorid=0x8564,productid=0x1000,id=hostdev0,bus=usb.0

The only way to see my iPhone (or any USB device) in the Windows guest is to have it redirected via "Spice", not with libvirt xml capture elements.

Select Redirect USB device in virt-viewer and it just works.

I have upgraded to Qemu 2.4, libvirt 1.2.21 and upgraded the qemu machine to "q35" as I tried hard to make it work via xml.
Now that I have it working, I don't plan to check if it works with less current software / machines.

If I get the previous comments right, this is just about using the right configuration, and not a real bug? If so, I assume we can close this ticket nowadays?

Closing this bug for QEMU, since there haven't been any replies within the last 7 months.

Also marking the ubuntu task as incomplete. It looks like it's sorted, but let's give it some time for people to comment if they still have an issue.

Doing the same for the debian task, which doesn't have an upstream bug anyway.

[Expired for qemu (Ubuntu) because there has been no activity for 60 days.]