Warrentheo

In the future, please create a new thread and monitor this one, we don't want to hijack the thread since they are unlikely to be the same exact issue... I noticed you had the UnRaid NVidia plugin installed, what do you use the 1070 for? p.s. you should answer that in your own thread...

Step 1 is to double check that the card works as intended on a baremetal boot... Can't pass broken hardware... Try turning off any motherboard legacy boot or CSM boot option, this will force UEFI boot for UnRaid and the GPU... Windows 10 should use OVMF for UEFI in the VM also... VBIOS passing is only a thing for NVidia cards, because currently they are the only ones that are encrypting their VBIOS and the connection between it and their drivers... video=efifb:off should not be needed... VFIO-PCI drivers for the GPU and its audio card (to be more specific, everything in its IOMMU group except the PCIe slot) in syslinux should help... I prefer the Q35 machine because it fixed some compatibility issues for me, but I have been told that i440fx is slightly faster and works for alot of people... Start there, and if that doesn't work, we will need the XML from the VM and the diagnostics file from the host... Edit: OOPS, vfio-pci drivers should never be used for "CPU"... Meant to say "GPU" >.<

This is normal for the GTX 10 series and the RTX cards... They have encrypted BIOS and the connection between the BIOS and the drivers are also encrypted... They need to have a BIOS file passed in to QEMU to be able to reset the card correctly as well as other issues... This means that when you reset the server, it also resets the GPU, and so will often work, but only for the first boot, and "rebooting" the VM will fail to reset the GPU, causing it to stop talking to the drivers, or other issues... You will want to watch the Space Invader videos if you want the card to act normally...

I think you need to re-read my last post, I get the impression you are still confusing yourself... (p.s. it says don't pass anything... remove the rom file line...)

ah, found one for you:

I can tell you that QEMU doesn't detect the NUMA setup you have, and so you have to manually configure each VM to let the kernel it uses know how to max out the CPU... So the first thing you will need to do is fix the NUMA setup in your VM's XML before you fix anything inside of the VM... If you don't, the VM will always be handing stuff off to other CPU's that it thinks will be near instant, but instead takes ages on CPU timescales... This will mean that the CPU's will spend a ton of time waiting for intercommunication to happen rather then doing anything useful... https://libvirt.org/formatdomain.html#elementsNUMATuning <domain> ... <numatune> <memory mode="strict" nodeset="1-4,^3"/> <memnode cellid="0" mode="strict" nodeset="1"/> <memnode cellid="2" mode="preferred" nodeset="2"/> </numatune> ... </domain> ... <cpu> ... <numa> <cell id='0' cpus='0-3' memory='512000' unit='KiB' discard='yes'/> <cell id='1' cpus='4-7' memory='512000' unit='KiB' memAccess='shared'/> </numa> ... </cpu> ... ... <cpu> ... <numa> <cell id='0' cpus='0,4-7' memory='512000' unit='KiB'> <distances> <sibling id='0' value='10'/> <sibling id='1' value='21'/> <sibling id='2' value='31'/> <sibling id='3' value='41'/> </distances> </cell> <cell id='1' cpus='1,8-10,12-15' memory='512000' unit='KiB' memAccess='shared'> <distances> <sibling id='0' value='21'/> <sibling id='1' value='10'/> <sibling id='2' value='21'/> <sibling id='3' value='31'/> </distances> </cell> <cell id='2' cpus='2,11' memory='512000' unit='KiB' memAccess='shared'> <distances> <sibling id='0' value='31'/> <sibling id='1' value='21'/> <sibling id='2' value='10'/> <sibling id='3' value='21'/> </distances> </cell> <cell id='3' cpus='3' memory='512000' unit='KiB'> <distances> <sibling id='0' value='41'/> <sibling id='1' value='31'/> <sibling id='2' value='21'/> <sibling id='3' value='10'/> </distances> </cell> </numa> ... </cpu> ...

I use Intel chips, and only have a little bit of a hint on this issue, but I think you need to study up on NUMA nodes and how they interact with KVM/QEMU... Thread ripper isn't really a single CPU, it really acts like 2 or 4 CPU sockets in a single CPU socket, with a limited number of methods for one CPU to pass info or tasks to another CPU... In this context to avoid confusion, they don't call these CPU's on a CPU a CPU, but rather a single CPU with multiple NUMA nodes... Your PCIe slots are also linked not to the CPU, but rather a specific NUMA node, and if a different NUMA node wants to talk to that card, it also has to do this inter-NUMA node communication process... Threadripper can be an awesome CPU, but requires alot more configuration and understanding to get it running at its peak...

To my knowledge, only GTX 10 series and above need bios passthrough... It was not until the 10 series that they started encrypting the BIOS... That is why you can get a program like: https://www.techpowerup.com/download/maxwell-ii-bios-tweaker/ or https://www.techpowerup.com/download/kepler-bios-tweaker/ For the GTX 9 series and below, but will never see one again for the GTX 10 series and above... This encryption is what is causing the issues with passthrough, and why BIOS's need to be passed through...

If you use your router as your DHCP server, set it up there instead... Only do it on UnRaid is you use UnRaid as your DHCP server...

To my knowledge, only GTX 10 series and above need bios passthrough... It was not until the 10 series that they started encrypting the BIOS... That is why you can get a program like: https://www.techpowerup.com/download/maxwell-ii-bios-tweaker/ or https://www.techpowerup.com/download/kepler-bios-tweaker/ For the GTX 9 series and below, but will never see one again for the GTX 10 series and above... This encryption is what is causing the issues with passthrough, and why BIOS's need to be passed through...

The BIOS on a GTX 7 series card is not encrypted, no special actions should be needed... Only GTX 10 series and the RTX cards have the encrypted BIOS and drivers that make it needed to do the BIOS passthrough...

This one helped me alot 🙂 If that is too late, then I would still backup where you are now so you can experiment...

Low possibility, but you might try and add something like: <cputune> ... ... <emulatorpin cpuset='0,4'/> </cputune> and edit the CPU's that QEMU gets to use, move them off the cores that the VM uses... On my system UnRaid has to be on Core 0, and I also pass through its Hyperthreaded core as well... Edit to line up with you system...

Unfortunately there is a large number of things this could be, and so would need the Diagnostics file from the Host, as well as the XML from the VM... Tools-->Diagnostics-->Download Then just edit the VM, but switch the little switch in the upper right from "Form View" to "XML View", copy everything in there to a text file, and attach that file as well...

In the past it was one of the things that triggered the NVidia driver to notice it was in a VM, and so had to be turned off... That said I have had mine on for about a year with no issues on my GTX1070... The RTX card may be different, but I doubt it... For troubleshooting, I would start with it off for now, and try turning it on when everything else is working...

If you have all the devices correctly passed, than this most likely means that the BIOS file is not correct... Ever since the NVidia 10 series and the RTX series, NVidia started encrypting their BIOS and the connection between their drivers and their BIOS... I have a GTX1070, and was able to use the SpaceInvader video to just dump my card with no other modification to get it to work... The RTX cards may be slightly different, but from other reports I have seen, this just looks like the same sort of things that the GTX 10 series people have been having to deal with so I doubt it... For me, when the BIOS was not correct, but I rebooted the host and auto-launched the Windows VM, it would still work during that boot, but then would not be able to reset the PCIe slot, so if I "rebooted" the VM, it would no longer talk to the card and error 43... I suspect you are at this stage of the process...

I understand what you are saying, but that is why I included the link to the CPU benchmarks comparing the CPU you have to the Min-Spec CPU... While you might think that the Processor clock has alot to do with it, it really doesn't... For instance AMD has always had a much lower clock speed to the Intel chips, and yet somehow usually kept up on real world benchmarks... That is why I included this link: https://cpu.userbenchmark.com/Compare/Intel-Xeon-E5-2660-v2-vs-Intel-Core-i5-2400/m13068vs803 It shows that that CPU has about 2/3's of the single core performance of the CPU that ARK requires as min spec, but as a whole that CPU has about 50% of the minimum spec... It really is a limiting factor here... I get it, I actually used a Core 2 Quad Q9550 with 4 Cores, @2.83 GHz for WAY longer than I should have because I was still able to get it to do what I needed it too (Even had my GTX1070 plugged into it), and went straight from that to an i7-7700K... Bottom line, you are trying to use a processor that is somewhere between 2/3's to 1/2 of the Minimum required processor for that game, and you are not running just that game on it, you are running UnRaid + KVM/QEMU + a storage server + Windows VM + Ark... I really do believe that that is a large part of why the VM's are unstable, they are not meant to run like that... I am not going to stop you, and more power to you if this sort of thing is what floats your boat, but this will likely boil down to making that CPU perform like a much better CPU with extreme overclocking or something, and UnRaid is not really an ideal environment to try and run a stable system while also pushing the envelope just a little too far...

To be honest, that CPU is about 50% of the minimum spec for the game, so either the crashing is because the CPU is not up to spec, or the crashing doesn't matter because even if we fix it, the game is not going to run correctly... This is lost cause territory for me... p.s. A GTX 660 is also below the minimum spec for the craphics card as well... MINIMUM: OS: Windows 7/8.1/10 (64-bit versions) Processor: Intel Core i5-2400/AMD FX-8320 or better Memory: 8 GB RAM Graphics: NVIDIA GTX 670 2GB/AMD Radeon HD 7870 2GB or better DirectX: Version 10 Storage: 60 GB available space Additional Notes: Requires broadband internet connection for multiplayer https://cpu.userbenchmark.com/Compare/Intel-Xeon-E5-2660-v2-vs-Intel-Core-i5-2400/m13068vs803 And all of this is for baremetal performance... Trying to run UnRaid and KVM/QEMU and possibly other stuff on top of all this further reduces how likely this is to work... If you are going to game on your UnRaid box, it needs to be overkill for the game you are running...

syslinux just keeps them from being used by UnRaid, but that is not enough, if you assign any device from the IOMMU group, it is easiest to just assign them all (there are workarounds for some devices, but it is easiest to just add them all)... This is why all the existing instructions for us GTX 10 series card users say to also pass the sound card as well... So I assumed you added something like: vfio-pci.ids=10de:1b81,10de:10f0 to your syslinux config, but with all 4 devices for you... But even after everything has the vfio-pci driver from the UnRaid kernel, you still need to pass all 4 into the devices section of the VM... P.S. In the new UnRaid 6.7.0-rc, the syslinux can be simplified to just the PCI id with something like: BIND=01:00.0 Which assigns the vfio-pci driver for everything in that PCIe slot (all 4 devices in your case)... This has the big plus of letting you pick from 2 different identical cards, but has the major downside of not moving with the card when you modify what hardware on your motherboard is connected or turned on, so hardware changes need to be made carefully after this...

Most of the new RTX cards have 4 "Devices" in their IOMMU group, and so far my experience is that people don't know that they need to pass them all in for the card to work correctly... This also means setting all those devices to use the vfio-pci driver so that UnRaid doesn't try and use them for itself... You will also need to pass in the BIOS from the card manually on NVidia 10 series and above...

It will start fine... Once... But will not reboot correctly, and have other weird issues... I recommend this link, acts a graphical frontend for QEMU, and makes attaching devices much easier...

Diagnostics is under the "Tools" menu, then under diagnostics, then just click "Download"... Also just for the future, the "Code" button is the one you want to click when posting XML code, the "Quote" button makes everything hard to read... Or better yet, paste it into a text file and just drag the file into this window... Not chewing you out, just mentioning for the future... Edit: Also, reading through what you did have posted: This looks like that reset of the GPU thing that I was talking about, so it looks like it is not fully passed through yet...

I have been using UnRaid for a while, and will not being going back to running Windows baremetal again I don't think... That said it does require more regular maintenance than running baremetal... More little things that need to be checked on occasion, all the ones from a Windows install, and from a Linux install combined... As I said, I consider it worth it, but it is up to you... Under the assumption that you took the red pill and feel up to the challenge, then up above and to the right hand side of all the stuff you took a picture of, there is a little toggle switch for "Form View" That is where you find the XML version of your VM setup... Copy it all to a text file, and attach that file here... Then goto the "Tools" menu, and select Diagnostics... Click "Download" and save the file somewhere... Then attach that file also... Some things I can see you might want to try first though, make sure you are running UnRaid 6.6.7 Also, normally you want to run latter versions of Windows with the "OVMF" bios, not the SeaBios, but that can wait till we look for anything else...

Your syslog is filled up with error's about IRQ's and call traces... Most likely the "Slowness" is the system trying its best to recover from these error's... Don't know if it is hardware failure or configuration issues... Use basic troubleshooting type steps (does it cause error's with no VM's running? does it cause error's with a simple Linux VM? Does it cause error's with Windows VM that has had all its devices and pass-throughs removed? Find something that doesn't cause errors and slowly build on top of that till you find the culprit... Also double check make sure that your host is setup correctly and BIOS is correctly configured... But basically your UnRaid Host needs to be working correctly before you can build a VM on top of it...

P.S. the "Code" button is your friend here...