Created attachment 932744 [details]
XML definition of the windows7 virtual machine

In case it is useful, here is the xml that defines the windows7 virtual machine (The webcam was not attached when this dump was taken). I can't say I actually understand any of this stuff, but it does appear to defined an ehci high speed USB controller you'd think it could use to plug a high speed device.

And to be really annoying, the webcam works fine when I attach it to a 32 bit Windows XP virtual machine on the same host. Here's the qemu log with the device as bus 3 device 32:

2014-08-30 01:13:26.390+0000: starting up
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin QEMU_AUDIO_DRV=spice /usr/bin/qemu-kvm -name winxppro -S -machine pc-0.14,accel=kvm,usb=off -m 8096 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid 6d626c31-643c-ca9a-d36d-3c1612e39bbd -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/winxppro.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-shutdown -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x9.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x9 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x9.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x9.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x8 -drive file=/zooty/images/winxppro.img,if=none,id=drive-virtio-disk0,format=qcow2,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/zooty/images/swap-winxppro.img,if=none,id=drive-virtio-disk1,format=raw,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk1,id=virtio-disk1 -drive if=none,id=drive-ide0-1-0,readonly=on,format=raw -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=23,id=hostnet0,vhost=on,vhostfd=24 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=54:52:00:62:7b:5c,bus=pci.0,addr=0x5 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input0 -spice port=5900,addr=127.0.0.1,disable-ticketing,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x2 -device AC97,id=sound0,bus=pci.0,addr=0x3 -device usb-host,hostbus=3,hostaddr=32,id=hostdev0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6
char device redirected to /dev/pts/0 (label charserial0)
main_channel_link: add main channel client
main_channel_handle_parsed: net test: latency 0.123000 ms, bitrate 24380952380 bps (23251.488094 Mbps)
inputs_connect: inputs channel client create
red_dispatcher_set_cursor_peer: 
main_channel_handle_parsed: agent start
ehci warning: guest updated active QH
qemu: terminating on signal 15 from pid 9827
red_channel_client_disconnect_dummy: rcc=0x7f8eb7e50240 (channel=0x7f8eb7e0fc70 type=5 id=0)
snd_channel_put: SndChannel=0x7f8eb7e468d0 freed
red_channel_client_disconnect_dummy: rcc=0x7f8eb7fa6910 (channel=0x7f8eb7e34860 type=6 id=0)
snd_channel_put: SndChannel=0x7f8eb7f960d0 freed
2014-08-30 01:15:17.808+0000: shutting down

Inside that virtual machine I was able to use Windows movie maker to record video from the webcam, and the device showed up in device manager as "legacy video capture" (or something like that). I didn't even have to install anything from logitech.

This may be the same as a problem thought to be only in virt-preview:

https://lists.fedoraproject.org/pipermail/virt/2014-August/004127.html

I've been looking at the Windows 7 system in more detail, and I actually do detect one thing when I plug in the webcam: For some reason, a "NEC USB Hub" appears in the usb controllers section of the device manager, but there is definitely no webcam device showing up anywhere.

(In reply to Tom Horsley from comment #0)
> Description of problem:
> 
> On my system, lsusb shows:
> 
> Bus 003 Device 022: ID 046d:0825 Logitech, Inc. Webcam C270
> 
> The first oddity is that the "Add Hardware" dialog box that pops up with the
> list of USB devices has the description of some USB devices, but not all,
> including the bus 3 device 22 entry which just has a blank area where I'd
> expect it to say Logitech Webcam.
> 

Libvirt/virt-manager gets that info from udev, so if you can see the correct vendor/product in udev output then either libvirt or virt-manager is messing up:

  udevadm info /dev/bus/usb/$bus/$addr

Regardless I'm guessing that's not related to the device not working, but I could be wrong

> I see warnings in there about speed mismatch, but I when I look at the usb
> setting in virt-manager, it says USB 2, so I'm not sure what else I can do
> to try and make it use a USB2 pass through.

Whatever is causing those warnings is probably responsible. Gerd, please see Tom's output in Comment #1, any thoughts?

I tried plugging it in again, and I see this in lsusb:

Bus 003 Device 014: ID 046d:0825 Logitech, Inc. Webcam C270

And this from  udevadm info /dev/bus/usb/003/014
P: /devices/pci0000:00/0000:00:14.0/usb3/3-12/3-12.2
N: bus/usb/003/014
E: BUSNUM=003
E: DEVNAME=/dev/bus/usb/003/014
E: DEVNUM=014
E: DEVPATH=/devices/pci0000:00/0000:00:14.0/usb3/3-12/3-12.2
E: DEVTYPE=usb_device
E: DRIVER=usb
E: ID_BUS=usb
E: ID_MODEL=0825
E: ID_MODEL_ENC=0825
E: ID_MODEL_FROM_DATABASE=Webcam C270
E: ID_MODEL_ID=0825
E: ID_REVISION=0012
E: ID_SERIAL=046d_0825_E4A49F80
E: ID_SERIAL_SHORT=E4A49F80
E: ID_USB_INTERFACES=:0e0100:0e0200:010100:010200:
E: ID_VENDOR=046d
E: ID_VENDOR_ENC=046d
E: ID_VENDOR_FROM_DATABASE=Logitech, Inc.
E: ID_VENDOR_ID=046d
E: MAJOR=189
E: MINOR=269
E: PRODUCT=46d/825/12
E: SUBSYSTEM=usb
E: TYPE=239/2/1
E: UPOWER_VENDOR=Logitech, Inc.
E: USEC_INITIALIZED=4424686435

I certainly see logitech and webcam in there, so I don't know why virt-manager doesn't say it.

Tom, can you open a separate bug against libvirt to track that? Provide that above udevadm output, and the virsh nodedev XML. To find the latter, you'll probably need to do

for i in `sudo virsh nodedev-list --cap usb_device | xargs`; do sudo virsh nodedev-dumpxml $i; done

and inspect the output for the matching device (maybe search for vendor hex string) and post it into the new bug. Thanks

(In reply to Tom Horsley from comment #3)
> I've been looking at the Windows 7 system in more detail, and I actually do
> detect one thing when I plug in the webcam: For some reason, a "NEC USB Hub"
> appears in the usb controllers section of the device manager, but there is
> definitely no webcam device showing up anywhere.

There are too many usb devices.  Four spice usb redirection slots.  One usb tablet.  Leaving only one usb port free, where qemu automagically plugs in a usb hub to avoid running out of usb ports.  This is where the "nec usb hub" comes from.  And as the emulated usb hub supports usb 1.1 only the webcam ends up on a slow port.  This is where the speed mismatch comes from, which is root cause why the webcam doesn't show up in the guest.

So, you have those four spice redirection ports, you can use virt-viewer (not fully sure virt-manager supports this too), then attach the webcam using spice usb redirection.  You find this via "File -> USB device selection" menu in virt-viewer.

Alternatively you can remove (some of) the spice redirection ports from the vm configuration to free up usb2 ports.  Then your webcam will get a usb2 port (when added via "add usb host device") and will work properly.

I certainly didn't configure the machine this way, I just let virt-manager set things up. Was it maybe a bad idea for virt-manager to allocate all the ports the way it did?

FWIW virt-manager does support the spice USB direction, similar to virt-viewer

(In reply to Tom Horsley from comment #8)
> I certainly didn't configure the machine this way, I just let virt-manager
> set things up. Was it maybe a bad idea for virt-manager to allocate all the
> ports the way it did?

Yeah this is virt-manager's fault... I didn't think the USB redirection devices had any downside, so I added 4 by default which is what gnome-boxes does. Figuring that boxes can't do typical USB device assignment since it requires a privileged libvirtd, all USB assignment for them needs to go over USB redirection, so they can afford to fill up more ports. Let's repurpose this bug to track virt-manager changing the default to 1 or 2 redirection devices.

Gerd, just curious, is the 6 port limit a function of the emulated usb2 hardware? Is there a limit for the usb1 and usb3 configurations?

  Hi,

> Gerd, just curious, is the 6 port limit a function of the emulated usb2
> hardware? Is there a limit for the usb1 and usb3 configurations?

uhci has two ports, fixed.
ehci has six ports, fixed.

ehci-with-companions has one ehci + three uhci controllers grouped.

xhci has four ports, by default, but I don't think libvirt has support for changing the number of ports.

The usb hub is used to increase the number of ports.  Which is pretty much transparent for uhci / usb1 devices.  But with ehci/xhci the devices connected via hub are second-class citizens as the hub supports usb1 only.

It is also possible to simply add a second ehci+companion controller group, so you get 12 instead of 6 ports.  Making that work nicely requires a bit more work in virt-manager though as you have explicitly assign usb devices to one of the two usb busses you have then.  libvirt supports <address type=usb/>, but it doesn't add those itself if not present (unlike it does with pci), so some work might be needed on the libvirt front too.

By golly, I deleted a couple of the USB redirector devices, and I could use add hardware to add the webcam and it actually worked.

Fixed upstream

commit 3933ff101b880898c9e7a502efd641db9c4bf8a5
Author: Cole Robinson <crobinso>
Date:   Sat Sep 20 20:16:31 2014 -0400

    guest: Limit number of default usb redirdevs to 2 (bug 1135488)

virt-manager-1.0.1-5.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/virt-manager-1.0.1-5.fc20

Package virt-manager-1.0.1-5.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing virt-manager-1.0.1-5.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-14000/virt-manager-1.0.1-5.fc20
then log in and leave karma (feedback).

virt-manager-1.0.1-5.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.