November 6, 201411 yr From what I have read, the code to passthrough a USB device (flirc in my case) is as follows: <hostdev mode='subsystem' type='usb' managed='no'> <source> <vendor id='0x20a0'/> <product id='0x0001'/> </source> </hostdev> My question is what if you have multiple "like" USB devices to passthrough to multiple VMs. For example, I have 2 flircs and each is passed through to separate WIN8 VMs. The code above is not USB port specific (only vendor/product) so how can this be accomplished? John
November 6, 201411 yr From what I have read, the code to passthrough a USB device (flirc in my case) is as follows: <hostdev mode='subsystem' type='usb' managed='no'> <source> <vendor id='0x20a0'/> <product id='0x0001'/> </source> </hostdev> My question is what if you have multiple "like" USB devices to passthrough to multiple VMs. For example, I have 2 flircs and each is passed through to separate WIN8 VMs. The code above is not USB port specific (only vendor/product) so how can this be accomplished? John This is possible, but we have to pass additional attributes to indicate the specific flirc by device id. I'll test this out today and see if I can get you some XML to try out.
November 6, 201411 yr Author From what I have read, the code to passthrough a USB device (flirc in my case) is as follows: <hostdev mode='subsystem' type='usb' managed='no'> <source> <vendor id='0x20a0'/> <product id='0x0001'/> </source> </hostdev> My question is what if you have multiple "like" USB devices to passthrough to multiple VMs. For example, I have 2 flircs and each is passed through to separate WIN8 VMs. The code above is not USB port specific (only vendor/product) so how can this be accomplished? John This is possible, but we have to pass additional attributes to indicate the specific flirc by device id. I'll test this out today and see if I can get you some XML to try out. Thanks Jon. Found some info here: https://bbs.archlinux.org/viewtopic.php?id=167074 As I understand it, host:bus.addr is an alternative to host:vendor_id:product_id. So if I wanted to pass both of these thumb drives: $ lsusb Bus 001 Device 002: ID 1e3d:2093 Chipsbank Microelectronics Co., Ltd CBM209x Flash Drive (OEM) Bus 001 Device 003: ID 1e3d:2093 Chipsbank Microelectronics Co., Ltd CBM209x Flash Drive (OEM) ... I would use host:001.002 and host:001.003 . Note I said would use, because I've never tried it. And usb_add is a qemu monitor command. See sections 3.4 and 3.5 of the doc you linked for info on the monitor. All this being said, I don't use libvirt stuff so I don't know if it has the capability to specify USB devices by bus.addr or whether or not it enables the monitor. According to the above, should I change the USB passthrough section to look like this: <hostdev mode='subsystem' type='usb' managed='no'> <source> <host:001.002/> </source> </hostdev> I'm guessing it isn't this simple. John
November 6, 201411 yr Author I think this may have worked (or at least it didn't yell at me). I won't know until I get the OS installed. <hostdev mode='subsystem' type='usb' managed='no'> <source> <address bus='8' device='2'/> </source> root@unRAID:~# lsusb Bus 002 Device 003: ID 0951:1625 Kingston Technology DataTraveler 101 II Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 008 Device 002: ID 20a0:0001 Clay Logic Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 002: ID 20a0:0001 Clay Logic Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 002: ID 046b:ff10 American Megatrends, Inc. Virtual Keyboard and Mouse Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
November 6, 201411 yr Author W00t! USB Passthrough using bus/device IDs: <hostdev mode='subsystem' type='usb' managed='no'> <source> <address bus='6' device='3'/> </source> </hostdev> Works like a friggin champ!
November 6, 201411 yr Author For anyone who cares, here is my final working XML for XBMCBuntu Gotham with GPU and USB passthrough (by bus/device IDs...not vendor/product IDs): <domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'> <name>HTPCFAMRM</name> <uuid>c43b7542-b40b-495f-90ab-aaa4eec68e8a</uuid> <memory unit='KiB'>4194304</memory> <currentMemory unit='KiB'>4194304</currentMemory> <memoryBacking> <nosharepages/> <locked/> </memoryBacking> <vcpu placement='static'>4</vcpu> <cputune> <vcpupin vcpu='0' cpuset='0'/> <vcpupin vcpu='1' cpuset='1'/> <vcpupin vcpu='2' cpuset='2'/> <vcpupin vcpu='3' cpuset='3'/> </cputune> <os> <type arch='x86_64' machine='pc-q35-2.1'>hvm</type> <boot dev='hd'/> <bootmenu enable='no'/> </os> <features> <acpi/> <apic/> </features> <cpu mode='host-passthrough'> <topology sockets='2' cores='2' threads='1'/> </cpu> <clock offset='localtime'/> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>destroy</on_crash> <devices> <emulator>/usr/bin/qemu-system-x86_64</emulator> <disk type='file' device='disk'> <driver name='qemu' type='qcow2' cache='none' io='native'/> <source file='/mnt/cache/VMs/HTPCFAMRM.qcow2'/> <target dev='vdc' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x03' function='0x0'/> </disk> <disk type='file' device='cdrom'> <driver name='qemu' type='raw'/> <source file='/mnt/user/Images/xbmcbuntu-13.0~gotham_amd64.iso'/> <target dev='hdb' bus='ide'/> <readonly/> <address type='drive' controller='0' bus='1' target='0' unit='0'/> </disk> <controller type='usb' index='0' model='ich9-ehci1'> <address type='pci' domain='0x0000' bus='0x02' slot='0x01' function='0x7'/> </controller> <controller type='usb' index='0' model='ich9-uhci1'> <master startport='0'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x01' function='0x0' multifunction='on'/> </controller> <controller type='usb' index='0' model='ich9-uhci2'> <master startport='2'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x01' function='0x1'/> </controller> <controller type='usb' index='0' model='ich9-uhci3'> <master startport='4'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x01' function='0x2'/> </controller> <controller type='sata' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/> </controller> <controller type='pci' index='0' model='pcie-root'/> <controller type='pci' index='1' model='dmi-to-pci-bridge'> <address type='pci' domain='0x0000' bus='0x00' slot='0x1e' function='0x0'/> </controller> <controller type='pci' index='2' model='pci-bridge'> <address type='pci' domain='0x0000' bus='0x01' slot='0x01' function='0x0'/> </controller> <controller type='ide' index='0'/> <interface type='bridge'> <mac address='52:94:00:d0:c0:dc'/> <source bridge='br0'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x02' function='0x0'/> </interface> <hostdev mode='subsystem' type='usb' managed='no'> <source> <address bus='6' device='3'/> </source> </hostdev> <memballoon model='virtio'> <address type='pci' domain='0x0000' bus='0x02' slot='0x04' function='0x0'/> </memballoon> </devices> <seclabel type='none' model='none'/> <qemu:commandline> <qemu:arg value='-device'/> <qemu:arg value='ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root.1'/> <qemu:arg value='-device'/> <qemu:arg value='vfio-pci,host=83:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on'/> <qemu:arg value='-device'/> <qemu:arg value='vfio-pci,host=83:00.1,bus=pcie.0'/> </qemu:commandline> </domain>
November 6, 201411 yr Author Well, it was too good to be true. While the above works, USB ports have a nasty habit of changing their device IDs on the fly (or whenever a VM is stopped, started, restart). So, still investigating. John
November 6, 201411 yr Author Sigh...now KVM is taking it upon itself to inject the USB device address into my XML. I went back to using vendor and product IDs: <hostdev mode='subsystem' type='usb' managed='no'> <source> <vendor id='0x20a0'/> <product id='0x0001'/> </source> </hostdev> I then started the VM and noticed this when I viewed the XML... <hostdev mode='subsystem' type='usb' managed='no'> <source> <vendor id='0x20a0'/> <product id='0x0001'/> <address bus='6' device='3'/> </source> </hostdev>
November 7, 201411 yr Author So, this whole issue with randomly changing USB device IDs...is this a Linux issue? A KVM issue? Just wondering why I never saw this problem in ESXi? Does ESXi do some of it's own funky remapping to keep consistent IDs? John
November 7, 201411 yr Hi John, Have you tried to passthrough an usb hub? Also, an ethernet adapter? Rgds.
November 7, 201411 yr Author Do you mean an external USB hub plugged into a USB port? My understanding was that if you passthrough a USB hub you will not be able to see the devices attached to it to pass those through. Anyway, wouldn't I be in the same situation with the hub being assigned a different device ID at random? I haven't tried...just what I read. Or are you talking about an internal USB controller? John
November 7, 201411 yr Do you mean an external USB hub plugged into a USB port? Yes. I just tried to passthrough an usb hub. Any device you plug in won´t work unless it is also passthroughed. I pluged an usb stick in my windows vm .. it was not recognized.
November 9, 201411 yr Do you mean an external USB hub plugged into a USB port? My understanding was that if you passthrough a USB hub you will not be able to see the devices attached to it to pass those through. Anyway, wouldn't I be in the same situation with the hub being assigned a different device ID at random? I haven't tried...just what I read. Or are you talking about an internal USB controller? John Are you stuck on using flirc or could you use one flirc and multiple rc6 ir receivers from different vendors?
November 9, 201411 yr So, this whole issue with randomly changing USB device IDs...is this a Linux issue? A KVM issue? Just wondering why I never saw this problem in ESXi? Does ESXi do some of it's own funky remapping to keep consistent IDs? John I don't know if this could work. But I was looking at assigning usb with udev rules. Give each usb device a unique name based on serial number. Then you could look up device id from that? and insert into vm xm.
November 9, 201411 yr Author Do you mean an external USB hub plugged into a USB port? My understanding was that if you passthrough a USB hub you will not be able to see the devices attached to it to pass those through. Anyway, wouldn't I be in the same situation with the hub being assigned a different device ID at random? I haven't tried...just what I read. Or are you talking about an internal USB controller? John Are you stuck on using flirc or could you use one flirc and multiple rc6 ir receivers from different vendors? Yeah...I'm just being hard-headed. I do have an extra M$ Media Center remote/receiver. I can use that for now on the one TV that has a long USB run with the flirc pluged into the end. The other is plugged directly into the server and I use an IR blaster from that to the TV. Thanks for the push dmacias. John
November 9, 201411 yr Author So, this whole issue with randomly changing USB device IDs...is this a Linux issue? A KVM issue? Just wondering why I never saw this problem in ESXi? Does ESXi do some of it's own funky remapping to keep consistent IDs? John I don't know if this could work. But I was looking at assigning usb with udev rules. Give each usb device a unique name based on serial number. Then you could look up device id from that? and insert into vm xm. I'd be willing to try this if you have anything you want me to test. John
November 9, 201411 yr So, this whole issue with randomly changing USB device IDs...is this a Linux issue? A KVM issue? Just wondering why I never saw this problem in ESXi? Does ESXi do some of it's own funky remapping to keep consistent IDs? John I don't know if this could work. But I was looking at assigning usb with udev rules. Give each usb device a unique name based on serial number. Then you could look up device id from that? and insert into vm xm. I'd be willing to try this if you have anything you want me to test. John I don't have anything but was reading about it. One example I saw was for multiple ftdi serial usb. At the bottom of this page http://stackoverflow.com/questions/9183880/how-to-find-out-which-usb-rs232-device-is-on-which-tty if you could get this to work. Then maybe. I only have 2 external usb and my front usb2 to 3 cable doesn't work with this mobo. But if add rear ports or a hub I have I'll test.
November 10, 201411 yr Author So, this whole issue with randomly changing USB device IDs...is this a Linux issue? A KVM issue? Just wondering why I never saw this problem in ESXi? Does ESXi do some of it's own funky remapping to keep consistent IDs? John I don't know if this could work. But I was looking at assigning usb with udev rules. Give each usb device a unique name based on serial number. Then you could look up device id from that? and insert into vm xm. I'd be willing to try this if you have anything you want me to test. John I don't have anything but was reading about it. One example I saw was for multiple ftdi serial usb. At the bottom of this page http://stackoverflow.com/questions/9183880/how-to-find-out-which-usb-rs232-device-is-on-which-tty if you could get this to work. Then maybe. I only have 2 external usb and my front usb2 to 3 cable doesn't work with this mobo. But if add rear ports or a hub I have I'll test. It doesn't look like the flircs have serial numbers (unless I am looking in the wrong place)... ~ # lsusb -v Bus 06 Device 2a: ID 20a0:0001 Clay Logic Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x20a0 Clay Logic idProduct 0x0001 bcdDevice 1.00 iManufacturer 1 flirc.tv iProduct 2 flirc iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 50 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 Remote Wakeup MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 0 No Subclass bInterfaceProtocol 1 Keyboard iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.01 bCountryCode 0 Not supported bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 95 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 50 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 50
November 10, 201411 yr Even if they did they'd probably be the same. Much like usb flash drives. Only other thing I can think of is adding two separate hubs. One for each flirc. I don't know if that would help identify them from each other.
November 11, 201411 yr Just an FYI, this is definitely something we need to solve, but there are other bigger fish to fry in development first.
November 11, 201411 yr Author Just an FYI, this is definitely something we need to solve, but there are other bigger fish to fry in development first. Agreed. I seem to be the only one that has run into this issue...mainly due to my configuration. There are more important things to concentrate on as I have a workaround. However, I can't for for the day that I add 7x radeon HD6450s and 7x flrics to my server. John
July 16, 201510 yr Bumping this one to see if it is still on LT's radar. Jonp? Still is, just not ready to address that just yet. Still bigger fish to fry.
July 21, 201510 yr Documented in the defect reports thread with work around documented: https://lime-technology.com/forum/index.php?topic=41650.0
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.