Bug 789621 - Problem adding USB host device to KVM Windows guest machine.
Problem adding USB host device to KVM Windows guest machine.
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: qemu (Show other bugs)
18
x86_64 Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Fedora Virtualization Maintainers
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-02-11 15:19 EST by Juris Krumins
Modified: 2016-08-17 08:02 EDT (History)
24 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-05-28 17:01:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Windows machine guest info (115.92 KB, application/pdf)
2012-02-11 15:19 EST, Juris Krumins
no flags Details
lsusb -vvv output of the device (2.28 KB, text/plain)
2013-05-23 17:08 EDT, denise.p.berry
no flags Details

  None (edit)
Description Juris Krumins 2012-02-11 15:19:12 EST
Created attachment 561141 [details]
Windows machine guest info

Description of problem:
Trying to add USB host device - storage and/or eToken to KVM Windows 7 32 and/or 64 bit (also Windows XP 32 and 64 bit) guest. No luck. Looks like Windows 7 see somthing on the bus, but device is not functioning inside of guest operating system. Sometime device in guest operating system doesn't even appear.


Version-Release number of selected component (if applicable):
Fedora 16
qemu-common-0.15.1-4.fc16.x86_64
qemu-img-0.15.1-4.fc16.x86_64
qemu-system-x86-0.15.1-4.fc16.x86_64
qemu-user-0.15.1-4.fc16.x86_64
qemu-kvm-tools-0.15.1-4.fc16.x86_64
qemu-kvm-0.15.1-4.fc16.x86_64

How reproducible:
Start Windows KVM machine, add USB 

Steps to Reproduce:
1.Start Windows 7 guest using Virtual Machine Manager
2. Add Hardware in "Virtual Hardware Details" part
3. Choose USB host device and select for USB flash drive.
4. Apply
  
Actual results:

No functional device appears in Windows 7 guest


Expected results:

USB flash device and/or functional eToken device should appear.


Additional info:

Mentioned configuration worked fine in Fedora 14 using KVM, Windows XP and eToken USB token. I guess it's somehow connected with USB 2.0 integration in qemu.
Comment 1 Fedora Admin XMLRPC Client 2012-03-15 13:56:50 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 2 Francis 2012-08-20 15:25:49 EDT
Same problem on RHEL 6.3
Comment 3 Jonathan Underwood 2012-10-18 06:28:40 EDT
Can confirm I see this problem on RHEL 6.3 too.
Comment 4 denise.p.berry 2013-01-03 16:17:13 EST
Please provide an update with the status of this issue.
Comment 5 Juris Krumins 2013-01-04 02:52:25 EST
(In reply to comment #4)
> Please provide an update with the status of this issue.

Unfortunatelly still no luck to get eToken to work in KVM VM.
Using following components:
Fedora release 16 (Verne) x86_64
kernel-3.6.10-2.fc16.x86_64
qemu-kvm-0.15.1-8.fc16.x86_64
qemu-img-0.15.1-8.fc16.x86_64
qemu-kvm-tools-0.15.1-8.fc16.x86_64
qemu-system-x86-0.15.1-8.fc16.x86_64
qemu-common-0.15.1-8.fc16.x86_64

Tested eiher with "Default" and "USB2" USB Controller Mode in KVM.
Comment 6 denise.p.berry 2013-01-08 15:53:16 EST
This issue has been open for almost a year.  Since there isn't a workaround or fix yet, can this errata be documented in the Technical Notes document?
Comment 7 Cole Robinson 2013-01-11 10:56:49 EST
Anyone hitting an issue on RHEL, please file a separate bug there.

Sorry for the general lack of response, but given that F16 is EOL if about a month, and USB support in qemu has changed quite a bit between F16 version and current state of things, my recommendation would be to try out Fedora 18, and if you can reproduce the issue I'll raise it with the USB guys.
Comment 8 Juris Krumins 2013-01-12 07:39:19 EST
I can try things out with F18 and report back in any case so we can decide what to to with this issue.(In reply to comment #7)
Comment 9 Fedora End Of Life 2013-01-16 15:43:26 EST
This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 10 Juris Krumins 2013-01-17 08:26:04 EST
(In reply to comment #8)
> I can try things out with F18 and report back in any case so we can decide
> what to to with this issue.(In reply to comment #7)


I've tested things out with F17. Same behaviour.

Following components are in use:

qemu-common-1.0.1-2.fc17.x86_64
qemu-kvm-1.0.1-2.fc17.x86_64
kernel-3.6.11-1.fc17.x86_64
qemu-kvm-tools-1.0.1-2.fc17.x86_64
qemu-system-x86-1.0.1-2.fc17.x86_64
qemu-img-1.0.1-2.fc17.x86_64
Comment 11 Don Dugger 2013-05-23 11:32:59 EDT
We tried this out on Fedora 18 and encountered the same problem.  Can you raise the issue with the USB guys?
Comment 12 Cole Robinson 2013-05-23 11:45:52 EDT
Don, for completeness can you please provide the following:

qemu package versions
qemu command line
guest OS
lsusb -vvv of the device
describe how things are failing in the guest
Comment 13 denise.p.berry 2013-05-23 17:08:18 EDT
Created attachment 752386 [details]
lsusb -vvv output of the device
Comment 14 denise.p.berry 2013-05-23 17:16:13 EDT
F18:

qemu-system-x86-1.2.2-11.fc18.x86_64
qemu-img-1.2.0-23.fc18.x86_64
qemu-kvm-1.2.2-11.fc18.x86_64
qemu-common-1.2.2-11.fc18.x86_64
kernel-3.6.10-4.fc18.x6_64

Guest OSs:
Windows Server 2008 R2 SP1 and Windows Server 2012

lsusb -vvv output:  
Please see attachment

Description of how things are failing in the guest:
Used Virtual Machine Manager to direct assign a USB device to a guest.  This works fine if the guest is Linux, but with a Windows guest it doesn't get assigned.  The device is removed from the host, and the guest OS has a yellow bang in device manager under Universal Serial Bus Controllers > USB Mass Storage Device.  In device properties, the general tab has the following device status: 
This device cannot start. (Code 10)
An invalid parameter was passed to a service or function.  

The events tab has an error event: Device not started (USBSTOR).  
The device not started event has the following information:  Device USB\VID_0BC2&PID_2400\2GJ11QJ6____had a problem starting.
Driver Name: usbstor.inf
Class GUID: {36FC9E60-C464-11CF-8056-444553540000}

Service: USBSTOR
Lower Filters:
Upper Filters: 
Problem: 0xA
Status: 0x0

The Windows Event Manager logged the following information for the same error event described above:
Log Name: Microsoft-Windows-Kernel-PnP/Device Configuration
Source: Kernel-Pnp
Event ID:  411
Level: Warning
User: SYSTEM
OpCode: Info

Tried two USB devices on and they produced the same results.
Comment 15 Cole Robinson 2013-05-23 17:23:36 EDT
Hans, Gerd, anything else to check for here?
Comment 16 Hans de Goede 2013-05-24 02:25:52 EDT
Hi all,

(In reply to Cole Robinson from comment #15)
> Hans, Gerd, anything else to check for here?

Denise, can you check what the usb controller type is set to in the virtual hardware details tab? If it is set to default or 1, can you try changing it to 2 ?

Also you're using host redirection, so can you please check /var/log/libvirt/qemu/<vmname>.log and if there are any USB related messages there, collect them and attach here?

Thanks,

Hans
Comment 17 Juris Krumins 2013-05-24 04:53:16 EDT
Just my 5 cents.

I finally got Alladin eToken to work on F18 with the following components:


qemu-system-sparc-1.2.2-11.fc18.x86_64
kernel-modules-extra-3.8.11-200.fc18.x86_64
qemu-system-xtensa-1.2.2-11.fc18.x86_64
qemu-system-mips-1.2.2-11.fc18.x86_64
qemu-system-x86-1.2.2-11.fc18.x86_64
kernel-3.9.2-200.fc18.x86_64
qemu-user-1.2.2-11.fc18.x86_64
qemu-system-ppc-1.2.2-11.fc18.x86_64
qemu-system-sh4-1.2.2-11.fc18.x86_64
qemu-system-s390x-1.2.2-11.fc18.x86_64
qemu-system-alpha-1.2.2-11.fc18.x86_64
qemu-img-1.2.2-11.fc18.x86_64
qemu-system-or32-1.2.2-11.fc18.x86_64
qemu-1.2.2-11.fc18.x86_64
qemu-system-unicore32-1.2.2-11.fc18.x86_64
qemu-system-microblaze-1.2.2-11.fc18.x86_64
kernel-doc-3.9.2-200.fc18.noarch
qemu-system-m68k-1.2.2-11.fc18.x86_64
qemu-kvm-1.2.2-11.fc18.x86_64
kernel-modules-extra-3.8.9-200.fc18.x86_64
kernel-headers-3.9.2-200.fc18.x86_64
kernel-modules-extra-3.9.2-200.fc18.x86_64
qemu-system-lm32-1.2.2-11.fc18.x86_64
qemu-kvm-tools-1.2.2-11.fc18.x86_64
qemu-system-cris-1.2.2-11.fc18.x86_64
qemu-common-1.2.2-11.fc18.x86_64
qemu-system-arm-1.2.2-11.fc18.x86_64



USB controller model for the virtual machine set to: Model USB 2
Guest OS: Windows 7 64 bit.
Comment 18 Cole Robinson 2013-05-25 15:31:34 EDT
Denise, please see comment #16, more info has been requested.
Comment 19 denise.p.berry 2013-05-28 15:39:19 EDT
Setting the USB controller type to 2 instead of 1 (default) works.  The log for the VM (/var/log/libvirt/qemu/<vmname>.log) didn't have any USB specific information when I tried using controller type 1.
Comment 20 Hans de Goede 2013-05-28 17:01:23 EDT
Hi,

Thanks for testing!

(In reply to denise.p.berry from comment #19)
> Setting the USB controller type to 2 instead of 1 (default) works.  The log
> for the VM (/var/log/libvirt/qemu/<vmname>.log) didn't have any USB specific
> information when I tried using controller type 1.

That explains things then, the device you're trying to redirect is considered not compatible with a USB-1 controller, before we had USB-2 support we did not check that, but now we only allow redirecting USB-2 devices to a USB-1 controller if the meet certain criteria and the device apparently does not,

Since moving to an USB-2 controller fixes this I'm going to close this bug.

Regards,

Hans
Comment 21 Michael DePaulo 2015-03-08 22:18:39 EDT
FYI: CentOS 7.0, and presumably RHEL 7.0, are affected by this issue also.
Changing the USB controller from "default" to "USB2" fixed compatibility with my SATA hard drive in a  USB2 dock (13fd:1240 "Generic External").

Note You need to log in before you can comment on or make changes to this bug.