Keksgesicht

yes. it should be. there is now a /etc/modprobe.d/bluetooth.conf with the same content as I descriped in my workaround.

The solution is a lot simpler. Linux (unRaid) is somehow blocking the device on the host. I found out that you can unload the bluetooth drivers and it works now inside the VM. modprobe -r btusb modprobe -r bluetooth If you want that it persistent between reboot, you have to blacklist these drivers. Normally it is /etc/modprobe.d/ but unRaid does not replace the initial root filesystem (initrd / rootfs) with a block device so changes where are not persistent. In some other forum thread a found something like this for unRaid. (not tested because my system is still running) mkdir /boot/config/modprobe.d/ echo -e 'blacklist btusb\nblacklist bluetooth' > /boot/config/modprobe.d/bluetooth.conf If you still need bluetooth on the host for some docker container. It is probably needed to load the drivers again when the VM isn't running. modprobe btusb modprobe bluetooth

I'm in the same situation. Onboard USB Bluetooth Controller (with Wifi). Passing through only the USB device was enough to get it working. (8087:0aa7 Intel Corp. Wireless-AC 3168 Bluetooth) cookietower is the unRaid host and cookierunner is my Manjaro VM. I just searched for a date before the upgrade. The other logs are the same except for the date. 04 Aug is before the update (6.9.2) und today (22 Aug) is after the update (6.10.0-rc1). Aug 4 10:52:39 cookietower kernel: Bluetooth: Core ver 2.22 Aug 4 10:52:39 cookietower kernel: Bluetooth: HCI device and connection manager initialized Aug 4 10:52:39 cookietower kernel: Bluetooth: HCI socket layer initialized Aug 4 10:52:39 cookietower kernel: Bluetooth: L2CAP socket layer initialized Aug 4 10:52:39 cookietower kernel: Bluetooth: SCO socket layer initialized Aug 4 10:52:39 cookietower kernel: Bluetooth: hci0: read Intel version: 370810225019140f38 Aug 4 10:52:39 cookietower kernel: Bluetooth: hci0: Intel device is already patched. patch num: 38 Aug 04 10:55:02 cookierunner NetworkManager[548]: <info> [1628067302.5320] Loaded device plugin: NMBluezManager (/usr/lib/NetworkManager/1.32.4-1/libnm-device-plugin-bluetooth.so) Aug 04 10:55:03 cookierunner kernel: Bluetooth: Core ver 2.22 Aug 04 10:55:03 cookierunner kernel: Bluetooth: HCI device and connection manager initialized Aug 04 10:55:03 cookierunner kernel: Bluetooth: HCI socket layer initialized Aug 04 10:55:03 cookierunner kernel: Bluetooth: L2CAP socket layer initialized Aug 04 10:55:03 cookierunner kernel: Bluetooth: SCO socket layer initialized Aug 04 10:55:03 cookierunner kernel: Bluetooth: hci0: read Intel version: 370810225019140f38 Aug 04 10:55:03 cookierunner kernel: Bluetooth: hci0: Intel device is already patched. patch num: 38 Aug 04 10:55:03 cookierunner systemd[1]: Starting Bluetooth service... Aug 04 10:55:03 cookierunner bluetoothd[875]: Bluetooth daemon 5.60 Aug 22 10:01:53 cookietower kernel: Bluetooth: Core ver 2.22 Aug 22 10:01:53 cookietower kernel: Bluetooth: HCI device and connection manager initialized Aug 22 10:01:53 cookietower kernel: Bluetooth: HCI socket layer initialized Aug 22 10:01:53 cookietower kernel: Bluetooth: L2CAP socket layer initialized Aug 22 10:01:53 cookietower kernel: Bluetooth: SCO socket layer initialized Aug 22 10:01:53 cookietower kernel: Bluetooth: hci0: read Intel version: 370810225019140f00 Aug 22 10:01:53 cookietower kernel: Bluetooth: hci0: Intel Bluetooth firmware file: intel/ibt-hw-37.8.10-fw-22.50.19.14.f.bseq Aug 22 10:01:53 cookietower kernel: Bluetooth: hci0: Intel BT fw patch 0x42 completed & activated Aug 22 10:03:31 cookietower kernel: Bluetooth: hci0: read Intel version: 370810225019140f00 Aug 22 10:03:31 cookietower kernel: Bluetooth: hci0: Intel Bluetooth firmware file: intel/ibt-hw-37.8.10-fw-22.50.19.14.f.bseq Aug 22 10:03:32 cookietower kernel: Bluetooth: hci0: Intel BT fw patch 0x42 completed & activated Aug 22 10:03:46 cookierunner NetworkManager[564]: <info> [1629619426.8626] Loaded device plugin: NMBluezManager (/usr/lib/NetworkManager/1.32.8-1/libnm-device-plugin-bluetooth.so) Aug 22 10:03:47 cookierunner kernel: Bluetooth: Core ver 2.22 Aug 22 10:03:47 cookierunner kernel: Bluetooth: HCI device and connection manager initialized Aug 22 10:03:47 cookierunner kernel: Bluetooth: HCI socket layer initialized Aug 22 10:03:47 cookierunner kernel: Bluetooth: L2CAP socket layer initialized Aug 22 10:03:47 cookierunner kernel: Bluetooth: SCO socket layer initialized Aug 22 10:03:47 cookierunner systemd[1]: Starting Bluetooth service... Aug 22 10:03:49 cookierunner kernel: Bluetooth: hci0: command 0x0c03 tx timeout Aug 22 10:03:57 cookierunner kernel: Bluetooth: hci0: sending initial HCI reset command failed (-110) Aug 22 10:03:57 cookierunner bluetoothd[869]: Bluetooth daemon 5.60 Aug 22 10:03:57 cookierunner systemd[1]: Started Bluetooth service. Aug 22 10:03:57 cookierunner systemd[1]: Reached target Bluetooth Support. This "sending initial HCI reset command failed (-110)" is driving me crazy. Host: It shows up in lsusb on host and vm. VM: It is listed by rfkill and blocking and unblocking seems to work. bluetoothctl tells me "No default controller available".

I have tried to set this in my XML-File: https://specs.openstack.org/openstack/nova-specs/specs/train/approved/allow-secure-boot-for-qemu-kvm-guests.html <os firmware='efi'> <type arch='x86_64' machine='pc-q35-5.1'>hvm</type> <loader secure='yes'/> </os> But now I am missing the template nvram file: /usr/share/qemu/edk2-i386-vars.fd Probably configured through: /usr/share/qemu/firmware/50-edk2-x86_64-secure.json Using the existing nvram file of the VM just turns all cores asigned to the VM to 100% and a black screen. Nothing special in the log.

I compiled QEMU 5.2 myself and it works amazing with your custom script. It is a lot faster than 9p and it also "works" with a Windows VM. For Linux VMs this works perfectly fine and haven't any issues that I had with 9p or NFS.

Hey, I have a btrfs raid1 pool with 3 disks. root@tower:~$ btrfs fi show /mnt/cache/ Label: none uuid: a4b126da-bb61-bbb4-471d-034266f28ea1 Total devices 3 FS bytes used 783.17GiB devid 1 size 931.51GiB used 511.03GiB path /dev/sdc1 devid 2 size 931.51GiB used 510.00GiB path /dev/sdb1 devid 3 size 1.82TiB used 1021.03GiB path /dev/nvme0n1p1 Is it possible to replace the 2 1TB with a new 2TB? I tried to read https://btrfs.wiki.kernel.org/index.php/Using_Btrfs_with_Multiple_Devices#Using_btrfs_replace, but I am not sure if it is possible to replace two disks with only one in a single operation. Also does it confuse the UnRaid GUI or does the WebGUI also support such operations?

I saw that Unraid 6.9 will exclude the Controller of the boot USB in "System Devices". That's is really helpfull. But I have an UPS attached via USB and I don't see any reason why this couldn't be an option to exclude too. The VMs are not able to shutdown the system then needed. This could also be a solution for me using dlandon/libvirt.hotplug.usb. He is using your getValidUSBDevices() in /usr/local/emhttp/plugins/dynamix.vm.manager/include/libvirt_helpers.php If your think excluding the UPS is overkill. Maybe just find a way that we can add a blacklist for certain USB devices.

ok, I created new XML templates and copied my custom changes like iothreads assingment and USB controller throughpassing into these templates. Now it's working. Maybe something in the nvram that the newer version of QEMU didn't expected. Also I want to add: I only tested VNC on my Ubuntu VM when I wrote my first comment. So it's maybe some problem related to Windows? I hope my problem is solved and I only have to reenable MSI inside the VMs.

These are normal Windows 10 installations 1909 with EFI boot mode and Q35 chipset. The primary VM has one USB Controller passed through. I noticed the missing files myself in the logs and found them in one of my unused VM XML templates. The VMs presenting the Windows boot logo. 10 seconds later the image freezes, blackouts, GPU fans stopping for a second and windows logo again. This keeps going on until I destroy the VM. The second VM only blackouts after 10 seconds but the monitor backlight keeps on. So the OS is still alive? Windows never tried to enter rescue mode. I heard about problems with AMD CPUs but I only had to add amd_iommu=on to the kernel parameters. With UnRaid 6.7.2 and 6.8.0 this all wasn't any problem. Maybe I libvirt or QEMU developer knows something about my problem. I will test your ideas later Did something changed in a prerelease version that I could test? Or should I upload my 6.8.0 diagnostics for comparison?

ok, I removed the Kernel parameter to drop the framebuffer (couldn't install drivers inside the VM without it on Host EFI boot), switched from EFI to legacy boot mode and even started the server in "safe mode" (no plugins running) with version 6.8.2. The Problem still occurs. The problem is not limited to the primary GPU. With VNC I didn't noticed any problems. But when I roll back to 6.8.0 the passthrough works again. What has changed in libvirt with the last updates? cookietower-diagnostics-20200207-1842.zip