KVM and USB Passthrough
 

I am having som issues getting USB passthrough to work. This is what my config looks like in the xml:

<hostdev mode='subsystem' type='usb' managed='yes'>
<source>
<vendor id='0x0781'/>
<product id='0x5583'/>
</source>
</hostdev>


The thing is that it seems to work a little, cus if I shut down my VM and unplugg the USB and try to start the VM again, I get an error saying that the USB device is missing.

if I do lsusb in the host before the device is passed through it show the device like this: "Bus 002 Device 007: ID 0781:5583 SanDisk Corp."

But if I do lsusb in the vm after the device is passed through I get a new device shown like this: "Bus 001 Device 003: ID 0409:55aa NEC Corp. Hub"

The device I am trying to pass through is a San Disk 64GB usb stick, and both the host and the VM is CentOS 7 if that mathers.

Anyone have experience with this issue? Please help me in the right direction. Thanks!

so I found this guy that figured out a solution : https://unix.stackexchange.com/quest...d05b5c0a32f003

The problem seems to be with the USB Bus implementation in 1440FX chipset that is emulated by qemu by default. The woraound is emulating the ICH9 chipset instead.

The way this guy solves it seems to be by simply adding the "-M q35" to the qemu command. Is it posible to edit whatever changes that makes in the xml with "virsh edit" command?

I havent really used qemu commands to administer my vms, uselly I manage with virt-manager. But is there a way to simply just use qemu to add the "-M q35" to an already existing VM?

You could put a wrapper script around qemu, or you can use virsh edit on your VM. Virt-manager only lets you pick q35 vs i440fx at machine creation. Bear in mind that from the point of view of the VM OS, you are replacing the motherboard. Centos will probably boot just fine, but a Windows VM will blue screen.

Thanks for the reply! I am not really sure what u mean with a wrapper script, still very much new to most of this stuff :/ I have been experimenting a bit with "virsh edit", but with little results.

The first thing I tried was to just edit the USB controller to this:

<controller type='usb' index='0' model='ich9-ehci1'>
<address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x7'/>
</controller>

it looked like this first:

<controller type='usb' index='0' model='nec-xhci'>
<address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
</controller>

a little note: "function='0x7'" seems to be USB 2 and "function='0x0'" seems to be USB 3, is this correct? would "ich9-ehci1" work with both or is that just possible with USB 2.0?

This mod gave no different result btw..

the next thing I tried was changing this:

<os>
<type arch='x86_64' machine='pc-i440fx-rhel7.0.0'>hvm</type>
<boot dev='hd'/>
</os>

to this:

<os>
<type arch='x86_64' machine='pc-ich9-ehci1-rhel7.0.0'>hvm</type>
<boot dev='hd'/>
</os>

This gave me an error messegae saying IDE controlles are unsopported for this QEMU binary or machine type. so I tried removing the IDE controller but it seems I am not allowed to do that. if I try to remove it in virt-manager it just dossent go away and nothing really happens, and if I try to remove it in the xml I am allowed to save it just fine but it comes right back as soon as I start the VM it seems. any idea why this happens?

Also seems like I only get the option to choose i440FX when creating a new VM in virtmanager. can this by any chanse be related to the fact that my host is not installed via UEFI? seems like I cannot choose UEFI bios in the VM settings either.

the entire xml for the vm I am trying to get the usb passthrough to work on looks like this btw:

<domain type='kvm'>
<name>scriptTesting</name>
<uuid>ecc4b42e-6758-43e5-aef0-0e05118c503b</uuid>
<memory unit='KiB'>2097152</memory>
<currentMemory unit='KiB'>1048576</currentMemory>
<vcpu placement='static'>2</vcpu>
<resource>
<partition>/machine</partition>
</resource>
<os>
<type arch='x86_64' machine='pc-ich9-ehci1-rhel7.0.0'>hvm</type>
<boot dev='hd'/>
</os>
<features>
<acpi/>
<apic/>
</features>
<cpu mode='custom' match='exact'>
<model fallback='allow'>Haswell-noTSX</model>
</cpu>
<clock offset='utc'>
<timer name='rtc' tickpolicy='catchup'/>
<timer name='pit' tickpolicy='delay'/>
<timer name='hpet' present='no'/>
</clock>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>restart</on_crash>
<pm>
<suspend-to-mem enabled='no'/>
<suspend-to-disk enabled='no'/>
</pm>
<devices>
<emulator>/usr/libexec/qemu-kvm</emulator>
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2'/>
<source file='/var/lib/libvirt/images/scriptTesting.qcow2'/>
<target dev='vda' bus='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
</disk>
<disk type='block' device='cdrom'>
<driver name='qemu' type='raw'/>
<target dev='hda' bus='ide'/>
<readonly/>
<address type='drive' controller='0' bus='0' target='0' unit='0'/>
</disk>
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2'/>
<source file='/var/lib/libvirt/images/scriptTesting-1.qcow2'/>
<target dev='sda' bus='sata'/>
<address type='drive' controller='0' bus='0' target='0' unit='0'/>
</disk>
<controller type='virtio-serial' index='0'>
<address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
</controller>
<controller type='pci' index='0' model='pci-root'/>
<controller type='usb' index='0' model='ich9-ehci1'>
<address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x7'/>
</controller>
<controller type='sata' index='0'>
<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/>
</controller>
<controller type='ide' index='0'/>
<interface type='direct'>
<mac address='52:54:00:61:a2:3c'/>
<source dev='enp7s0u2c2' mode='bridge'/>
<model type='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</interface>
<serial type='pty'>
<target port='0'/>
</serial>
<console type='pty'>
<target type='serial' port='0'/>
</console>
<channel type='unix'>
<source mode='bind' path='/var/lib/libvirt/qemu/channel/target/domain-scriptTesting/org.qemu.guest_agent.0'/>
<target type='virtio' name='org.qemu.guest_agent.0'/>
<address type='virtio-serial' controller='0' bus='0' port='1'/>
</channel>
<channel type='spicevmc'>
<target type='virtio' name='com.redhat.spice.0'/>
<address type='virtio-serial' controller='0' bus='0' port='2'/>
</channel>
<input type='tablet' bus='usb'/>
<input type='mouse' bus='ps2'/>
<input type='keyboard' bus='ps2'/>
<graphics type='spice' autoport='yes' listen='0.0.0.0' keymap='no'>
<listen type='address' address='0.0.0.0'/>
</graphics>
<sound model='ich6'>
<address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
</sound>
<video>
<model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
</video>
<hostdev mode='subsystem' type='pci' managed='yes'>
<source>
<address domain='0x0000' bus='0x03' slot='0x00' function='0x0'/>
</source>
<address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/>
</hostdev>
<hostdev mode='subsystem' type='usb' managed='yes'>
<source>
<vendor id='0x0781'/>
<product id='0x5583'/>
</source>
</hostdev>
<redirdev bus='usb' type='spicevmc'>
</redirdev>
<redirdev bus='usb' type='spicevmc'>
</redirdev>
<memballoon model='virtio'>
<address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/>
</memballoon>
</devices>
<seclabel type='dynamic' model='selinux' relabel='yes'/>
</domain>

if I do "/usr/libexec/qemu-kvm -machine help" I get this result:

Supported machines are:
none empty machine
pc RHEL 7.0.0 PC (i440FX + PIIX, 1996) (alias of pc-i440fx-rhel7.0.0)
pc-i440fx-rhel7.0.0 RHEL 7.0.0 PC (i440FX + PIIX, 1996) (default)
rhel6.6.0 RHEL 6.6.0 PC
rhel6.5.0 RHEL 6.5.0 PC
rhel6.4.0 RHEL 6.4.0 PC
rhel6.3.0 RHEL 6.3.0 PC
rhel6.2.0 RHEL 6.2.0 PC
rhel6.1.0 RHEL 6.1.0 PC
rhel6.0.0 RHEL 6.0.0 PC

So it seems q35 ich9 chip is not supported? is there something I can do to add this support? why is this USB passthrough stuff so tricky when PCI passthrough is so easy?! does anyone know of a good guide that cowers all the areas to get USB pasthrough working properlie?

The IDE controller goes with the 440 machine type, the q35 has a PCI controller. It's a lot easier to start from scratch when making a new VM, just like with a physical machine. You can always make a new machine and modify it afterwards, eg add your disk image.

I think we established that Centos 7 has dropped q35 anyway in your other thread.

A wrapper script is basically an alias for qemu-kvm. Instead of a link pointing to the qemu-x86_64 binary, you point it to a shell script which has qemu-x86_64 -M q35, or whatever custom commands you want. Then whenever qemu-kvm is called (eg by virt-manager), you'll automatically get q35 as your default. It's best to do this only in pretty rare cases and it makes maintenance a bit more involved, as you have to remember you modified things. I'd recommend you change your distro to support q35 (bummer), and make a q35 machine from scratch using virt-manager.

Guide: as usual, the Arch wiki is good and has good references. This page is probably overkill: https://wiki.archlinux.org/index.php...rough_via_OVMF

Thanks for the reply! like u sugested, I have landed on the decission to move to another distro. Ubuntu server seems like a safe choice as I am still very far from feeling like a pro. Is there any specific reasons(like this frustrating issue) I should not choose Ubuntu Server?

When it comes to the topic of moving my VMs from one KVM Hypervisor to another. If I do "virsh exportxml" on all my VMs and have backup of all my VM hard drive files, I should have everything I need to get my stuff upp and running again on the new hypervisor right?

Yes, though really you just need the drive files; it is usually trivial to recreate the xml part if you have to, unless you have something tricky.

I kept the xml for the VMs that work fine with the i440, and ill see what ill do with the VMs that need the Q35 once I actually have it supported. I will probebly just do everything from scratch there, still need to learn allot so its all a good learning experience I guess.

Thanks for the help sir!