libvirt: When installing two or more identical usb devices in a VM, only one works

[Mariano Dupont]

The problem is described in this bug:

https://bugzilla.redhat.com/show_bug.cgi?id=816560

"libvirt ignores address bus= device= when identicle vendor ID/product IDs usb devices attached with either virsh or virt-manager"

That bug is closed, but the problem is present in 0.9.8-2ubuntu17.4 (ubuntu server precise lts)

Can anyone confirm if there is a version that solves this in ubuntu and how to install it in last LTS?

Thank you!

============================
SRU Justification:
1. Impact: starting a VM with two usb devices with same vendor/id causes one to be ignored.
2. Development fix: looks over a list of usb devices with vendor/id.
3. Stable fix: backported patches from development fix.
4. Test case:
======== test case start ========
Steps to Reproduce:
1. Connect 2 USB to serial converters to the hypervisor
2. Use virt-manager to attach them to the guest. The XML hostdev part should read similar to:

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

3. Inside virsh edit XML description of the device specifying address bus= device= for each device (virt-manager does not differentiate them) The XML should end like this:

<hostdev mode='subsystem' type='usb' managed='yes'>
      <source>
        <address bus='002' device='005'/>
      </source>
</hostdev>
<hostdev mode='subsystem' type='usb' managed='yes'>
      <source>
        <address bus='002' device='006'/>
      </source>
</hostdev>

4) use virsh dumpxml <domain-id> and see the hostdev tag

Actual results:

Both devices have same bus and device, and inside the guest only /dev/ttyUSB0 is present.

Expected results:

Each device should respect the configured values in step 3 and in the guest there should be two devices i.e. /dev/ttyUSB0 and /dev/ttyUSB1

======== test case end ========

5. Regression potential: Only usb-related code should be affected, and all qa-regression-tests passed with this fix.
============================

[Ken (ken-redhat-bugs)]

+++ This bug was initially created as a clone of Bug #815755 +++

Description of problem:

Version-Release number of selected component (if applicable):

How reproducible: 100%

Steps to Reproduce:
1. Take 2 RSA Tokens and connect them to a hypervisor
2. Use lsusb -v to find a uniquely identifyable property of each device
3. Either
a) use virt-manager to attach the device with highest bus:device address to a guest
OR
b) write an XML description of the device specifying address bus= device= for the highest numbered RSA token
# virsh attach-device <domain-id> <xml-file>
4) use virsh dumpxml <domain-id> and see which device is actually attached to the guest

Actual results:

The device with the lowest bus:device address and matching vendor:product id is attached to the guest

Expected results:

The device specified by the address bus= device= in the XML, or the device selected in the virt-manager GUI should be attached to the guest

Additional info:

In order to confirm the wrong device is attached, login to the guest and run lsusb -v and search for the uniquely identifyable property of the device.

e.g. my RSA Token has bMaxPacketSize0 = 64, but for many of my colleagues it is 32.

[Ken (ken-redhat-bugs)]

Suggested fix ...

$ diff src/qemu/qemu_hostdev.c src/qemu/qemu_hostdev-modified.c
597,599c597,613
< usbDevice *usb
< = usbFindDevice(hostdev->source.subsys.u.usb.vendor,
< hostdev->source.subsys.u.usb.product);
---
> if (hostdev->source.subsys.u.usb.bus) {
> usbDevice *usb
> = usbGetDevice(hostdev->source.subsys.u.usb.bus,
> hostdev->source.subsys.u.usb.device);
> if ((hostdev->source.subsys.u.usb.vendor != usb->vendor) ||
> (hostdev->source.subsys.u.usb.product != usb->product)) {
> qemuReportError(VIR_ERR_OPERATION_INVALID,
> _("USB device %s does not match vendor product id"),
> usbDeviceGetName(tmp));
> usbFreeDevice(usb);
> goto cleanup;
> }
> } else {
> usbDevice *usb
> = usbFindDevice(hostdev->source.subsys.u.usb.vendor,
> hostdev->source.subsys.u.usb.product);
> }

[Gunannan (gunannan-redhat-bugs)]

The patch has been pushed in upstream. So I set it to POST
https://www.redhat.com/archives/libvir-list/2012-May/msg00289.html

[Cole (cole-redhat-bugs)]

Fixed in currentrelease

[Serge Hallyn (serge-hallyn)]

(Due to upcoming 12.04.2 release on Feb 14, I've marked this to work on it on Feb 15)

[Mariano Dupont (marianomd)]

Is there any way I can download source and compile the fixed version in precise? Any hint welcome, thanks.

[Serge Hallyn (serge-hallyn)]

Yes, you can

pull-lp-source libvirt # to get the current raring source
cd libvirt-*
dpkg-checkbuilddeps debian/control # apt-get install anything missing
dpkg -i # add a changelog entry with appropriate version
debian/rules build && fakeroot debian/rules binary
# or, instead of last command
debuild -S; cd ..; dput ppa:your/ppa *.changes

However, this bug is on a list of bugs which I intend to fix in precise-proposed and quantal-proposed this week.

[Mariano Dupont (marianomd)]

Thanks a lot Serge, almost there, but failed with:

Expected symbol virNetTLSContextNewClientPath is not in ELF library
Expected symbol virNetServerClientGetTLSKeySize is not in ELF library
Expected symbol virNetTLSContextNewClient is not in ELF library
Expected symbol virNetTLSSessionNew is not in ELF library
Expected symbol virNetServerClientHasTLSSession is not in ELF library
Expected symbol virNetServerSetTLSContext is not in ELF library
Expected symbol virNetTLSSessionHandshake is not in ELF library
Expected symbol virNetTLSContextNewServer is not in ELF library
Expected symbol virNetTLSSessionSetIOCallbacks is not in ELF library
Expected symbol virNetTLSInit is not in ELF library
Expected symbol virNetTLSSessionGetHandshakeStatus is not in ELF library
Expected symbol virNetTLSSessionWrite is not in ELF library
Expected symbol virNetTLSSessionGetKeySize is not in ELF library
Expected symbol virNetTLSContextCheckCertificate is not in ELF library
Expected symbol virNetSocketSetTLSSession is not in ELF library
Expected symbol virNetClientSetTLSSession is not in ELF library
Expected symbol virNetTLSContextNewServerPath is not in ELF library
Expected symbol virNetServerServiceGetTLSContext is not in ELF library
Expected symbol virNetTLSSessionRead is not in ELF library
Expected symbol virNetClientGetTLSKeySize is not in ELF library
make[4]: *** [check-symfile] Error 1
make[4]: Leaving directory `/home/mdupont/libvirt-1.0.2/debian/build/src'
make[3]: *** [check-am] Error 2
make[3]: Leaving directory `/home/mdupont/libvirt-1.0.2/debian/build/src'
make[2]: *** [check] Error 2
make[2]: Leaving directory `/home/mdupont/libvirt-1.0.2/debian/build/src'
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory `/home/mdupont/libvirt-1.0.2/debian/build'
make: *** [debian/stamp-makefile-check] Error 2

[Serge Hallyn (serge-hallyn)]

@Mariano,

could you please write a test case in the Description for the SRU?

[Mariano Dupont (marianomd)]

@Serge,

that would be the steps to reproduce the bug? Or is it something else?

[Serge Hallyn (serge-hallyn)]

@Mariano,

yes, please, steps to reproduce so that anyone can walk in and verify that the bug is fixed in precise-proposed.

[Serge Hallyn (serge-hallyn)]

Thanks!

[Chris Halse Rogers (raof)]

Hello Mariano, or anyone else affected,

Accepted libvirt into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/libvirt/0.9.8-2ubuntu17.8 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Mariano Dupont (marianomd)]

Hello Serge, it worked flawlessly.

To test it I did the following steps:

1) Added poposed repository line in sources.list of hypervisor:
deb http://archive.ubuntu.com/ubuntu/ precise-proposed restricted main multiverse universe

2) Kept back other proposed packages adding the following in /etc/apt/preferences.d/proposed

Package: *
Pin: release a=precise-security
Pin-Priority: 990

Package: *
Pin: release a=precise-updates
Pin-Priority: 900

Package: *
Pin: release a=precise-proposed
Pin-Priority: 400

3) apt-get update && apt-get upgrade

4) apt-get install libvirt-bin/precise-proposed libvirt0/precise-proposed

5) Stopped VM, edited config in virsh adding 6 USB devices:

    <hostdev mode='subsystem' type='usb' managed='yes'>
      <source>
        <vendor id='0x067b'/>
        <product id='0x2303'/>
        <address bus='2' device='4'/>
      </source>
    </hostdev>
    <hostdev mode='subsystem' type='usb' managed='yes'>
      <source>
        <vendor id='0x067b'/>
        <product id='0x2303'/>
        <address bus='2' device='5'/>
      </source>
    </hostdev>
    <hostdev mode='subsystem' type='usb' managed='yes'>
      <source>
        <vendor id='0x067b'/>
        <product id='0x2303'/>
        <address bus='2' device='6'/>
      </source>
    </hostdev>
    <hostdev mode='subsystem' type='usb' managed='yes'>
      <source>
        <vendor id='0x067b'/>
        <product id='0x2303'/>
        <address bus='2' device='7'/>
      </source>
    </hostdev>
    <hostdev mode='subsystem' type='usb' managed='yes'>
      <source>
        <vendor id='0x067b'/>
        <product id='0x2303'/>
        <address bus='2' device='8'/>
      </source>
    </hostdev>
    <hostdev mode='subsystem' type='usb' managed='yes'>
      <source>
        <vendor id='0x067b'/>
        <product id='0x2303'/>
        <address bus='2' device='9'/>
      </source>
    </hostdev>

6) Restarted the VM, and it detects all of them:

Bus 001 Device 002: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Bus 001 Device 004: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Bus 001 Device 005: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Bus 001 Device 006: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Bus 001 Device 007: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Bus 001 Device 008: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port

Thanks a lot!

[Brian Murray (brian-murray)]

The verification of this Stable Release Update has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

[Launchpad Janitor (janitor)]

This bug was fixed in the package libvirt - 0.9.8-2ubuntu17.8

---------------
libvirt (0.9.8-2ubuntu17.8) precise-proposed; urgency=low

  [ Adam Conrad ]
  * libvirt-bin.postinst: also put admin group members into the libvirtd
    group, to support systems installed before precise. (LP: #1124127)
  * libvirt-bin.postinst: use getent group instead of grep /etc/group

  [ Serge Hallyn ]
  * Update README.Debian:
    - we use libvirtd, not libvirt group (LP: #1095140)
    - we add users from sudo, not admin group, to libvirtd.
  * Handle two usb devices with same vendor/id (LP: #1082213)
    - ubuntu/qemu-Keep-list-of-USB-devices-attached-to-domains
    - ubuntu/usb-create-functions-to-search-usb-device
    - ubuntu/qemu-call-usb-search-function-for-hostdev

  [ Andres Lagar-Cavilla ]
  * Add RESUME event listener to qemu monitor (LP: #1097824)
    - ubuntu/handle_resume.patch

  [ Kirill Zaborsky ]
  * Add proper handling for EINTR signal (LP: #1092826)
    - ubuntu/fix-poll.patch
 -- Serge Hallyn <email address hidden> Thu, 21 Feb 2013 08:38:35 -0600

[Bill Mills (wmills)]

This feature appears to cause a bug.
To reproduce attach-device to a virtual machine and then stop that vm
Start another vm and try to attach-device to that machine
I get:
virsh attach-device vm1 /var/lib/libvirt/hotplug/usb-serial.xml
error: Failed to attach device from /var/lib/libvirt/hotplug/usb-serial.xml
error: Requested operation is not valid: USB device 002:005 is in use by domain ..

usb-serial:
    <hostdev mode='subsystem' type='usb' managed='yes'>
      <source>
        <vendor id='0x067b'/>
        <product id='0x2303'/>
      </source>
    </hostdev>

backing up libvirt0 and libvirt-bin to 0.9.8-2ubuntu17.7 makes this problem go away.

While looking at this I found a Fedora bug that looks similar. The upstream patches they identified may be of interest.
https://bugzilla.redhat.com/show_bug.cgi?id=814866

[Serge Hallyn (serge-hallyn)]

Quoting Bill Mills (<email address hidden>):
> This feature appears to cause a bug.
> To reproduce attach-device to a virtual machine and then stop that vm
> Start another vm and try to attach-device to that machine
> I get:
> virsh attach-device vm1 /var/lib/libvirt/hotplug/usb-serial.xml
> error: Failed to attach device from /var/lib/libvirt/hotplug/usb-serial.xml
> error: Requested operation is not valid: USB device 002:005 is in use by domain ..
>
> usb-serial:
> <hostdev mode='subsystem' type='usb' managed='yes'>
> <source>
> <vendor id='0x067b'/>
> <product id='0x2303'/>
> </source>
> </hostdev>
>
> backing up libvirt0 and libvirt-bin to 0.9.8-2ubuntu17.7 makes this
> problem go away.
>
> While looking at this I found a Fedora bug that looks similar. The upstream patches they identified may be of interest.
> https://bugzilla.redhat.com/show_bug.cgi?id=814866

Could you please open a new bug for this? We can't re-use
this bug for a new SRU of new patches.

[Bill Mills (wmills)]

New bug report created as (LP: #1190387)