bastl

@jbrodriguez Damn it, it always confuses me. Selecting 443 as port and the login as root and it is working. But how do I connect as a none root user now? In the web UI the permission configuration for some dockers and VMs are set to "read" and "exec" for a specific user, but the login in doesn't work for that user in the app. Username and password is the one which is set up in Unraids user settings, right? I remember it worked in older builds besides some strange issues with the checkboxes jumping around. I've reported that issue to you couple weeks ago. Now the mini game is gone but only root can login. 🤨 The permission I've set are now visible in the description of that specific user in Unraids user management. Not sure if it's supposed to be that way.

@jbrodriguez I've updated the unraid plugin and the android app and I can't add a server in the app. Open webui leads me to the webinterface as normal. Accessible via IP or local domain name. Port automatically switches to 2379 in the browser. Login as root is working. On my phone I put in the IP of Unraid the port 2378 specified in the plugin, root and password and it doesn't add the server. Discover also brings up no server. Same for turning on/off https in the app or changing the port to 2379. Entering the local domain name, same issue. Edit: Webinterface is accessible from my phone

@ken-ji Thanks. It looks like it's working. I'am having another virbr up and used by a pfsense VM and a Windows VM. Pfsense acts as a torproxy for the VM and Windows has access to the internet and hasn't any access to the lan services Unraid provides. The question is, how do I make the virbr persistent, so it survives a Unraid restart? Is there a config file somewhere on the flash device where I have to put the bridge settings in? I can't really find anything where the virbr0 is configured in.

Finally 😂

I don't get it. Same hardware, same Unraid version. You switched to 6.7_RC5/6 right? The only thing i noticed in your xml is that you put the device on bus='0x00'. I always had it on a higher bus number. <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> BIOS version is also the latest I guess, right? I'am on P3.30.

Are you booting Unraid in Legacy or UEFI Mode?

Is it possible to create an virtual nic somehow that is only for internal use and not like the virbr0 in a NAT network behind the actual Unraid network? Having a VM using the virbr0 even if it's on it's own network still can see devices and shares behind the NAT. That's not what I want. I couldn't find any solutions on the forum for this. All I've found are the suggestions to use the virbr, but thats completly agains the idea of an separated isolated network. Vmware, Virtualbox, XCP-NG all have such an feature build in. Did I miss something? The goal is to be able to create VMs for testing without any access to the outside. Only talking to each other. Maybe have an Pfsense VM also having access to that internal only network to handle DHCP and to monitor web traffic. I don't want a solution where I have to change some settings inside the VMs to permit access to the outside. Manual configuring the network to maybe set it to a wrong gateway for example isn't a solution. Highly appreciated for any suggestions.

I quickly have set up a i440fx VM as described before with the same result. As soon as I give the VM the "Intel Corp" USB device besides the Dual Wireless AC 3168 Controller and out of the box with a fresh windows install the controller works, wifi networks are visible and usable. Edit: xml attached <?xml version='1.0' encoding='UTF-8'?> <domain type='kvm'> <name>W10_i440fx_test</name> <uuid>fc794f27-b453-21ce-b011-bb5e9cd80222</uuid> <metadata> <vmtemplate xmlns="unraid" name="Windows 10" icon="windows.png" os="windows10"/> </metadata> <memory unit='KiB'>8388608</memory> <currentMemory unit='KiB'>8388608</currentMemory> <memoryBacking> <nosharepages/> </memoryBacking> <vcpu placement='static'>8</vcpu> <cputune> <vcpupin vcpu='0' cpuset='2'/> <vcpupin vcpu='1' cpuset='18'/> <vcpupin vcpu='2' cpuset='3'/> <vcpupin vcpu='3' cpuset='19'/> <vcpupin vcpu='4' cpuset='4'/> <vcpupin vcpu='5' cpuset='20'/> <vcpupin vcpu='6' cpuset='5'/> <vcpupin vcpu='7' cpuset='21'/> </cputune> <os> <type arch='x86_64' machine='pc-i440fx-3.1'>hvm</type> <loader readonly='yes' type='pflash'>/usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi.fd</loader> <nvram>/etc/libvirt/qemu/nvram/fc794f27-b453-21ce-b011-bb5e9cd80222_VARS-pure-efi.fd</nvram> </os> <features> <acpi/> <apic/> <hyperv> <relaxed state='on'/> <vapic state='on'/> <spinlocks state='on' retries='8191'/> <vendor_id state='on' value='none'/> </hyperv> </features> <cpu mode='host-passthrough' check='none'> <topology sockets='1' cores='8' threads='1'/> </cpu> <clock offset='localtime'> <timer name='hypervclock' present='yes'/> <timer name='hpet' present='no'/> </clock> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <devices> <emulator>/usr/local/sbin/qemu</emulator> <disk type='file' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source file='/mnt/user/VMs/Windows 10/vdisk1.img'/> <target dev='hdc' bus='virtio'/> <boot order='1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </disk> <disk type='file' device='cdrom'> <driver name='qemu' type='raw'/> <source file='/mnt/user/isos/Windows/Win10_Pro_x64_NTLite_UpdatesJan2019.iso'/> <target dev='hda' bus='ide'/> <readonly/> <boot order='2'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> <disk type='file' device='cdrom'> <driver name='qemu' type='raw'/> <source file='/mnt/user/isos/virtio-win-0.1.160-1.iso'/> <target dev='hdb' bus='ide'/> <readonly/> <address type='drive' controller='0' bus='0' target='0' unit='1'/> </disk> <controller type='pci' index='0' model='pci-root'/> <controller type='pci' index='1' model='pci-bridge'> <model name='pci-bridge'/> <target chassisNr='1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> </controller> <controller type='pci' index='2' model='pci-bridge'> <model name='pci-bridge'/> <target chassisNr='2'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/> </controller> <controller type='pci' index='3' model='pci-bridge'> <model name='pci-bridge'/> <target chassisNr='3'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/> </controller> <controller type='pci' index='4' model='pci-bridge'> <model name='pci-bridge'/> <target chassisNr='4'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x0b' function='0x0'/> </controller> <controller type='pci' index='5' model='pci-bridge'> <model name='pci-bridge'/> <target chassisNr='5'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x0c' function='0x0'/> </controller> <controller type='pci' index='6' model='pci-bridge'> <model name='pci-bridge'/> <target chassisNr='6'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x0d' function='0x0'/> </controller> <controller type='ide' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> </controller> <controller type='virtio-serial' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </controller> <controller type='usb' index='0' model='ich9-ehci1'> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x7'/> </controller> <controller type='usb' index='0' model='ich9-uhci1'> <master startport='0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0' multifunction='on'/> </controller> <controller type='usb' index='0' model='ich9-uhci2'> <master startport='2'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x1'/> </controller> <controller type='usb' index='0' model='ich9-uhci3'> <master startport='4'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x2'/> </controller> <interface type='bridge'> <mac address='52:54:00:88:7f:63'/> <source bridge='br0'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> <serial type='pty'> <target type='isa-serial' port='0'> <model name='isa-serial'/> </target> </serial> <console type='pty'> <target type='serial' port='0'/> </console> <channel type='unix'> <target type='virtio' name='org.qemu.guest_agent.0'/> <address type='virtio-serial' controller='0' bus='0' port='1'/> </channel> <input type='tablet' bus='usb'> <address type='usb' bus='0' port='1'/> </input> <input type='mouse' bus='ps2'/> <input type='keyboard' bus='ps2'/> <graphics type='vnc' port='-1' autoport='yes' websocket='-1' listen='0.0.0.0' keymap='de'> <listen type='address' address='0.0.0.0'/> </graphics> <video> <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1' primary='yes'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </video> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x05' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x06' slot='0x01' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='usb' managed='no'> <source> <vendor id='0x8087'/> <product id='0x0aa7'/> </source> <address type='usb' bus='0' port='2'/> </hostdev> <memballoon model='virtio'> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </memballoon> </devices> </domain>

Nothing stubbed. Only ACS override "both" selected. kernel /bzimage append isolcpus=8-15,24-31 pcie_acs_override=downstream,multifunction initrd=/bzroot I only manually added the following part <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x05' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/> </hostdev> and selected the "Intel Corp" USB device. And the VM xml i used to get it working. <?xml version='1.0' encoding='UTF-8'?> <domain type='kvm'> <name>W10_Q35_test</name> <uuid>1910a190-0555-c5e2-d334-f130de9f4a75</uuid> <metadata> <vmtemplate xmlns="unraid" name="Windows 10" icon="windows.png" os="windows10"/> </metadata> <memory unit='KiB'>8388608</memory> <currentMemory unit='KiB'>8388608</currentMemory> <memoryBacking> <nosharepages/> </memoryBacking> <vcpu placement='static'>8</vcpu> <cputune> <vcpupin vcpu='0' cpuset='2'/> <vcpupin vcpu='1' cpuset='18'/> <vcpupin vcpu='2' cpuset='3'/> <vcpupin vcpu='3' cpuset='19'/> <vcpupin vcpu='4' cpuset='4'/> <vcpupin vcpu='5' cpuset='20'/> <vcpupin vcpu='6' cpuset='5'/> <vcpupin vcpu='7' cpuset='21'/> </cputune> <os> <type arch='x86_64' machine='pc-q35-3.1'>hvm</type> <loader readonly='yes' type='pflash'>/usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi.fd</loader> <nvram>/etc/libvirt/qemu/nvram/1910a190-0555-c5e2-d334-f130de9f4a75_VARS-pure-efi.fd</nvram> </os> <features> <acpi/> <apic/> <hyperv> <relaxed state='on'/> <vapic state='on'/> <spinlocks state='on' retries='8191'/> <vendor_id state='on' value='none'/> </hyperv> </features> <cpu mode='host-passthrough' check='none'> <topology sockets='1' cores='8' threads='1'/> </cpu> <clock offset='localtime'> <timer name='hypervclock' present='yes'/> <timer name='hpet' present='no'/> </clock> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <devices> <emulator>/usr/local/sbin/qemu</emulator> <disk type='file' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source file='/mnt/user/VMs/W10_Q35_test/vdisk1.img'/> <target dev='hdc' bus='virtio'/> <boot order='1'/> <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/> </disk> <disk type='file' device='cdrom'> <driver name='qemu' type='raw'/> <source file='/mnt/user/isos/Windows/Win10_Pro_x64_NTLite_UpdatesJan2019.iso'/> <target dev='hda' bus='sata'/> <readonly/> <boot order='2'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> <disk type='file' device='cdrom'> <driver name='qemu' type='raw'/> <source file='/mnt/user/isos/virtio-win-0.1.160-1.iso'/> <target dev='hdb' bus='sata'/> <readonly/> <address type='drive' controller='0' bus='0' target='0' unit='1'/> </disk> <controller type='sata' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/> </controller> <controller type='pci' index='0' model='pcie-root'/> <controller type='pci' index='1' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='1' port='0x10'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0' multifunction='on'/> </controller> <controller type='pci' index='2' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='2' port='0x11'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x1'/> </controller> <controller type='pci' index='3' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='3' port='0x12'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x2'/> </controller> <controller type='pci' index='4' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='4' port='0x13'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x3'/> </controller> <controller type='pci' index='5' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='5' port='0x14'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x4'/> </controller> <controller type='virtio-serial' index='0'> <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/> </controller> <controller type='usb' index='0' model='ich9-ehci1'> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x7'/> </controller> <controller type='usb' index='0' model='ich9-uhci1'> <master startport='0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0' multifunction='on'/> </controller> <controller type='usb' index='0' model='ich9-uhci2'> <master startport='2'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x1'/> </controller> <controller type='usb' index='0' model='ich9-uhci3'> <master startport='4'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x2'/> </controller> <interface type='bridge'> <mac address='52:54:00:ce:ba:1e'/> <source bridge='br0'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </interface> <serial type='pty'> <target type='isa-serial' port='0'> <model name='isa-serial'/> </target> </serial> <console type='pty'> <target type='serial' port='0'/> </console> <channel type='unix'> <target type='virtio' name='org.qemu.guest_agent.0'/> <address type='virtio-serial' controller='0' bus='0' port='1'/> </channel> <input type='tablet' bus='usb'> <address type='usb' bus='0' port='1'/> </input> <input type='mouse' bus='ps2'/> <input type='keyboard' bus='ps2'/> <graphics type='vnc' port='-1' autoport='yes' websocket='-1' listen='0.0.0.0' keymap='de'> <listen type='address' address='0.0.0.0'/> </graphics> <video> <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1' primary='yes'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/> </video> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x05' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='usb' managed='no'> <source> <vendor id='0x8087'/> <product id='0x0aa7'/> </source> <address type='usb' bus='0' port='2'/> </hostdev> <memballoon model='none'/> </devices> </domain> EDIT: as a note. It's a relativly fresh Windows install with Q35 i had on hand which I used for testing some Qemu stuff on. OS disk was reset, so it's kinda fresh.

@IamSpartacus Same as you I got error 10 when passing through the wireless controller to a VM. Usual a onboard wireless controller also comes with an BT device which I couldn't find in Unraids device list or after the passthrough inside the VM. The Cambridge Silicon Radio is an extra USB BT dongle I've plugged in, it's not the onboard one. I noticed something. Check your USB devices and you should see a device called Intel Corp. I never knew what this is. Pass this to the VM with the 3168NGW and the wireless controller will work and you should see your wifi networks.

If I`'am not wrong, some users get that error on the current stable 6.6 release for some specific controllers on some NVME drives. @limetech added support for them with the RC versions. This will not affect you but maybe Limetech can add this on the list if the next kernel will not add support for this card.

@jbrodriguez that took some time for you to upgrade 😂

@Whoami Your sound device isn't in it's own IOMMU group. You won't be able to pass it through if it's not. The port you have plugged it in is connected via the chipset to the CPU where other devices also connected to. Splitting the devices with the ACS override patch mostly helps a bit but in your case the sound card is still grouped together with one of the PCIe Ports. Try to change to another PCIe slot which isn't connected to the PCH. Edit: What also could help is a updated BIOS version if available. If you're lucky this could fix it. Early days for me on Threadripper the IOMMU groupings were really bad and you couldn't really split them in individual groups with the ACS_patch. A couple BIOS revs. later and this wasn't a issue anymore for me. example without ACS: IOMMU group 13: [1022:43ba] 01:00.0 USB controller: Advanced Micro Devices, Inc. [AMD] X399 Series Chipset USB 3.1 xHCI Controller (rev 02) [1022:43b6] 01:00.1 SATA controller: Advanced Micro Devices, Inc. [AMD] X399 Series Chipset SATA Controller (rev 02) [1022:43b1] 01:00.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] X399 Series Chipset PCIe Bridge (rev 02) [1022:43b4] 02:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 300 Series Chipset PCIe Port (rev 02) [1022:43b4] 02:04.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 300 Series Chipset PCIe Port (rev 02) [1022:43b4] 02:05.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 300 Series Chipset PCIe Port (rev 02) [1022:43b4] 02:06.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 300 Series Chipset PCIe Port (rev 02) [1022:43b4] 02:07.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 300 Series Chipset PCIe Port (rev 02) [1d6a:d107] 03:00.0 Ethernet controller: Aquantia Corp. AQC107 NBase-T/IEEE 802.3bz Ethernet Controller [AQtion] (rev 02) [8086:1539] 04:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network Connection (rev 03) [8086:24fb] 05:00.0 Network controller: Intel Corporation Dual Band Wireless-AC 3168NGW [Stone Peak] (rev 10) [8086:1539] 06:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network Connection (rev 03) Not possible to pass any of that network devices to a VM. With ACS applied all devices will be split in it's own groups now with an up-to-date BIOS. 1 year ago this looked different. All networking devices were still grouped together and also the SATA and the USB controller showed in one group. Unfortunately i can't provide you a screenshot from back in the days.

@Razvan Rosca Login into nextcloud with an admin account. Go to settings >> overview and you should see on the right your current installed version and if an upgrade is available. Is this what you're looking for?

Yep, the name of the VM doesn't match @TomPeel

Not every software inside a docker is updated by the docker itself. It depends on how the docker is put together.

I remember when the 2080ti came out, couple people had issues with the cards getting stuck in a certain powerstage, never changing the clock speeds as supposed to or had random artefacts without even stressing the cards. Someone knows if that issue also occured on the 2080's? This could explain the high idle load. Is the card changing the clock speeds inside a VM under load and on idle?

I wouldn't really compare the 2080 with an 1070. It's way closer to an 1080ti which is way more power hungry than an 1070. Also each manufacture tunes it's cards differently with different power stages and different overclocks.

@rowid_alex Go to your nextcloud webinterface and as said earlier, login with an admin account and check if an update is available. It should show your current version and available updates. The nextcloud itself has to be updated inside the container. Übersicht = overview or whatever language you are using.

I mean if I setup a new Windows VM. sometimes it uses only 1 single core at 100% load and it took ages at that point to get trough the setup. Limit the VM to only 1 core for the setup always fixed it for me. Sometimes I had the same issue changing some settings for the VM (remove GPU, add another disk). Same fix, 1 core, vm starts fine, after that I could reassign more cores and it should work.

If this is the first start of the VM set it to only 1 core. Initial setup with only 1 core assigned fixed it for me, if I had that issue. @johnarvid

The docker container I always keep up to date and from time to time I check nextcloud with an admin account if any update is available. 15.05 I got a couple days ago, hit the update button, done. No special procedure. Check for an update with an Admin account in the settings section "overview", download it and install it. If everything works, the updater shouldn't show any errors. If you have issues, post the output of the updater. @rowid_alex

🤨

I saw a post from a Unraid user over in the original forum with the dev for this patch asking why to use Q35 or why not (and no it wasn't me). Here is his answer. https://forum.level1techs.com/t/increasing-vfio-vga-performance/133443/176 Sure it all depends on the usecase if you should use Q35 or i440fx. Some users here reported they had issues passing through an PCIe device like an GPU and using Q35 out of the box worked for them, so why you wanna remove it than? i440fx is used for years now and should be stable, I get it, but That's what gnif stated and also kinda my opinion. Why removing something thats in heavy development and will be the way to go in the future. Another thing he stated is the following and might be a reason why for me on i440fx 3Dmark for example never worked. At the start of the program a system profiler is running at the beginning collecting system information. This process always frooze for me and caused the VM to crash. Switching to Q35 and changing nothing else and 3Dmark runs fine. This is only one example for some piece of software that might crash or doesn't work in it's full functionality and I'am sure there will be other situations where the i440fx machine type can cause issues not reading the right hardware specific informations correctly. The only thing that changed in this example is to use the newer machine type reporting the correct link speed of x16 by the driver instead of 0x. I can't prove thats the reason why 3Dmark works in Q35 for me and not in i440fx, but as long as it works, it's the option to go with. As much as I love Unraid and believe in @limetech to do the right decisions the same i believe in Gnif opinion and appreciate what he does, btw. the guy who developed the Threadripper PCI reset patch that made it into the kernel. https://patchwork.kernel.org/patch/10181903/ I would like to have no changes in unraid in this specific topic. Keep the Q35 as an option for the user and have the i440fx as default as it is right now. Thanks

@xlucero1 This is your original syslinux config for the default Unraid boot label Unraid OS menu default kernel /bzimage append pcie_acs_override=downstream,multifunction vfio_iommu_type1.allow_unsafe_interrupts=1 initrd=/bzroot and as you can see you already had the pcie_acs_override=downstream,multifunction option in there. You should be fine with this. As far as I know this is the furthest way you can split up the groups with this setting. Each mainboard manufacturer handles the grouping of the PCIE devices differently. On some each device is on it's own group out of the box, on the next manufacturer some are grouped and can be split up with the ACS override patch and on some even this doesn't work. For me for example on the older BIOS versions of my AMD x399 TR4 mainboard i always had the graphics card grouped with other devices and with ACS enabled it worked, where the onboard audio device still was grouped with all network nics and an USB controller. A newer BIOS version helped in my case. After updating I had all devices in it's own groups, except the network devices. All without the ACS override patch. With the patch I can split the nework devices all in it's own groups now. You can check if there is a newer BIOS version for your mainboard available, but make sure to save all your settings you made before updating. It will reset all your BIOS settings to default. If that doesn't help there is only one solution left. Get an extra dedicated soundcard for passthrough.