Warrentheo

You have both systems setup to consume nearly 100% of available physical ram, unfortunately lock ups are the expected behavior when you do that... It is not actually locking up, it is trying to use your swapfile like RAM, because the fact that it is a swapfile is not told to the VM's... This can cause all kinds of processes to have a timeout cascade... If you really need to not upgrade the RAM on your system, then set the VM's to use much less physical RAM, and setup swapfiles in the individual VM's... However there is no real substitute for just having the free RAM to begin with...

Everything on Linux is a file, its very different from windows that way... If you don't want to point it at: /mnt/cache/domains/Windows/vdisk1.img then point it at something like this instead: /dev/disk/by-id/ata-Hitachi_HDS5C3030ALA630_MJ1321YNG06KNA this points it to the devices folder, selects a block device disk, and this is important, it selects it "by-id" so that if you ever change your partitions or drives it doesn't break where the VM is pointing... there are others, you can select by several others, check out what you have in your /dev/disk/ folder on the UnRaid host... Be Careful, Linux will happily let you specify the wrong one and let you overwrite an important data drive, so double-check you got the correct one...

Here is a review I found on the amazon page for your motherboard: https://www.amazon.com/Supermicro-X9DAI-LGA2011-USB3-0-Motherboard/dp/B007HVZBWM#customerReviews Bottom line, this appears to be a motherboard issue... There is a 3.3 Version of your BIOS (you currently have 3.2) this may or may not help... https://www.supermicro.com/products/motherboard/Xeon/C600/X9DAi.cfm (Then click update BIOS)

You need to pass in all the devices in the IOMMU group, in your case, it means you need to pass in: 1002:aab0] 02:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Cape Verde/Pitcairn HDMI Audio [Radeon HD 7700/7800 Series]

Best option with VM sound issues is almost always to just get a USB sound card that does what you want it to do, and pass that in...

Could be a large number of things, unfortunately you haven't posted any info about your system, not even if the VM is Linux or FreeBSD or Windows 98... Please add the Diagnostics file from your UnRaid host (WebGui-->Tools-->Diagnostics-->Download) And the XML file from your VM (WebGui-->VM's-->Edit the VM-->Switch from Form View To XML View-->Copy everything there to a text file and add it here also)

********************************************* EDIT: Turns out my system really is having a GPU issue, will deal with RMA and retest this fix... ********************************************* Adding this caused several other issues... It booted but was glitchy at first, but still didn't allow bluetooth usb passthrough... During playing a game with it on it suddenly crashed out, and the VM would no longer boot, it seems it breaks my daily driver Win10 VM with the webgui error message: Execution error internal error: Unknown PCI header type '127' Which from what I can see on other posts means that it is not able to do GPU passthrough correctly anymore: At first I thought I had killed my video card somehow (didn't think it could be bluetooth related), and tried several things to fix the issue, manually rebuilding the VM XML, didn't work, completely rebuilding the libvirt image and then manually rebuilding the VM's xml's didn't help either.. I decided just for troubleshooting that I would undo the bluetooth settings: append fbcon=rotate:1 module_blacklist=bluetooth,btbcm,btintel,btrtl,btusb BIND=01:00.0 pci=noaer initrd=/bzroot and switched it back to: append fbcon=rotate:1 BIND=01:00.0 pci=noaer initrd=/bzroot and after a reboot, I was able to get my daily driver back... I have attached a diagnostics and vm xml file from just before switching off the blacklist in sysconfig and rebooting... qw-diagnostics-20190324-1905.zip war.xml

Prime95 uses a part of your CPU called AVX or AVX2... This puts so much stress on the CPU that most motherboards have a setting in their BIOS to UnderClock the CPU when it detects an AVX workload... Prime95 is an unrealistic CPU stress test for this reason... By default my motherboard BIOS drops 200Mhz off the clocks, and I have my overclock set to drop 300Mhz off the clock intentionally just for testing with Prime95... On my motherboard this is called "AVX instruction core negative offset [Auto] [1-31]"... Something like 3DMark is a much better CPU test for this reason... Overclock for normal load stability first, then downclock from there for AVX load stability...

Here is some consolation... The new AMD Thread Ripper and Epyc chips are basically multi socket CPU's in a single CPU, and I am sure Intel is not too far off from the same sort of thing... The rest of us will need learn this stuff soon anyway, you will just be ahead of us 😛

Hazards of having a server grade dual socket board... You need to become an I.T. Admin to be able to run all the cool things on it 😛

It is also possible to manually edit the XML for the VM to make what ever configuration of NUMA nodes you wish, basically make what ever kind of processor you wish, as long as windows kernel knows what you want... https://libvirt.org/formatdomain.html#elementsNUMATuning I would recommend search for "NUMA" on that page, and seeing all the different settings you can configure...

Some of those use the ones that are part of the motherboard, which usually has the same issues as using the ports that come with the motherboard... This is the one that I use: Inateck KT5001 PCI-E to USB 3.0 5-Port PCI Express Card and 15-Pin Power Connector, Red https://www.amazon.com/gp/product/B00FPIMJEW/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1 Works very well, and supplies power which is something you need to consider, the power coming from your motherboard is not going to be able to light up all the stuff you plug in, so you will either need to get a powered USB hub and plug that in, or get one that taps power off from the power supply directly... This one also has a second internal header, so you can connect up some of your front panel case ports to it to pass them also (on mine this is 2 ports on the front, 5 in the back, you will not find a card that does better than 7)

It can be possible, but the short answer is "don't"... Get a separate card instead... Some motherboards have several separate "cards" mine has 3, one 3.1 Motherboard header, one 3.1 on the rear, and one 3.0/2.0 running most of the remaining ports on the back... One controller needs to remain to be able to run the UnRaid USB thumb drive, and on my motherboard the remaining 2 other controllers have issues with IOMMU groups and don't passthrough very well... I can still pass the individual devices, but that basically requires that they be permanently connected and never change... Ok for some devices, but not all... The best way to get them to act like a normal controller is to pass a controller of its own to the VM... You may get lucky and your motherboard may have more than one controller, and one of those controllers my be passable to the VM...

Just to be clear, using the english translation of <emulatorpin cpuset='0-4'/> is "Pin the QEMU emulator to only use cores zero through 4 of the host" (a total of 5 cores BTW, only 1 or maybe 2 to be safe should be needed) Most likely you would want to avoid using a hyphen when doing this designation... The english version of: <emulatorpin cpuset='0,4'/> is "Pin the QEMU emulator to only use cores zero or 4 of the host" (a total of 2, or really 1+ its HT, or about 1.25 cores) That comma vs hyphen makes a big difference... The name of your video card threw me for a bit, because MSI actually does have something to do with this issue, but MSI has 2 different meaning in this context: MSI = Micro-Star International and MSI = Message Signaled Interrupts (https://en.wikipedia.org/wiki/Message_Signaled_Interrupts) Message Signaled Interrupts actually was the next thing I was going to have you try, I have attached a utility that may help with that... This is a small simple utility that shows the windows registry settings for the PCI devices on your system, and displays their MSI status, as well as letting you enable it if needed... MSI basically lets the video card bypass the CPU to talk to ram, allowing it to run much faster... It is a bit like DMA access... Most likely if you passed in your GPU, it is not set to enable MSI interrupts, and this utility will let you enable it, then reboot... I have to use it every time the drivers are installed or updated for my GTX1070... MSI_util.exe

Add this to your XML file: <cputune> ... ... ... <vcpupin vcpu='6' cpuset='7'/> <emulatorpin cpuset='0,4'/> </cputune> and adjust it to your setup, this will move the Qemu overhead to whatever CPU core you wish... By default the Linux kernel and the Windows kernel try to use the same CPU cores, this forced handoff and inability for one kernel to reliably schedule tasks for those cores is what is causing this sort of thing... The extreme example of this is to also add: ... isolcpus=1-3,5-7 .... (Again, adjust to your setup... Any cores set this way will be unavailable to the Linux kernel, only usable if something specifically requests them...) to your syslinux config... UnRaid will use CPU 0 no matter what you put here, but any cores you isolate will only be used if something like QEMU comes along and specifically requests to use them after that... This will force a separation between the Linux Kernel and the Windows Kernel... On my setup, an i7-7700k, 64gb ram, at first I ran with the first core and its hyper-thread Reserved for UnRaid, used Emulatorpin to pin QEMU to them also (possibly redundant after CPU isolation), then ran windows on the remaining 3 cores and their HT's... While this worked, I realized I was having about 25% of my CPU sitting idle... Currently I removed the Isolation, which allows Linux to have access to all cores, set EmulatorPin to only core 0 (without it's HT), and run windows on 3 full cores and one HT... This allows Windows and Linux to share the primary core while not actually sharing it... Been running this way for 6 or 7 months, and think it works much better... This however means that if I start using the Linux side more (or Docker also), that Linux has the ability to max out all 8 threads and kill my VM... I just currently use the Linux side sparingly, so for me, this works...

The top pinned thread is all about this: I suspect however that a NUC will be severely under-powered for that task... Even after iGPU passthrough...

I have been trying to kill this driver for a while, and have been unable to find a workable solution... I even reported the question General support: and have been unable to get an answer... The normal solutions I have found on the internet are not working under UnRaid apparently... I am willing to try and help any way I can, but I am stuck... We need to have a way in place to kill this if needed before 6.7.0 rolls out... Thank you in advance, I really like UnRaid and use it everyday, and your help on this is appreciated 🙂

Duno, I have always hated dealing with Linux permission issues, and so made sure to never add another user to UnRaid just to remove these type of issues (do security with firewalls instead) I suspect you will need to use "New Permissions" tool under tools, or if you have the plugin installed, the "Docker Safe New Permissions" version... But be careful with that, if you don't know what it does, it has the possibility of screwing up all you Linux permissions... Possibly not much of an issue for someone getting rid of UnRaid though...

You will want to make sure they are comparable for speed and such, otherwise you will have strange slowdowns and speed ups that will be hard to explain... But this might help:

Yah, but you need to be careful... No parity drive + different storage permission models can easily lead to data loss... This might help, lets you move data off of a drive so you can use it elsewhere:

Right off the bat, I can see that you are going to have this problem, and will want to watch this video: Also, those log files show no USB devices plugged in: Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 002: ID 154b:00d5 PNY Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub These are just the Root Hubs for the USB controllers on your motherboard, and I assume the PNY USB stick you have UnRaid on... It doesn't even show the keyboard and mouse you have connected (do you have a P/S2 style keybaord/mouse?). Either the motherboard drivers are not working correctly (unlikely since the Root Hubs from those drivers showed up) or the USB devices in question are either broken or not connected... You are also going to want to remove: ... pcie_acs_override=multifunction ... from your syslinux config unless you have a specific problem you know can be corrected by it, since it causes other problems you should avoid if you don't need them...

I am having issues with the new bluetooth drivers added to UnRaid to support bluetooth in the docker containers... These drivers grab my USB bluetooth and prevents me from passing it into a VM now (Locks up VM and causes other issues) I have already started a new bug report for this issue already, and was told this is not a bug, but a feature 😕 Not a huge problem for my situation since I only occasionally use it in my VM, however I do think other people are going to need this info, and eventually I am going to need my bluetooth again, so I have been trying to figure out how to fix this issue... For various reasons, I am not willing to move the device to the passed through USB controller or other adjustments to the hardware to fix this issue, it was caused by a software change, and will need a software change to fix it... The main issue is that it currently looks like there no way to disable this driver correctly, the other solutions I have found on my google searches have not worked, some things I have tried: ...... rmmod btusb rmmod btrtl rmmod btintel rmmod btbcm rmmod bluetooth # Start the Management Utility /usr/local/sbin/emhttp & rmmod: ERROR: Module btusb is not currently loaded rmmod: ERROR: Module btrtl is not currently loaded rmmod: ERROR: Module btintel is not currently loaded rmmod: ERROR: Module btbcm is not currently loaded /var/tmp/go: line 15: $'r\357\273\277mmod': command not found ... bluetooth.blacklist=yes ... So it appears that while the drivers have been implemented, the method for disabling them is either not implemented yet, or non-standard... I am afraid I am at the limit of my Linux knowledge on this, and was hoping someone else might be able to help point me in the right direction... 😉

Please edit the VM, switch the view from "Form" view to the XML version, copy it all out to a text file and add it to a post, then also goto tools-->diagnostics in unraid, download them, and add them to that post also... This should give us more info 🙂

Stuff plugged into PCIe slots are not like USB ports, they require reset signals from the motherboard to reset themselves and connect to a new computer... The process of passing through a GPU to a VM is a bit like moving the GPU from one computer to another without powering anything down first, so we need the Host to not be using it at the time, and we need to be able to send a reset signal to it when we connect it to the VM instead... If you boot the linux kernel normally, it expects to be able to use every device it discovers, and so will load drivers for the GPU, and then use it to show stuff on the screen... To prevent UnRaid from using the GPU, we need to tell the linux kernel during boot to not hook into the GPU, we do that by telling it to use the vfio-pci driver for the GPU instead... This "driver" is more like a plug for something else to provide the driver instead, and just specifies the shape of that plug rather than do anything to the GPU... If you "stub" one item in an IOMMU group, you should stub them all, and pass all items in the group (except the PCIe slot) together... You are going to want to edit your syslinux to re-arrange somethings: BOOT_IMAGE=/bzimage vfio-pci.ids=1002:67df,1002:aaf0,1b73:1100,8086:10d6,8086:15a1,1b21:1242 video=efifb:off initrd=/bzroot The "initrd=/bzroot" should almost always be at the end, and the "video=efifb:off" also should not be needed... You will probably also want to add "10de:128b,10de:0e0f,19da:5360" for your NVidia card if you plan to pass it through... Unfortunately alot of this comes down to how your motherboard interacts with the GPU's you put in it, so some of this comes down to experimentation on your part to see what works for you...

I have been looking through this one, and I am currently at a loss ( I use NVidia, and so don't have much experience with AMD, but I understand that AMD's should be easier to pass since they don't encrypt things like NVidia does)... Some things to try: Make sure to boot the host as UEFI (Disable any legacy boot mode of CSM mode in the BIOS after making sure that EFI boot is enabled for UnRaid) Try temporarily removing the NVidia plugin, as well as move the 580 to the primary motherboard slot (Remove the 1070, and if everything works, put it back in slot that the 580 is currently in) The error you are getting indicates that the motherboard is unable to reset the PCIe slot for the graphics card, so the IOMMU group passthrough is not working correctly... There are sometimes weird issues with motherboard and GPU combinations... Slots - 2 x PCI Express 3.0 x16 Slots (PCIE2/PCIE4: single at x16 (PCIE2); dual at x8 (PCIE2) / x8 (PCIE4)) - 1 x PCI Express 2.0 x16 slot (PCIE5: x2 mode) - 2 x PCI Express 2.0 x1 Slots - 1 x mini-PCI Express Slot - Supports AMD Quad CrossFireX™ and CrossFireX™ - Supports NVIDIA® Quad SLI™ and SLI™ - 15μ Gold Contact in VGA PCIe Slot (PCIE2) *If M2_1 slot is occupied, PCIE2 slot will run at x8 mode, and PCIE4 slot will run at x4 mode. **mini-PCI Express slot is shared with PCIE3 slot.