Warrentheo

Several options, but mainly we need the XML from the VM, and the diagnostics file from the host before we can figure out which one...

It could also just be your thermal grease drying out, or having bumped the cooler dislodging the thermal connection... There are several options... If it is thermal grease issues, you might want to look into this, it is a new product, and not really mentioned everywhere yet...: https://www.amazon.com/gp/product/B07CKVW18G/ref=ox_sc_act_title_3?smid=A23NVCSO4PYH3S&psc=1 Edit: it could be something like a new video card overheating the case as well, again there are many options for what is causing this... I would not jump straight to buying something to fix it...

Your system is having several issues... Libvirt keeps loosing access to files: 2019-02-17 05:45:16.964+0000: 9822: info : libvirt version: 4.7.0 2019-02-17 05:45:16.964+0000: 9822: info : hostname: Asgard 2019-02-17 05:45:16.964+0000: 9822: error : qemuOpenFileAs:3143 : Failed to open file '/mnt/disks/KINGSTON_SV300S37A120G_50026B774609E873/Windows 10/vdisk1.img': No such file or directory 2019-02-17 05:45:16.964+0000: 9823: error : qemuOpenFileAs:3143 : Failed to open file '/mnt/disks/KINGSTON_SV300S37A120G_50026B774609E873/Windows 10/vdisk1.img': No such file or directory 2019-02-17 05:45:16.972+0000: 9821: error : qemuOpenFileAs:3143 : Failed to open file '/mnt/disks/KINGSTON_SV300S37A120G_50026B774609E873/Windows 10/vdisk1.img': No such file or directory 2019-02-17 05:45:16.973+0000: 9821: error : qemuOpenFileAs:3143 : Failed to open file '/mnt/disks/KINGSTON_SV300S37A120G_50026B774609E873/Windows 10/vdisk1.img': No such file or directory 2019-02-17 05:45:16.974+0000: 9821: error : qemuOpenFileAs:3143 : Failed to open file '/mnt/disks/KINGSTON_SV300S37A120G_50026B774609E873/Windows 10/vdisk1.img': No such file or directory 2019-02-17 05:45:16.975+0000: 9823: error : qemuOpenFileAs:3143 : Failed to open file '/mnt/disks/KINGSTON_SV300S37A120G_50026B774609E873/Windows 10/vdisk1.img': No such file or directory 2019-02-17 05:45:19.244+0000: 9824: error : virStorageFileReportBrokenChain:4776 : Cannot access storage file '/mnt/disks/KINGSTON_SV300S37A120G_50026B774609E873/Windows 10/vdisk1.img': No such file or directory 2019-02-17 05:45:24.100+0000: 9821: error : qemuOpenFileAs:3143 : Failed to open file '/mnt/disks/KINGSTON_SV300S37A120G_50026B774609E873/Windows 10/vdisk1.img': No such file or directory 2019-02-17 05:45:24.108+0000: 9825: error : qemuOpenFileAs:3143 : Failed to open file '/mnt/disks/KINGSTON_SV300S37A120G_50026B774609E873/Windows 10/vdisk1.img': No such file or directory 2019-02-17 05:45:24.110+0000: 9825: error : qemuOpenFileAs:3143 : Failed to open file '/mnt/disks/KINGSTON_SV300S37A120G_50026B774609E873/Windows 10/vdisk1.img': No such file or directory 2019-02-17 05:45:24.111+0000: 9825: error : qemuOpenFileAs:3143 : Failed to open file '/mnt/disks/KINGSTON_SV300S37A120G_50026B774609E873/Windows 10/vdisk1.img': No such file or directory 2019-02-17 05:45:24.112+0000: 9822: error : qemuOpenFileAs:3143 : Failed to open file '/mnt/disks/KINGSTON_SV300S37A120G_50026B774609E873/Windows 10/vdisk1.img': No such file or directory and your system keeps overheating: ....... ....... Feb 17 16:15:08 Asgard kernel: CPU6: Package temperature/speed normal Feb 17 16:15:08 Asgard kernel: CPU7: Package temperature/speed normal Feb 17 16:15:08 Asgard kernel: CPU5: Package temperature/speed normal Feb 17 16:15:08 Asgard kernel: CPU3: Package temperature/speed normal Feb 17 16:15:08 Asgard kernel: CPU1: Package temperature/speed normal Feb 17 16:15:08 Asgard kernel: CPU2: Package temperature/speed normal Feb 17 16:15:08 Asgard kernel: CPU1: Core temperature above threshold, cpu clock throttled (total events = 2144810) Feb 17 16:15:08 Asgard kernel: CPU5: Core temperature above threshold, cpu clock throttled (total events = 2144810) Feb 17 16:15:08 Asgard kernel: CPU1: Core temperature/speed normal Feb 17 16:15:08 Asgard kernel: CPU5: Core temperature/speed normal Feb 17 16:20:28 Asgard nginx: 2019/02/17 16:20:28 [error] 8876#8876: *203316 readv() failed (104: Connection reset by peer) while reading upstream, client: 192.168.1.2, server: , request: "POST /webGui/include/DeviceList.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "192.168.1.106", referrer: "http://192.168.1.106/Main" Feb 17 16:20:49 Asgard nginx: 2019/02/17 16:20:49 [error] 8876#8876: *203381 readv() failed (104: Connection reset by peer) while reading upstream, client: 192.168.1.2, server: , request: "POST /plugins/unassigned.devices/UnassignedDevices.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "192.168.1.106", referrer: "http://192.168.1.106/Main" Feb 17 16:21:10 Asgard nginx: 2019/02/17 16:21:10 [error] 8876#8876: *203455 readv() failed (104: Connection reset by peer) while reading upstream, client: 192.168.1.2, server: , request: "POST /webGui/include/DeviceList.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "192.168.1.106", referrer: "http://192.168.1.106/Main" Feb 17 16:21:51 Asgard nginx: 2019/02/17 16:21:51 [error] 8876#8876: *203589 readv() failed (104: Connection reset by peer) while reading upstream, client: 192.168.1.2, server: , request: "POST /webGui/include/DeviceList.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "192.168.1.106", referrer: "http://192.168.1.106/Main" Feb 17 16:22:33 Asgard nginx: 2019/02/17 16:22:33 [error] 8876#8876: *203724 readv() failed (104: Connection reset by peer) while reading upstream, client: 192.168.1.2, server: , request: "POST /webGui/include/DeviceList.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "192.168.1.106", referrer: "http://192.168.1.106/Main" Feb 17 16:23:57 Asgard nginx: 2019/02/17 16:23:57 [error] 8876#8876: *203990 readv() failed (104: Connection reset by peer) while reading upstream, client: 192.168.1.2, server: , request: "POST /plugins/unassigned.devices/UnassignedDevices.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "192.168.1.106", referrer: "http://192.168.1.106/Main" Notice where it shows : Most likely your log files are filling up with CPU issues in the logs, and this eventually kills LibVirt... Either way, check your hardware... Once you get the logs to stop screaming at you, you will probably fix the issues with LibVirt and your VM's.... Also, to GHunter, I am not able to find the XML files in the diagnostics... Does it matter if they have the "Anonymous" version of the diagnostics? or am I just going blind?

In the past this was difficult if the cards were all identical (no way to specify which of the identical cards you wanted, since they all had the same hardware ID...) But this should be better soon with the new UnRaid 6.7.0-rc coming soon... One of its features is that you can specify cards by PCIe slot, and not by hardware id... 6.7.0 should be good when it is released, it still has some minor kinks they are working out...

They offer dummy plugs for that sort of thing if you wish... Just Google: DisplayPort Dummy Plug or HDMI Dummy Plug

If the "AMD Tool" you mention tries to talk to the CPU controllers directly and such, all that will fail... The only thing that 'host-passthrough' does is passthrough the CPU strings to the VM... You can open CPU-z in VM and then look at a bare-metal example to see what doesn't get passed through... It is possible to change or add some of this stuff manually (You need to do that sort of thing when creating a MacOS VM), but mostly the ones that don't get added are skipped for a reason, they tend to affect the way that kernels and other programs interact with the CPU... Bottom line, unless you know exactly what the program is looking for, and that you can add it to the VM, it would probably be best to run bare-metal just for that...

The NVRAM section points to the new BIOS settings entry that gets created for each VM, basically when you create a new VM you are creating a new motherboard with a BIOS of its own... The UUID for the xml file need to point to a BIOS entry that exists or the VM can't boot...

This is probably the best you can do, it will passthrough most of the CPU info to the VM... Just add info to the VM XML file... <cpu mode='host-passthrough' check='none'> ... </cpu> It may be possible to pass in other strings associated with the correct CPU, but knowing what they are looking for would probably be needed for that...

I don't know if this is mentioned somewhere else in this thread (I don't use MacOS), but saw this and thought I would mention it... Apparently Qemu 3.1 (Used in the UnRaid 6.7.0-rc) has issues with Mojave... https://wiki.qemu.org/Planning/3.1

Switching Bare-Metal to VM and back again I have seen articles and posts on, but it is outside my personal experience, it would be like yanking a hard-drive back and forth between 2 motherboards... Windows 10 "ToGo" sticks I am told make this easy, but never tried them out... Windows also has the ability to boot "Bare-Metal" but from a VHD or VHDX image file which is something I have done before back in Windows 7 days, but flipping the image file between VHD(X) and qemu RAW or QCOW2 just seems like a hassle... I currently run my system exclusively as a VM with GPU passthrough, and you can get near bare-metal performance when needed by just tweaking some settings and turning off background processes on the host, which is the kind of thing you would need to do even if you were running bare-metal, so the point of switching between them seems way more trouble than it is worth IMO... Edit: I have a m.2 960 evo Raid-0 that I use as UnRaid cache drive... I store them on there, and just set the "system" share to "Cache drive = Yes"

This may also be caused by not having your motherboard BIOS setup correctly... Make sure that you disable "Compatibility" boot modes in your BIOS, on my asus board this is called "CSM"... This will force UnRaid to boot UEFI, so make sure you turn on UEFI boot on the UnRaid flash settings before you do that... Also make sure that the IOMMU groups are working correctly on your system, Intel VT-d or the AMD version on your board... If it is not either of those, you may have gotten a cheap card that doesn't acknowledge the reset signal that the VM sends it, thus requiring the reset sent from the host motherboard to be able to connect to a VM again...

Most likely you tried to just flip it in the VM settings, but the change is too much for the WebGUI or manually editing the VM's XML... What you do is just create a new VM, but point it at all the existing image files, that will get all the sub devices sorted out correctly... Be careful doing this though, when the new one is working and you delete the old one, it will try and delete the "old" images files at the same time... One more reason to make sure your backups are up to date... When you are all done, you can move the image files around manually to make it look like normal...

Usually this is something filling up, like the SSD or something else... I had something like this when I had a repeated motherboard error filling up my Syslog file, which once it was full, the VM's would just lockup with no notification... Most likely something similar is happening here... If that doesn't help, we need diagnostics files, and the VM XML file...

That is good, but also normal even if not passing correctly, the real test is if the card still works after VM reboot...? If so, then you should finally be good... 👍

https://bit-tech.net/news/tech/graphics/amd-fixes-radeon-vii-uefi-gaffe-with-firmware-update/1/

Switching from one to the other is like yanking the hard drive and putting it in a different motherboard... The i440fx is an ancient chipset for the Pentium 1+2 that never heard of a PCIe slot... Backups should definitely be done, and when you switch it and try to boot, it will take forever to reinstall every single driver on the system... While in my experience it usually works without issue, I won't be responsible if you skip the backups... I also would not expect a major improvement over the i440fx since even though it is having to run additional overhead, it is not that major... I mainly mention it because you and so restricted on the hardware you gave the VM... I have noticed other compatibility issues that still makes it worth it, and the only downside was in the past the q35 hadn't had as much testing... IMO there is no longer any reason for i440fx in windows anymore... Q35-only features ● PCIe “goodies” – Extended configuration space (MMCFG) – PCIe native hotplug – Advanced Error Reporting (AER) – Alternative Routing-ID Interpretation (ARI) – Native Power Management – Function Level Reset (FLR) – Address Translation Services (ATS) ● AHCI storage controller ● vIOMMU emulation ● “Secure” Secure Boot

Typically if you don't passthrough the VBIOS, the first time you boot the VM, it will work just fine, but rebooting the VM would require rebooting the host since there is no way to issue a reset to the video card from the VM without the VBIOS file, and you have to issue a reset the old fashioned way, by rebooting the motherboard it is plugged into... Do you experience this? or does the card never work? If it is always Error 43, there may be some hardware failure here interfering with it... Make sure the card works fine baremetal without UnRaid in the background... At this point we need to verify that is it not a hardware issue before we continue to troubleshoot software...

Trying to run 2 different computers on the same hardware at the same time will cause bottlenecks... One thing I can say about your games you listed is that they are CPU bound, and all want at least 4 real cores... Adding a H.T. Core can usually be guesstimated to add 1/4 of another core, so a 4 core and 4 H.T. system will usually have the speed of a 5 core system with no H.T. You are basically running games that like 4 real cores or more on 2.5 cores... IMO this is the most likely cause of you issues... City SkyLines in particular will gobble up pretty much all the CPU power you throw at it... Windows also can run on 4GB's of RAM, but will start pagefileing most of the ram right after boot, and so I would expect even windows to have issues with this, let alone running a game on it... (The recommended specs for Fortnite are 8GB's, though it does say the min spec is 4GB's) One minor thing, you probably want to change your machine type from i440fx to Q35... But be careful, making that switch is like moving your hard drive to a new motherboard... Backup first, and first boot will take forever while it re-installs all drivers... This will eliminate some of the emulation overheard with running windows on a chip-set from the Pentium 1+2 era... I think most of your issues boil down to needing to assign more hardware to the gaming side of your system... And the sad recommendation is to get a better system...

This is normally done with boot order, just set the hard drive to have a higher boot order than the ISO, then on first boot it will see an unformated disk, and boot the ISO, but the second time it will boot the disk... There are other, more complicated options, like install "Virt-Manager" in the UnRaid app store that gives you something like the Host interface you are talking about with VirtualBox... Or just use a second screen (Like a cell phone or tablet), and when the install is in the process of rebooting, fully shutdown the VM and edit it however you like... There are many other options to solve this issue...

Yah, it can be an adventure... AMD cards can have special issues with CPU scheduling that unfortunately I am not familiar with... Just so you know, the VBIOS dumping thing is because NVidia encrypted their VBIOS as well as the connection between the VBIOS and their drivers... However, they only started doing that on the GTX 10 series and the RTX... You should not need a VBIOS from a GTX710...

This sort of thing sounds like a scheduling issue with the cores, most likely the UnRaid kernel and the Windows kernel both have access to the same cores, and some core is getting scheduled for double duty, thus locking up the other while it gets done... Make sure the VM and the Qemu emulator have their own cores...

Just so you know, the VBIOS passthrough was added for GTX 10 series and RTX cards because NVidia encrypted the VBIOS, as well as the connection between the drivers and the VBIOS... VBIOS passthrough is a workaround to fix this in Windows... One way you can tell that this is not needed is you can edit your bios with an editor and make your own with your own fan curve and such, all of us 10 series people don't get those, and probably never will... From what I understand there is a driver telling the card to do what it is doing, because if there was no driver yet, then the default settings in the VBIOS would still be in charge... Some possible sources for drivers are: UnRaid: Edit your Syslinux config to include all the PCI ids for your card to use the VFIO driver, this prevents UnRaid/Linux from assigning any drivers of its own to it.. kernel /bzimage append vfio-pci.ids=10de:1b81,10de:10f0 initrd=/bzroot (Edit this to match all the device ids on your particular card, just don't add the PCIe slot to the list...) This does make the card not work outside of a VM passthrough situation... or Windows: You have not installed any fan control software for your card... If you have an EVGA card, download and install EVGA Precision XOC... Or you can install MSI afterburner on nearly any card (even EVGA if you like it better)... This should allow you to control the card like it would outside of a VM...

The 1050ti is not the best performing of cards, but typically the way I understand it, you wont get the drivers to load in windows if you don't have a VBIOS for the NVidia card correctly passed through... The GTX 10 series and RTX series and up all encrypt the VBIOS as well and the connection between the VBIOS and their drivers... The VBIOS passthrough is a workaround to get this connection to work in a VM...

The performance issues is minimal, there is some additional overhead from the PCIe to PCI translation that occurs with PCIe passthrough on the i440fx, while the speed change barely reached the level of perceptable for me, the main reason for the fix was I have had several issues with compatibility... For a while, PUBG worked fine for me, then one day when they were adding in anti-cheat measures like battleye, it would fail battleye checks on my system and fail to load. I also had issues with the UWP game Sea of Theives just refusing to load... For me switching to Q35 gave me a minor but noticeable speed improvement, a noticeable reduction is minimum framerates in games (mico-stuttering), and suddenly games that refused to work or had issues no longer had those issues... In the past the i440fx chipset was by far the one most polished by the Qemu community, and Q35 was just buggy or glitchy... From my admittedly limited experience Q35 is fully ready to replace the i440fx machine now, UnRaid already defaults to Q35 for the Linux based VM templates, and I believe there is no longer a reason for the Windows based ones to default to i440fx since even on Windows it no longer seems that it brings any benefit over Q35, and only seems to cause problems... Again, my opinion, and I am still looking for people that actually have issues with Q35... Edit: On you questions: Linux in general, and therefore UnRaid likes to have its primary core on Core 0... Even if you try and isolate Core 0 Linux will still use it anyway... You can isolate the Linux kernel from all the other cores, so you can even force all the UnRaid overhead and emulation down to just Core 0 if you felt the need... There are 2 commands here that affect this sort of thing: The one for the Linux kernel itself is a config you put in your Syslinux config and looks like this: kernel /bzimage append isolcpus=1-3,5-7 initrd=/bzroot This would on my system leave Core 0, and its mirror Hyperthread, which on my system is Core 4, still available for anything the Linux kernel wants to do... Anything that wants to use those other "Isolated" cores has to specifically request them, since the kernel wont hand them out automatically any more... There is a performance hit to running emulation, there is some housekeeping and cleanup needed when running in a VM, and those need to go somewhere... If you don't specifically specify where that work can be done, then if will go back to the Linux kernel to run this... If you have not done any isolation of cores or any other things to mitigate this, it will sometimes run with a higher priority on the cores that the VM (Windows) kernel wants to use... This will cause noticeable pauses, and minor bumps to your performance... We solve this by moving this overhead off the cores we assign to our VM by telling KVM/Qemu where to run this overhead at: <cputune> ... ... <emulatorpin cpuset='0,4'/> </cputune> Remember, you have both a Linux kernel, and the VM kernel (Windows) not talking directly to each other, and so will sometimes try and schedule the same CPU core to do two different things at once... So we trade some performance (some cores are now only used sometimes or even rarely) for a reduction in pauses and glitches (Cores are no longer double booked because we have 2 kernels fighting for the same cores)... Adding NUMA nodes and infinity fabric into this mix makes things even more complicated, and unfortunately I don't have an AMD chip to give advice on that... Getting a good balance between performance and VM lag is up to you and the application/game you are running... Currently I am running without CPU isolation, but the emulator pinned outside of the cores assigned to the VM on my system... This means the emulator isn't causing issues in the VM, but other UnRaid processes potentially could, however I don't run many docker containers or other UnRaid processes, and so for me UnRaid acts mostly as storage manager...

Good luck with that, the USB3 type A port is literally just a USB2 type A port with 5 extra wires for more lanes and faster bandwidth... If you don't connect anything to those 5 extra wires, you literally have a USB2 port, so it should not matter which port you plug it into... Sounds like you have a fun one on your hands...