Re: Constantly changing USB product ID
On 03/27/2012 05:48 PM, Jaap Winius wrote: Hi folks, Recently I learned how to configure KVM with USB pass-though functionality. In my case I configured my guest domain with this block of code: hostdev mode='subsystem' type='usb' managed='yes' source vendor id='0x0c93'/ product id='0x1772'/ address bus='1' device='4'/ /source /hostdev At first this worked fine, but then later the guest domain refused to start because the USB device was absent. When I checked, I found that its product ID had mysteriously changed to 1771. Later it was back at 1772. Now it appears that the USB device I am dealing with has a product ID that changes back and forth between 1771 and 1772 at random. Apparently, the Windows program running on the guest domain is designed to deal with this nonsense, but the question is, Can KVM be configured to deal with it? Something like product id='0x177*'/ would be useful, but that doesn't work. Any ideas would be much appreciated. This is really strange. What kind of device is this? I've filed an RFE [1] for virt-manager for assigning USB host devices opportunistically, that is if they're plugged they're assigned, and if not the guest starts without them. If it were implemented, you could assign both 0x1771 and 0x1772 and whichever ID the device is today would get assigned. [1] https://bugzilla.redhat.com/show_bug.cgi?id=804432 -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Constantly changing USB product ID
On 03/28/2012 02:41 PM, Avi Kivity wrote: On 03/27/2012 05:48 PM, Jaap Winius wrote: Hi folks, Recently I learned how to configure KVM with USB pass-though functionality. In my case I configured my guest domain with this block of code: hostdev mode='subsystem' type='usb' managed='yes' source vendor id='0x0c93'/ product id='0x1772'/ address bus='1' device='4'/ /source /hostdev At first this worked fine, but then later the guest domain refused to start because the USB device was absent. When I checked, I found that its product ID had mysteriously changed to 1771. Later it was back at 1772. Now it appears that the USB device I am dealing with has a product ID that changes back and forth between 1771 and 1772 at random. Apparently, the Windows program running on the guest domain is designed to deal with this nonsense, but the question is, Can KVM be configured to deal with it? Something like product id='0x177*'/ would be useful, but that doesn't work. Any ideas would be much appreciated. This is really strange. What kind of device is this? I've filed an RFE [1] for virt-manager for assigning USB host devices opportunistically, that is if they're plugged they're assigned, and if not the guest starts without them. If it were implemented, you could assign both 0x1771 and 0x1772 and whichever ID the device is today would get assigned. [1] https://bugzilla.redhat.com/show_bug.cgi?id=804432 btw, the correct place for this discussion is likely the libvirt mailing list, or maybe the virt-manager list if it exists. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Constantly changing USB product ID
On 03/27/12 17:48, Jaap Winius wrote: Hi folks, Recently I learned how to configure KVM with USB pass-though functionality. In my case I configured my guest domain with this block of code: hostdev mode='subsystem' type='usb' managed='yes' source vendor id='0x0c93'/ product id='0x1772'/ address bus='1' device='4'/ /source /hostdev At first this worked fine, but then later the guest domain refused to start because the USB device was absent. Not sure what libvirt does there, but qemu can handle this just fine. If you add '-device usb-host,vendorid=0x0c93,productid=0x1772' qemu will start just fine no matter if the device is present or not. You can plug in in and out as you like and it will show up in the guest when plugged in. Might be a some security thing, when running qemu depriviledged and selinux-controlled libvirt probably has to make sure the files in /dev/bus/usb/ have correct permissions and labels. When I checked, I found that its product ID had mysteriously changed to 1771. Later it was back at 1772. Now it appears that the USB device I am dealing with has a product ID that changes back and forth between 1771 and 1772 at random. Guess it has two modes, one real and one install where it presents itself as mass storage device with windows drivers. Apparently, the Windows program running on the guest domain is designed to deal with this nonsense, but the question is, Can KVM be configured to deal with it? Something like product id='0x177*'/ would be useful, but that doesn't work. qemu is fine with '-device usb-host,vendorid=0x0c93' which will match any product with from that vendor. Dunno about the libvirt side. cheers, Gerd -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Constantly changing USB product ID
Hi folks, Recently I learned how to configure KVM with USB pass-though functionality. In my case I configured my guest domain with this block of code: hostdev mode='subsystem' type='usb' managed='yes' source vendor id='0x0c93'/ product id='0x1772'/ address bus='1' device='4'/ /source /hostdev At first this worked fine, but then later the guest domain refused to start because the USB device was absent. When I checked, I found that its product ID had mysteriously changed to 1771. Later it was back at 1772. Now it appears that the USB device I am dealing with has a product ID that changes back and forth between 1771 and 1772 at random. Apparently, the Windows program running on the guest domain is designed to deal with this nonsense, but the question is, Can KVM be configured to deal with it? Something like product id='0x177*'/ would be useful, but that doesn't work. Any ideas would be much appreciated. Thanks, Jaap -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
