John_M's post in (SOLVED) Filesystem failures when system is under load was marked as the answer
The reason I said the RAM was a slightly odd choice is that it's specced at DDR4-3600 but the maximum your CPU can run at is 3200 MT/s. That figure is derated by your particular configuration - you have two DIMMs per channel and they are dual-rank. Becuase that's a lot of physical chips connected across the bus the recommended maximum speed for a 3000-series CPU is 2666 MT/s. So you might have paid more for faster RAM when slightly slower RAM would suffice.
2133 MT/s is fine. I was asking why you weren't running it at 2666 MT/s and if the reason is that you had decided to slow it down in an attempt to avoid the errors.
The BTRFS errors I pointed out are real errors - hardware errors, I believe, and they are present in both sets of diagnostics - i.e. before you start the VM. Check the timestamp. The system runs fine before you start the VM but since the VM makes heavy use of the cache pool the problems begin when you start the VM.
On the question about power delivery, the Pro 4 series has weaker VRMs than more gaming orientated motherboards and the B450 series was designed for the 2000-series of CPUs. Your 3950X is rather more power hungry than the top CPU in the 2000 series (the 2700X). I don't think it's an issue in your case but it is why I asked what your VM was doing, thinking you might be using it to thrash the CPU.
If you're happy with the RAM the next thing to address is the NVMe cache.
John_M's post in How does tower.local "work"? was marked as the answer
The .local domain is a special case. It's a pseudo-top level domain that has been set aside for use by the multicast DNS (mDNS) service, originally developed by Apple as Rendezvous and more recently known as Bonjour, with the aim to provide "zero-configuration networking". Apple released the protocol to the open source community in a series of RFCs and it has been adopted and incorporated into other operating systems, e.g. the avahi daemon provides mDNS for Linux. Instead of querying a centralised DNS server, mDNS requests are multicast to all hosts on the local network and if an mDNS-supporting host recognises its own name it responds with its IP address, using a similar data structure to that used by a conventional DNS server. For a particular container to support mDNS it would need to be built with avahi included.
John_M's post in Unraid 6.10.3 Find parity disk was marked as the answer
In the unique situation where you have one data disk and one parity disk and they are both the same size, their contents are identical because that's how even parity works.
You could probably assign either as either and it would be ok. However, you might want to adopt a more cautious approach.
Here's what I'd do. I'd choose one of them and temporarily disconnect the other (so if things go wrong you at least have a second chance). Do a new config and allocate your chosen drive as disk 1, no parity. Start the array and check that your files are ok. Once you're happy you can shut down, reconnect the other drive, add it as parity and let it rebuild.