Can you dump out the libvirt XML of this guest, something like:

virsh dumpxml <name-of-guest>

Created attachment 1699097 [details]
KVM-W10.xml

xml file as requested

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)

Created attachment 1699225 [details]
vir manager log

virt manager log as requested

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.

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

Created attachment 1699395 [details]
nodedev lsit

nodedev list as requested

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

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>

(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)

# 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

$ 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

 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

New info.  ALL of my flash drive are now doing this

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>

6.6.0-3.fc33.x86_64

just hit and that fixed it.  Thank you!

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

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.

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

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 ***