Comment 3 for bug 1988504

Just to help others reading this "rpc-libvirtd: debugfs access is restricted" is bug 1957924 and a non critical (noise, but not breaking) issue. You can ignore any of these (at least that was the assumption so far.

In dmesg we have no usual suspects (apparmor denials for example:
We only see the device "coming back to the host" without much info about an issue.
Maybe this one:
  usb 2-3.4: usbfs: interface 0 claimed by r8152 while 'qemu-system-x86' sets config #1

That is a conflict between the host r8152 driver and qemu.

In the libvirt log we see that libvirt fails because it can not set the config as being busy.
2022-09-08T09:36:23.331793Z qemu-system-x86_64: libusb_set_configuration: -6 [BUSY]

That could match to the above dmesg entry of a fight between host driver and qemu.

I do not know if the host changed behavior in how hard it hold onto this device.
But instead of hot-plugging it back and forth we could try releasing it from the host a bit more before attaching it to the guest.
Then you can try to move it to the guest and see if it works now.
(Of course if you need it in host and guest we will eventually need to sort out how to do this more smoothly).

So I wonder, if yo'd be ok (if you do not need the driver for something else) to try on the host to blacklist that driver.
0. blacklist on the host
 $ echo "blacklist r8152" > /etc/modprobe.d/lp-1988504-avoid-hostdrivers.conf
 $ echo "blacklist cdc_ether" >> /etc/modprobe.d/lp-1988504-avoid-hostdrivers.conf
 # not sure if this is loaded by initramfs (surely not if unplugged) but to be sure
 $ sudo update-initramfs -u
1. Unplug your USB network device
2. Reboot
3. Plug in your USB network
4. Check lsmod, it should not more have r8152 or cdc_ether loaded on the host
5. now start your guest
6. set up the log watches again
7. try to attach the USB dev

Let me know if that gets you any further