meep

Also for troubleshooting, try to not have vnc and gpu assigned at the same time. Use splashtop or some other remote access software (not rdp).

If you check the properties in device manager for the basic display adapter, you’ll likely find a -43 error. nvidia drivers do not play nice when they detect the host is a vm. please check the steps outlined in the link in my sig to get started resolving this.

There's a degree of trial and error with all these things. If you reserve 2x cor3es for unRaid, at the expense of your VM, but VM is smoother, I'd take that as a win. Have a look at this thread if you haven't seen it - some good info and tweaks here; You also haven't mentioned if you have any dockers or plugins running? If so, these will need some resources as well. Also, be aware that copy operations to the array require unRaid to calculate parity. This is an intensive process that likely explains some of the CPU max you observe (but not all). You can alleviate this by correctly configuring the cache disk and offloading to the array at a more convenient time (middle of the night, or whenever you're not gaming). You might know all this, of course, but just in case.

Hi. Came here from a post on reddit. I had a look at your diagnostics there, and there are a few oddities - mainly the 'Pod' and 'Tumbler' VM XML files appear to be truncated, so I cannot see how the GPUs are assigned. Also, from analysing this, I think you might be looking in the wrong place, or at the wrong thing. Your logs are filled with BTRFS and disk errors. Rather than thinking the second GPU/VM is causing the crash / disk errors, have you considered that the disk errors might be causing the VM crash? It looks like your 'domains' share (where the VM images are stored) is set to cache prefer and your cache is BTRFS . If there's a disk error, your VM files could corrupted and cause the VM to crash. In my experience, BTRFS has been a very poor option for cache file system (two catastrophic crashes resulting in data loss). My next step here would be to reconfigure my cache to be a single drive with XFS (preferably a different physical drive on a different controller to eliminate possible issues with a bad disk, controller or cable)). hen I'd re-create my VMs ensuring the data is on this safer single drive and see where it goes from there. Also, check out the blog link in my footer for some tips on GPU config. It looks like you've done a lot of them already, but you might find a nugget!.

Do this. be sure to include if you are booting unRaid in UEFI or Legacy mode, and if switching this makes any difference to you.

Check out the link in my sig. you might find some tips there. was the bios updated for mining optimization? If yes, you might need to roll it back, or pass through a bios rom file.

Check out the link in my sig - I've written up a cheatsheet of sorts to help with this kind of thing.

For future reference, @Masterbob221's problem was he was adding the multifunction tag to the source element GPU video dev node in the XML, when it needed to be added to the virtual address line.

Great news on the iommu groups! You don’t have an os install image defined. as you are setting up the vm afresh, you need to point to an install iso to get the os installed

I had a quick look and don’t see anything obvious. Plus it’s my turn to get some sleep! try some of the steps above. Also, try switching off ALL the usb passthrough s, and see if you can then edit xml. If yes, switch on usb one at a time and use a process of elimination to figure out if one of these is the case of the problem if you don’t figure it out, and no one else can help, we can do another discord session tomorrow.

You cannot change the bios for an existing vm. You need to create a new vm with the changed settings. Since you have the same boot issue in vnc, that rules out the gpu as the source of the problem. It’s very difficult to read the specific windows error your encountering,, but if this runs on different hardware, it’s likely something to do with part of your vm config that’s specific to your old system. starting fresh with a new vm on this new hardware should point you in the right direction. for iommu, have you checked your system bios to be sure there’s no configuration there that you need to turn on to enable iommu?

Hi again! try to make a change using the visual editor, say adjust memory assignment in the vm, or toggle a cPU. Click update and see if that sticks. if it does, try the xml edit again. You need to be careful in editing the xml that you don’t inadvertently cause an error in the file, like accidentally leaving out a quotation mark, or deleting an angle bracket. try making the xml changes one at a time to see if you can narrow down which one is the problem. also, when you get it working, get into the habit of saving datestamped known working versions of the xml that you can revert to in case things go wrong with further edits. plus do post diagnostics (tools -> diagnostics)

Also, does your vm boot ok when using vnc, with no gpu passthrough. it might be worth your while stepping back to vnc, solve the usb issue, then tackle the GPU.

A little perseverance and you’ll overcome these issues. Once you develop an understanding of what’s going on, you’ll be spinning up VMs like a pro. for gpu issue, what is the machine type and bios you have configured for the vm? Seabios usually works best for gpu passthroug, and switching between q35 and i440 machine types often solves a lot of problems.