stottle Posted September 9, 2014 Share Posted September 9, 2014 I was trying to pass a specific usb device thru to my VM, but received an error about not having a usb bus to connect to. I added the following lines to my xml, which fixed the problem: <controller type='usb' index='0' model='ich9-ehci1'> <address type='pci' domain='0' bus='0' slot='4' function='7'/> </controller> <controller type='usb' index='0' model='ich9-uhci1'> <master startport='0'/> <address type='pci' domain='0' bus='0' slot='4' function='0' multifunction='on'/> </controller> However, I've seen different values for slot and function online, and I don't know what ich9-ehci1 and ich9-uhci1 are. Can someone shed some light on what these mean, and how to decide what the values should be? Thanks! Quote Link to comment
jonp Posted September 9, 2014 Share Posted September 9, 2014 I was trying to pass a specific usb device thru to my VM, but received an error about not having a usb bus to connect to. I added the following lines to my xml, which fixed the problem: <controller type='usb' index='0' model='ich9-ehci1'> <address type='pci' domain='0' bus='0' slot='4' function='7'/> </controller> <controller type='usb' index='0' model='ich9-uhci1'> <master startport='0'/> <address type='pci' domain='0' bus='0' slot='4' function='0' multifunction='on'/> </controller> However, I've seen different values for slot and function online, and I don't know what ich9-ehci1 and ich9-uhci1 are. Can someone shed some light on what these mean, and how to decide what the values should be? Thanks! Try adding these: <controller type='usb' index='0' model='ich9-uhci2'> <master startport='2'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x02' function='0x1'/> </controller> <controller type='usb' index='0' model='ich9-uhci3'> <master startport='4'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x02' function='0x2'/> </controller> Quote Link to comment
jonp Posted September 9, 2014 Share Posted September 9, 2014 Could also try adjusting the other two you have to this: <controller type='usb' index='0' model='ich9-ehci1'> <address type='pci' domain='0x0000' bus='0x02' slot='0x02' function='0x7'/> </controller> <controller type='usb' index='0' model='ich9-uhci1'> <master startport='0'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x02' function='0x0' multifunction='on'/> </controller> Quote Link to comment
stottle Posted September 9, 2014 Author Share Posted September 9, 2014 I can certainly try those changes. I was hoping this part could be a little less "black magic", so if you could point me to something that describes where these parameters come from, that would be appreciated. Note, passthru is at least working with the settings I provided. Thanks for the suggestion and all of the progress on KVM! Quote Link to comment
jonp Posted September 9, 2014 Share Posted September 9, 2014 I can certainly try those changes. I was hoping this part could be a little less "black magic", so if you could point me to something that describes where these parameters come from, that would be appreciated. Note, passthru is at least working with the settings I provided. Thanks for the suggestion and all of the progress on KVM! Sorry it's not so clear, but those are the XML statements required to generate the QEMU commands for USB pass through to work properly. If you want a GUI for creating VMs though, there is virt manager which can be used to connect to unRAID, but it's a Linux-only application. You could run it inside a VM though. A guide on how to do all this is in the works... Quote Link to comment
stottle Posted September 9, 2014 Author Share Posted September 9, 2014 I guess I wasn't clear on what I was after. I'm not looking for it to be simpler. I'm confused on this particular xml tag, and so I'm looking for an explanation. If you check the controllers section of the libvirt API, it says "Normally, libvirt can automatically infer such controllers without requiring explicit XML markup, but sometimes it is necessary to provide an explicit controller element."So I didn't include any controllers in my xml, but that caused the error about no usb bus. What seems odd is that there is a fixed string of xml that works (and needs to be added by me), but the string isn't dependent on my hardware. Even more confusing there are several versions with slightly different parameters (again, not tied to hardware). Hopefully you see why I find that confusing. The API (linked above) doesn't help (me) much, and google didn't point me to an answer either. So was just hoping for an answer here. Nothing's broken on my end (virtualization-wise - I copied a bunch of stuff over to reiserFS on beta7 from another unRAID server and thus potentially having corrupt copies). I was just looking for information. Quote Link to comment
jonp Posted September 9, 2014 Share Posted September 9, 2014 I guess I wasn't clear on what I was after. I'm not looking for it to be simpler. I'm confused on this particular xml tag, and so I'm looking for an explanation. If you check the controllers section of the libvirt API, it says "Normally, libvirt can automatically infer such controllers without requiring explicit XML markup, but sometimes it is necessary to provide an explicit controller element."So I didn't include any controllers in my xml, but that caused the error about no usb bus. What seems odd is that there is a fixed string of xml that works (and needs to be added by me), but the string isn't dependent on my hardware. Even more confusing there are several versions with slightly different parameters (again, not tied to hardware). Hopefully you see why I find that confusing. The API (linked above) doesn't help (me) much, and google didn't point me to an answer either. So was just hoping for an answer here. Nothing's broken on my end (virtualization-wise - I copied a bunch of stuff over to reiserFS on beta7 from another unRAID server and thus potentially having corrupt copies). I was just looking for information. Ok, I see what you're getting at. Can you share your entire xml? I specifically want to see the <hostdev> statements you used for the USB pass through and if you can, a before and after shot of your xml. Quote Link to comment
stottle Posted September 9, 2014 Author Share Posted September 9, 2014 Sure. The Win7.xml seems to work for GPU and single usb device (usb dongle for wireless keyboard with trackpad). The .working version was what I had previously, which supported GPU passthru (this was before I tried passthru on USB). Win7.xml.txt Win7.working.xml.txt Quote Link to comment
jonp Posted September 10, 2014 Share Posted September 10, 2014 what kind of device were you adding? If USB3, which I bet it is (like a webcam or something), I believe those controllers handle USB emulation. Here's the thing, you're using my original XML that specifies the use of the Q35 emulated chipset. That is the reason you have to manually enter those things in the XML to create the USB3 support. Libvirt allows the specification of Q35, but doesn't seem to pre-populate all the appropriate fields when invoking it's use yet. At least not consistently. If you want, you could try reverting to the i440fx emulated chipset which I personally haven't played with in a while, but it is probably worthwhile testing it again. The main reason I liked the q35 was that it was what allowed me to pass through higher-end gpus the same as lower-end without any difficulty. The i440fx in our initial testing was just not playing as nice as the q35. Here's the benefits of q35 in QEMU: http://wiki.qemu.org/Features/Q35 www.linux-kvm.org/wiki/images/0/06/2012-forum-Q35.pdf A big part of this is native PCIe device support. Some devs think the need for this just isn't there...others disagree. I just care about what works in our testing to deliver the most consistent experience to all of our users with the least amount of case-handling as possible (e.g. "oh user A, you do this...user B, you do that, user C, try standing on your head while starting the VM and holding the HDMI cable.") That all said, try changing this: <type arch='x86_64' machine='q35'>hvm</type> To this: <type arch='x86_64' machine='pc-i440fx-2.1'>hvm</type> Also, remove all this: <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=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on'/> <qemu:arg value='-device'/> <qemu:arg value='vfio-pci,host=01:00.1,bus=root.1,addr=00.1'/> </qemu:commandline> Instead, place these statements in your XML above the </devices> line: <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address bus='0x01' slot='0x00' function='0x0'/> </source> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address bus='0x01' slot='0x00' function='0x1'/> </source> </hostdev> Report back... Quote Link to comment
stottle Posted September 11, 2014 Author Share Posted September 11, 2014 Thanks for the reply - it sounds like q35 is better, and the usb controllers are specific to using q35. That said, I'm not sure why you are suggesting I try i440fx.... As for the hostdev change, that is the xml syntax corresponding to the lines I had, right? So it should work with q35 or i440fx? Quote Link to comment
jonp Posted September 11, 2014 Share Posted September 11, 2014 Thanks for the reply - it sounds like q35 is better, and the usb controllers are specific to using q35. That said, I'm not sure why you are suggesting I try i440fx.... As for the hostdev change, that is the xml syntax corresponding to the lines I had, right? So it should work with q35 or i440fx? The hostdev change was to test out GPU pass through on i440fx chipset along with your USB device pass through. Not a requirement, but something you could try if you wanted to avoid putting extra stuff in your XML that seems "erroneous." Quote Link to comment
Recommended Posts
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.