unRAID crashes after GPU Passthrough to Windows KVM


cap089

Recommended Posts

On 10/4/2019 at 8:49 PM, metathias said:

Unraid not being bootable without UEFI sounds a bit odd to me. Its bootable either way for me. Having it on presented a host of issues for me in the past (Cant speak for recent versions of unraid).

Hi I tried it without UEFI at first and during my tests with other versions of unRAID sometimes I forgot to set the checkmark "Allow UEFI boot" in the USB Creator app and every time I missed the checkmark the stick did not show up in the Boot menu... 

 

Ok at first the IOMMU groups. I enabled PCIe ACS Override and set it to "Both", also I allowed the VFIO unsafe interrupts.

 

IOMMU group 0:	[1022:1482] 00:01.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 1482
IOMMU group 1:	[1022:1483] 00:01.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 1483
IOMMU group 2:	[1022:1482] 00:02.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 1482
IOMMU group 3:	[1022:1482] 00:03.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 1482
IOMMU group 4:	[1022:1483] 00:03.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 1483
IOMMU group 5:	[1022:1482] 00:04.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 1482
IOMMU group 6:	[1022:1482] 00:05.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 1482
IOMMU group 7:	[1022:1482] 00:07.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 1482
IOMMU group 8:	[1022:1484] 00:07.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 1484
IOMMU group 9:	[1022:1482] 00:08.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 1482
IOMMU group 10:	[1022:1484] 00:08.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 1484
IOMMU group 11:	[1022:1484] 00:08.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 1484
IOMMU group 12:	[1022:1484] 00:08.3 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 1484
IOMMU group 13:	[1022:790b] 00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller (rev 61)
	            [1022:790e] 00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge (rev 51)
IOMMU group 14:	[1022:1440] 00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 1440
	[1022:1441] 00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 1441
	[1022:1442] 00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 1442
	[1022:1443] 00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 1443
	[1022:1444] 00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 1444
	[1022:1445] 00:18.5 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 1445
	[1022:1446] 00:18.6 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 1446
	[1022:1447] 00:18.7 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 1447
IOMMU group 15:	[1022:57ad] 01:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 57ad
IOMMU group 16:	[1022:57a3] 02:03.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 57a3
IOMMU group 17:	[1022:57a3] 02:04.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 57a3
IOMMU group 18:	[1022:57a3] 02:05.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 57a3
IOMMU group 19:	[1022:57a4] 02:08.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 57a4
IOMMU group 20:	[1022:57a4] 02:09.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 57a4
IOMMU group 21:	[1022:57a4] 02:0a.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 57a4
IOMMU group 22:	[8086:2723] 03:00.0 Network controller: Intel Corporation Device 2723 (rev 1a)
IOMMU group 23:	[10ec:8125] 04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. Device 8125
IOMMU group 24:	[8086:1539] 05:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network Connection (rev 03)
IOMMU group 25:	[1022:1485] 06:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Device 1485
IOMMU group 26:	[1022:149c] 06:00.1 USB controller: Advanced Micro Devices, Inc. [AMD] Device 149c
IOMMU group 27:	[1022:149c] 06:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Device 149c
IOMMU group 28:	[1022:7901] 07:00.0 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] (rev 51)
IOMMU group 29:	[1022:7901] 08:00.0 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] (rev 51)
IOMMU group 30:	[10de:1b80] 09:00.0 VGA compatible controller: NVIDIA Corporation GP104 [GeForce GTX 1080] (rev a1)
IOMMU group 31:	[10de:10f0] 09:00.1 Audio device: NVIDIA Corporation GP104 High Definition Audio Controller (rev a1)
IOMMU group 32:	[1022:148a] 0a:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Device 148a
IOMMU group 33:	[1022:1485] 0b:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Device 1485
IOMMU group 34:	[1022:1486] 0b:00.1 Encryption controller: Advanced Micro Devices, Inc. [AMD] Device 1486
IOMMU group 35:	[1022:149c] 0b:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Device 149c
IOMMU group 36:	[1022:1487] 0b:00.4 Audio device: Advanced Micro Devices, Inc. [AMD] Device 1487
IOMMU group 37:	[1022:7901] 0c:00.0 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] (rev 51)
IOMMU group 38:	[1022:7901] 0d:00.0 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] (rev 51)

 

Then my XML for my Windows 10 KVM. I passthrough the Realtek Ethernet Controller to the VM, the 2 USB controllers in the IOMMU groups 26 (06:00.1) and 27 (06:00.3). Also of course the GTX 1080 with its sound chip and in addition the onBoard sound card: 

<?xml version='1.0' encoding='UTF-8'?>
<domain type='kvm'>
  <name>Windows 10</name>
  <uuid>7d89541c-18c6-c0bc-f056-d63aa5f1f952</uuid>
  <metadata>
    <vmtemplate xmlns="unraid" name="Windows 10" icon="windows.png" os="windows10"/>
  </metadata>
  <memory unit='KiB'>20971520</memory>
  <currentMemory unit='KiB'>20971520</currentMemory>
  <memoryBacking>
    <nosharepages/>
  </memoryBacking>
  <vcpu placement='static'>16</vcpu>
  <cputune>
    <vcpupin vcpu='0' cpuset='4'/>
    <vcpupin vcpu='1' cpuset='16'/>
    <vcpupin vcpu='2' cpuset='5'/>
    <vcpupin vcpu='3' cpuset='17'/>
    <vcpupin vcpu='4' cpuset='6'/>
    <vcpupin vcpu='5' cpuset='18'/>
    <vcpupin vcpu='6' cpuset='7'/>
    <vcpupin vcpu='7' cpuset='19'/>
    <vcpupin vcpu='8' cpuset='8'/>
    <vcpupin vcpu='9' cpuset='20'/>
    <vcpupin vcpu='10' cpuset='9'/>
    <vcpupin vcpu='11' cpuset='21'/>
    <vcpupin vcpu='12' cpuset='10'/>
    <vcpupin vcpu='13' cpuset='22'/>
    <vcpupin vcpu='14' cpuset='11'/>
    <vcpupin vcpu='15' cpuset='23'/>
  </cputune>
  <os>
    <type arch='x86_64' machine='pc-i440fx-3.0'>hvm</type>
    <loader readonly='yes' type='pflash'>/usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi.fd</loader>
    <nvram>/etc/libvirt/qemu/nvram/f59f4ccd-d607-2f2a-049b-51c03e6983fc_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='16' 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='block' device='disk'>
      <driver name='qemu' type='raw' cache='writeback'/>
      <source dev='/dev/disk/by-id/ata-Samsung_SSD_850_EVO_1TB_S2RFNX0HA24183T'/>
      <target dev='hdc' bus='sata'/>
      <boot order='1'/>
      <address type='drive' controller='0' bus='0' target='0' unit='2'/>
    </disk>
    <disk type='block' device='disk'>
      <driver name='qemu' type='raw' cache='writeback'/>
      <source dev='/dev/disk/by-id/ata-WDC_WD30EFRX-68EUZN0_WD-WCC4N1TJ06V8'/>
      <target dev='hdd' bus='sata'/>
      <address type='drive' controller='0' bus='0' target='0' unit='3'/>
    </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='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>
    <controller type='pci' index='0' model='pci-root'/>
    <controller type='ide' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
    </controller>
    <controller type='sata' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </controller>
    <controller type='virtio-serial' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </controller>
    <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='mouse' bus='ps2'/>
    <input type='keyboard' bus='ps2'/>
    <hostdev mode='subsystem' type='pci' managed='yes'>
      <driver name='vfio'/>
      <source>
        <address domain='0x0000' bus='0x09' slot='0x00' function='0x0'/>
      </source>
      <rom file='/mnt/user/domains/gtx1080.dump'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
    </hostdev>
    <hostdev mode='subsystem' type='pci' managed='yes'>
      <driver name='vfio'/>
      <source>
        <address domain='0x0000' bus='0x09' slot='0x00' function='0x1'/>
      </source>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
    </hostdev>
    <hostdev mode='subsystem' type='pci' managed='yes'>
      <driver name='vfio'/>
      <source>
        <address domain='0x0000' bus='0x0b' slot='0x00' function='0x4'/>
      </source>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/>
    </hostdev>
    <hostdev mode='subsystem' type='pci' managed='yes'>
      <driver name='vfio'/>
      <source>
        <address domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
      </source>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/>
    </hostdev>
    <hostdev mode='subsystem' type='pci' managed='yes'>
      <driver name='vfio'/>
      <source>
        <address domain='0x0000' bus='0x06' slot='0x00' function='0x1'/>
      </source>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </hostdev>
    <hostdev mode='subsystem' type='pci' managed='yes'>
      <driver name='vfio'/>
      <source>
        <address domain='0x0000' bus='0x06' slot='0x00' function='0x3'/>
      </source>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/>
    </hostdev>
    <memballoon model='none'/>
  </devices>
</domain>

 

EDIT: During writing this post, unRAID 6.6.7 crashed and I had to "kill" it via power button...

Edited by cap089
Link to comment

Interesting. The ACS override, and VFIO unsafe are known to both be very unstable and could be an issue. While in my limited attempts to use ACS override it did function to allow me to split off devices not normally allowed to do (more IOMMU groups) When attempting to separate those things into either separate VMs or just one VM (taking the bus away from just Unraid) would cause hanging, halting, And other ghostly phenomenon.

 

As for your USB drive not showing up without UEFI enabled. Sounds like a bios settings might have something to do with that. Try to find a legacy/compatibility mode for your bios to turn off UEFI altogether on the BIOS side. Also clearing your boot keys might be necessary (Its seems like every generation they try to make it harder just to turn UEFI off)  Then confirm the USB device is showing up in your bootable options in the BIOS. You might also through your bios carefully for IOMMU related options (there should be one somewhere) I looked through your MB manual for your motherboard (ROG Strix X570-E Gaming) and it was pretty useless for bios settings info. So you might have to hunt a bit to find the options your looking for.

Link to comment

Thanks for your reply. Ok then I will do some testing in the next days:

- disable "VFIO unsafe interrupts"

- disable PCI ACS override, but I thinkt thats what I need because otherwise I can forget about to passthrough any USB controller...

 

Regarding the BIOS settings. Yes I know the manual is not worth it... Right from the beginning IOMMU support was enabled or rather it was on "Auto" so I switched the setting to "Enabled" just to be sure. The same thing I made with the "legacy" boot support. But thats what I mentioned earlier, I think here the BIOS of my mainboard behaves buggy or something else. But I will check it out again.

Link to comment

Ok testing is done....

At first the good news: I found an hidden additional setting for legacy support, after enabling it I was able to boot unRAID without UEFI.

Directly to the bad news:

1. I made a complete new unRAID stick with v6.6.7 and also erased the disks of my array. After setting up the disk again and parity sync started I got the "well known" kernel panic:

kernel panic - not syncing: fatal exception in interrupt [...]

At this point I had not even touched the VM tab...

 

2. Switched to v6.7.2 in legacy mode -> endless loading after rebuild sync started

3. Tried it with v6.7.3 rc4 -> crashes immediately at startup

 

4. So Ok - tried it again with v6.6.7. Now I got no kernel panic and set up the Windows VM. I activated PCI ACS Override - otherwise it does not fit my needs... I also had to activate again "VFIO allow unsafe interrupts" because otherwise the Windows KVM was not able to boot.

With these 2 options I could actually boot into Windows and I just started up a game and ran a Cinebench. So far so good...

 

Then I tried to reboot the WM and after I logged in to Windows the whole WM crashed. In the unRAID Web UI I had again endless loading on the "WM" tab and after a while unRAID crashed completely. I tried three reboots. Two times it stucked/ crashed during booting and at the third time it booted up but the Web UI was not reachable under the shown IP adress. Clearing the browser cache did not help.

 

5. Finally I just remembered that sometimes an additional boot-parameter is necessary on Ryzen CPUs. So I again installed everything new and added the parameter:

rcu_nocbs=0-23

But with this the system was even more unstable and crashed again.

 

At all I think it doesn't make sense to go on with testing (?) My plan is to wait for unRAID 6.8 and BIOS updates. And if nothing happens during the next two months and I take this as a lesson and go back to a stable Synology NAS.

Link to comment

Hi! This week a new BIOS update launched and now also the first beta version of 6.8 came out. So I thought I try it again...

 

In general the CPU performance is worse with the new BIOS update - but thats another site..

 

With unRAID 6.8 I have the exact same issues. It crashes when I try to start the Windows VM with the GPU passthrough. Even when I manually stop the parity sync it crashes. The GPU unbind script also not work anymore with 6.8 - so there are more changes made... Unbind it manually with the unbind command in /sys/pci/drivers/vfio-pci/ is also not working.

Link to comment
  • 2 weeks later...

Hi, I checked out the latest 6.8 rc3 with the new custom kernel modules which are provided in this thread:

 

At all 6.8 seems to run smoother and robust but now it seems to be that the latest BIOS for my motherboard (from: 10/07/19) which make its impossible to passthrough any device. I tried out without the GPU passthrough and just my SSD, USB controllers and onboard sound and in the system-log I get errors, like:

Tower kernel: vfio-pci 0000:0b:00.4: not ready 1023ms after FLR; waiting

 

I guess I have to wait for a next BIOS update and hopefully then everything will work...

Link to comment
On 9/24/2019 at 6:43 PM, Hankanman said:

Hi I scratched my head on this for a while, there was a solution, essentially unraid doesn't release the Primary GPU for use by a VM:

 

First test with the following commands via ssh with your VM off:

 

echo 0 > /sys/class/vtconsole/vtcon0/bind
echo 0 > /sys/class/vtconsole/vtcon1/bind
echo efi-framebuffer.0 > /sys/bus/platform/drivers/efi-framebuffer/unbind

 

Then try to boot your vm with the gpu passed through. if it boots successfully you had the same issue as me. Then install user scripts from community applications and set this to run as a little script when the array starts. even works with auto starting VMs.

Could you tell me a little more of what this script does? It's just got my VM working for the first time after a load of issues I was facing...

 

Edited by J89eu
Link to comment

UPDATE: I just tested out v 6.8 rc4 and now the GPU passthrough seems to work. Also a restart was no problem, so far.

 

But now I got another problem: When I try to passthrough the onboard soundchip the system crashes. Its also the origin for the error which I posted before:

Tower kernel: vfio-pci 0000:0b:00.4: not ready 1023ms after FLR; waiting

I tried to unbind it manually via "pci-pci.ids" in the boot parameters, as I had done succesfully with the Realtek ethernet controller, but this did not help. And of course the soundchip is in his own IOMMU group and also I selected it as the second audio device (first one is the GPU audio)..

 

Any ideas, please?

 

EDIT: I actually tried this method, but didn't work..

 

Edited by cap089
Link to comment
  • 2 weeks later...

Personally i dont try to passthrough audio to my VM. There are a host of issues that commonly crop up around doing that.. My solution was just to purchase USB sound cards. Their really pretty cheap. And are loads more stable in every way then the built-in passthrough solutions that exist out there. A slam dunk really. Seeing as how only 1 VM device could get that sound device anyway. The solution costs more...But not  by much.

Link to comment

Buying some extra stuff was not my plan. This week a new BIOS update for my motherboard was released but here I have the same issue with the onboard audio..

The next thing which annoys me on unRAID is that it seems to be impossible to just passthrough a blu ray drive like any other SATA drive...

 

So I have to think about, if I can live with these compromises.

Link to comment
Just now, bastl said:

Ever thought about using an external USB drive or buying a cheap adapter for your existing one and pass this through?

 

CD-DVD drives in 2019 😂 just sayin

 

I want everything in one case and I just need it for Makemkv. Yeah I know there are some Docker versions of Makemkv but I also "cross-read" about some weird problems.

Link to comment
1 minute ago, bastl said:

I bet you have a free USB header on your motherboard which you can use 😉

Most modern boards have 2 or even more and in most cases you only use one for the front panel USB ports of the case.

 

Thats an argument ;). But well the problem with the onboard sound is more important to fix and if I buy an PCI Soundcard then I first have to find a card that fits my needs.

Link to comment

@cap089 From your xml it looks like you're passing a lot of stuff to your VM. It's adviced to reduce it to a minimum. Besides of the GPU and it's audio, you're passing through

 

IOMMU group 23: [10ec:8125] 04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. Device 8125

IOMMU group 26: [1022:149c] 06:00.1 USB controller: Advanced Micro Devices, Inc. [AMD] Device 149c

IOMMU group 27: [1022:149c] 06:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Device 149c

 

Are you sure you really need all these? Ethernet can be handled via a virtual nic and is faster (up to 10gig) if you transfer files to unraid if you're using a fast cache for your shares. USB onboard controllers are often really tricky to get them to work. Did you tried tried to only passthrough the GPU without anything else and get it to work and add the onboard audio next? Mouse and keyboard you can add via unraids web ui.

Link to comment

I would advise against using the web ui xml generator to pass through devices.. Not there is any wrong with the UIs method. devices themselves just pass through poorly to VMs. Passing controllers is the preferred method by a mile. I dont see anything wrong with your setup up. Even if it is a bit dense. Mine are as well. I would still however try to convince you to steer clear of the sound card.. No end in sight to the number of issues you will come up against. A sufficient USB audio board is 10 bucks.. Hell they come for free on the end of cheap headsets all the time. If your want digital audio for some reason.. Sort it out through the HDMI on your video board.. Thats where it will end up usually anyway.

Link to comment
13 minutes ago, metathias said:

Passing controllers is the preferred method by a mile.

True for dedicated cards but not for unboard controllers, maybe connected to the chipset, grouped with other devices and with ACS Override split. Lots of people have problems passing through onboard controllers. ACS is only a workaround which won't work in all szenarios. Dedicated usb cards is the way to go. This is why I told him to test without and reduce the devices to a minimum to narrow down the issues. Yesterday a guy had issues where the VM shutdown or restart caused the server to freeze and guess what was the culprit? A passed through USB controller 😉

Link to comment
26 minutes ago, metathias said:

I would advise against using the web ui xml generator to pass through devices.. Not there is any wrong with the UIs method. devices themselves just pass through poorly to VMs.

Sorry I don't get it. What do you mean? For the USB controllers I used the XML view.

And for the soundcard I used the Web UI. So you think I should try it here also with the XML view?

 

Anyway I will check out soundcards these days...

Link to comment

USB controllers cant be passed through normally with the basic view VM editor. You have to manually add the XML yourself before it will show in the basic form view. However you can pass through any given USB device using the basic form view (The way i suggest NOT to use)

 

@bastl

I guess it really goes to show each persons needs to adjust their configuration to the hardware available to them. Personally i am on a 1950x with a Asus x399 Strix. I  pass 2 of my built-in individual usb controllers to 2 different VMs. Where i have never had an issue with them in that config. Of course a add-in controller board is also an excellent way to go as well.

Link to comment
9 hours ago, metathias said:

USB controllers cant be passed through normally with the basic view VM editor. You have to manually add the XML yourself before it will show in the basic form view.

 

Ah ok. So I got you right. Thats the way I have done it the whole time.

 

EDIT: Ok sometimes solutions are that easy that you cant see them at first sight.🙈

I have higher quality active speakers which I normally plugged in via optical cable. Besides that they have normal AUX and USB! So I just use them via USB now and have sound in my VM! xD

 

For now I let the machine running and let unRAID finish the Parity-Sync and hope that everything runs stable. After that I can kick on the big media file transfer..

Edited by cap089
Update
Link to comment

Hi! Ok everything seemed to work so far, until today... Yesterday the file transfer was running and gaming in the Windows KVM was no issue. Today I set up some Docker-Apps and recognized an overhead in the Windows KVM. I just tested Battelfield V and moving the mouse was lagging as hell... It is no GPU issue, I have constantly about 90-100 fps in this game, as I had before on the baremetal system.

 

Yesterday I already set up the CPU isolation for the gaming VM and also used the "MSI tool". Actually I have no idea why the overhead is now present or rather so intense. Should I try to switch from i440fx-4.0 to Q35? That is what I found on my research in the web and the forum...

 

Link to comment

@cap089 You can limit your dockers to specific cores like you can do to VMs. If you don't do that, they will grab all the cores which are free. In a situation where a docker uses a lot of cpu cicles or ram you might affect your gaming VM. Go to settings > CPU pinning and make sure you not overlap the cores for your dockers and VMs or shutdown your dockers when gaming.

Link to comment

@bastl There was no overlapping and I thought isolating means the cores are permanently reserved for this specific VM (?)

But anyway I pinned the Dockers to specific cores/ threads and it didn't changed anything. Even a restart of the whole server did not help.

Yesterday there were also Dockers running in the background like Krusader, Plex, Makemkv.. I don't know what changed overnight. Just the fact, that the file transfer is completed.

Link to comment

My guess is that those dockers are probably eating into core 0 which should be isolated from the dockers, Core 0 and its hyperthread twin should be left exclusively to unraid. Try using CPU pinning on the dockers. But make sure NOT to use isolation on dockers. Leave isolation only to VMs and dont isolate core 0 or it hyperthread.. That will stop unraid from using it altogether. There might be a few cpu tweaks you can make to further improve performance. But if the unraid config is set up correctly. Even default settings for the VM should produce decent performance. If somewhat underwhelming.

 

Also. Double check your memory resources. Try not to let it get down to those last few GB of ram. If so you could start getting huge I/O from the constant swapping any data unraid is trying to juggle. If that happens it can bring the whole system to a crawl. And should show in the CPU utilization graph on the dashboard of unraid.

Edited by metathias
More data
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.