Bug 1850091 - libvirt.libvirtError: internal error: vendor cannot be 0.
Summary: libvirt.libvirtError: internal error: vendor cannot be 0.
Keywords:
Status: CLOSED DUPLICATE of bug 1897625
Alias: None
Product: Fedora
Classification: Fedora
Component: libvirt
Version: 32
Hardware: Unspecified
OS: Unspecified
unspecified
urgent
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-06-23 14:13 UTC by Todd
Modified: 2020-12-19 10:25 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-12-14 18:49:39 UTC
Type: Bug


Attachments (Terms of Use)
KVM-W10.xml (4.49 KB, text/html)
2020-06-29 09:29 UTC, Todd
no flags Details
vir manager log (2.39 KB, text/plain)
2020-06-30 02:02 UTC, Todd
no flags Details
nodedev lsit (4.63 KB, text/plain)
2020-06-30 22:55 UTC, Todd
no flags Details
nodedev list with w10 installation flash drive inserted (5.04 KB, text/plain)
2020-06-30 22:58 UTC, Todd
no flags Details

Description Todd 2020-06-23 14:13:44 UTC
Fedora32 x64
qemu-kvm-4.2.0-7.fc32.x86_64
libvirt-daemon-6.4.0-1.fc32.x86_64

virt-manager won't accept a WoeUSB created Windows 10 installation flash drive.  (The flash drive does boot natively.):


Error adding device: internal error: vendor cannot be 0.

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/addhardware.py", line 1351, in _add_device
    self.vm.add_device(dev)
  File "/usr/share/virt-manager/virtManager/object/domain.py", line 408, in add_device
    self._redefine_xmlobj(xmlobj)
  File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line 417, in _redefine_xmlobj
    self._redefine_xml_internal(origxml, newxml)
  File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line 395, in _redefine_xml_internal
    self._define(newxml)
  File "/usr/share/virt-manager/virtManager/object/domain.py", line 999, in _define
    self.conn.define_domain(xml)
  File "/usr/share/virt-manager/virtManager/connection.py", line 612, in define_domain
    return self._backend.defineXML(xml)
  File "/usr/lib64/python3.8/site-packages/libvirt.py", line 4048, in defineXML
    if ret is None:raise libvirtError('virDomainDefineXML() failed', conn=self)
libvirt.libvirtError: internal error: vendor cannot be 0.

Comment 1 Richard W.M. Jones 2020-06-29 09:13:30 UTC
Can you dump out the libvirt XML of this guest, something like:

virsh dumpxml <name-of-guest>

Comment 2 Todd 2020-06-29 09:29:48 UTC
Created attachment 1699097 [details]
KVM-W10.xml

xml file as requested

Comment 3 Richard W.M. Jones 2020-06-29 10:17:39 UTC
I had a chat with the libvirt developers and we think the actual log
file we need is virt-manager.log which is in ~/.cache/virt-manager/virt-manager.log
if you ran virt-manager as an ordinary user
(https://fedoraproject.org/wiki/How_to_debug_Virtualization_problems#Virt_Manager)

Comment 4 Todd 2020-06-30 02:02:20 UTC
Created attachment 1699225 [details]
vir manager log

virt manager log as requested

Comment 5 Daniel Berrangé 2020-06-30 09:04:00 UTC
The log clearly shows virt-manager is providing bogus XML input

[Mon, 29 Jun 2020 18:58:46 virt-manager 79402] DEBUG (addhardware:1303) Adding device:
<hostdev mode="subsystem" type="usb" managed="yes">
  <source>
    <vendor id="0x0000"/>
    <product id="0x0000"/>
  </source>
</hostdev>

[Mon, 29 Jun 2020 18:58:46 virt-manager 79402] DEBUG (libvirtobject:57) Redefining <vmmDomain name=KVM-W10 id=0x7ff40c219f80> with XML diff:
--- Original XML
+++ New XML
@@ -119,5 +119,11 @@
     <memballoon model="virtio">
       <address type="pci" domain="0x0000" bus="0x00" slot="0x07" function="0x0"/>
     </memballoon>
+    <hostdev mode="subsystem" type="usb" managed="yes">
+      <source>
+        <vendor id="0x0000"/>
+        <product id="0x0000"/>
+      </source>
+    </hostdev>
   </devices>
 </domain>


The question is where is it getting this information from, as it might not be virt-manager's fault in te root cause.

Comment 6 Cole Robinson 2020-06-30 15:44:20 UTC
Todd can you run this and attach the output:

for i in `sudo virsh nodedev-list --cap usb_device` ; do sudo virsh nodedev-dumpxml $i; done

Comment 7 Todd 2020-06-30 22:55:23 UTC
Created attachment 1699395 [details]
nodedev lsit

nodedev list as requested

Comment 8 Todd 2020-06-30 22:58:33 UTC
Created attachment 1699396 [details]
nodedev list with w10 installation flash drive inserted

I occurred to me, it would be helpful to run the same test over again with the W10 installation flash drive inserted

Comment 9 Todd 2020-06-30 22:59:57 UTC
With the W10 installation flash drive inserted:

<device>
  <name>usb_2_1_2</name>
  <path>/sys/devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1.2</path>
  <devnode type='dev'>/dev/bus/usb/002/003</devnode>
  <parent>usb_2_1</parent>
  <driver>
    <name>usb</name>
  </driver>
  <capability type='usb_device'>
    <bus>2</bus>
    <device>3</device>
    <product id='0x0000'>FlashBlu</product>
    <vendor id='0x0000'>Kanguru</vendor>
  </capability>

Comment 10 Daniel Berrangé 2020-07-01 09:39:57 UTC
(In reply to Todd from comment #9)
> With the W10 installation flash drive inserted:
> 

>   <capability type='usb_device'>
>     <bus>2</bus>
>     <device>3</device>
>     <product id='0x0000'>FlashBlu</product>
>     <vendor id='0x0000'>Kanguru</vendor>
>   </capability>

Yeah that's a big problem.

Can you tell us what udev reports for the USB device path eg

$ udevadm info /dev/bus/usb/002/003

(or whatever its current path is when you plug it in again)

Comment 11 Todd 2020-07-06 08:33:05 UTC
# udevadm info /dev/bus/usb/001/007
P: /devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1.2
N: bus/usb/001/007
L: 0
E: DEVPATH=/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1.2
E: DEVNAME=/dev/bus/usb/001/007
E: DEVTYPE=usb_device
E: DRIVER=usb
E: PRODUCT=1e1d/1106/110
E: TYPE=0/0/0
E: BUSNUM=001
E: DEVNUM=007
E: MAJOR=189
E: MINOR=6
E: SUBSYSTEM=usb
E: USEC_INITIALIZED=45895670476
E: ID_VENDOR=Kanguru
E: ID_VENDOR_ENC=Kanguru
E: ID_VENDOR_ID=1e1d
E: ID_MODEL=FlashBlu
E: ID_MODEL_ENC=FlashBlu
E: ID_MODEL_ID=1106
E: ID_REVISION=0110
E: ID_SERIAL=Kanguru_FlashBlu_070894810E20BD74
E: ID_SERIAL_SHORT=070894810E20BD74
E: ID_BUS=usb
E: ID_USB_INTERFACES=:080650:
E: ID_VENDOR_FROM_DATABASE=Kanguru Solutions
E: ID_PATH=pci-0000:00:14.0-usb-0:1.2
E: ID_PATH_TAG=pci-0000_00_14_0-usb-0_1_2

Comment 12 Todd 2020-11-02 00:06:11 UTC
$ rpm -qa qemu-kvm
qemu-kvm-4.2.1-1.fc32.x86_64

This has become critical for me now.  Would you please jump on this?

Many thanks,
-T

Comment 13 Todd 2020-11-06 21:19:58 UTC
 Fedora 32

   $ rpm -qa virt-manager
   virt-manager-3.1.0-1.fc32.noarch

   $ rpm -qa qemu-device-usb-redirect
   qemu-device-usb-redirect-5.1.0-7.fc32.x86_64

This is a Samsung BAR flash drive:

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/addhardware.py", line 1289, in _finish_cb
    failure = self._add_device(dev)
  File "/usr/share/virt-manager/virtManager/addhardware.py", line 1281, in _add_device
    self.vm.add_device(dev)
  File "/usr/share/virt-manager/virtManager/object/domain.py", line 580, in add_device
    self._redefine_xmlobj(xmlobj)
  File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line 383, in _redefine_xmlobj
    self._redefine_xml_internal(origxml, newxml)
  File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line 366, in _redefine_xml_internal
    self._define(newxml)
  File "/usr/share/virt-manager/virtManager/object/domain.py", line 1065, in _define
    self.conn.define_domain(xml)
  File "/usr/share/virt-manager/virtManager/connection.py", line 554, in define_domain
    return self._backend.defineXML(xml)
  File "/usr/lib64/python3.8/site-packages/libvirt.py", line 4361, in defineXML
    raise libvirtError('virDomainDefineXML() failed')
libvirt.libvirtError: internal error: vendor cannot be 0.

This is the info on the drive:

$ udevadm info /dev/bus/usb/002/005
P: /devices/pci0000:00/0000:00:14.0/usb2/2-4
N: bus/usb/002/005
L: 0
E: DEVPATH=/devices/pci0000:00/0000:00:14.0/usb2/2-4
E: DEVNAME=/dev/bus/usb/002/005
E: DEVTYPE=usb_device
E: DRIVER=usb
E: PRODUCT=90c/1000/1100
E: TYPE=0/0/0
E: BUSNUM=002
E: DEVNUM=005
E: MAJOR=189
E: MINOR=132
E: SUBSYSTEM=usb
E: USEC_INITIALIZED=13609827609
E: ID_VENDOR=Samsung
E: ID_VENDOR_ENC=Samsung
E: ID_VENDOR_ID=090c
E: ID_MODEL=Flash_Drive
E: ID_MODEL_ENC=Flash\x20Drive
E: ID_MODEL_ID=1000
E: ID_REVISION=1100
E: ID_SERIAL=Samsung_Flash_Drive_0327918050002584
E: ID_SERIAL_SHORT=0327918050002584
E: ID_BUS=usb
E: ID_USB_INTERFACES=:080650:
E: ID_VENDOR_FROM_DATABASE=Silicon Motion, Inc. - Taiwan (formerly Feiya Technology Corp.)
E: ID_MODEL_FROM_DATABASE=Flash Drive
E: ID_PATH=pci-0000:00:14.0-usb-0:4
E: ID_PATH_TAG=pci-0000_00_14_0-usb-0_4

Comment 14 Todd 2020-11-07 03:32:23 UTC
New info.  ALL of my flash drive are now doing this

Comment 15 Todd 2020-11-07 08:18:49 UTC
If it helps, I came up with a workaround:

$ lsusb | grep -i silico
Bus 002 Device 006: ID 090c:1000 Silicon Motion, Inc. - Taiwan (formerly Feiya Technology Corp.) Flash Drive

# virt-xml KVM-USB-EUFI  --add-device --hostdev 002.006
Domain 'KVM-USB-EUFI' defined successfully.


XML file now looks like:

    <hostdev mode='subsystem' type='usb' managed='yes'>
      <source>
        <vendor id='0x090c'/>
        <product id='0x1000'/>
      </source>
      <boot order='1'/>
      <address type='usb' bus='0' port='4'/>
    </hostdev>

Comment 16 Todd 2020-11-08 02:15:53 UTC
6.6.0-3.fc33.x86_64

just hit and that fixed it.  Thank you!

Comment 17 Todd 2020-11-08 02:52:25 UTC
It as probably this fix the did the trick:

$ rpm -qa qemu-device-usb-redirect
qemu-device-usb-redirect-5.1.0-5.fc33.x86_64

Comment 18 Sally A. Haj 2020-12-14 00:12:42 UTC
I face the same issue while adding a USB flash drive, "Unable to add device: internal error: vendor cannot be 0."
I am using Fedora 33 with latest updated packages.

Comment 19 Sally A. Haj 2020-12-14 01:38:54 UTC
Even when I try to add it through the terminal "virt-xml fedora32_server --add-device --hostdev 002.010" it says "ERROR    internal error: vendor cannot be 0"
By the way I have USB 2

Comment 20 Cole Robinson 2020-12-14 18:49:39 UTC
This bug is filed against fedora 32, but AFAICT the f32 version of libvirt should not be affected. The original reporter appeared to be using a newer libvirt, maybe one from virt-preview.

Fedora 33 updates-testing should have a fixed libvirt, duping to the f33 bug

*** This bug has been marked as a duplicate of bug 1897625 ***


Note You need to log in before you can comment on or make changes to this bug.