John_M

For that reason it isn't possible to say why the disk was disabled but bad connections are the most common cause. However, the disk seems ok from its SMART report, if rather too hot. I'd replace the SATA cable, check the power cable and then rebuild onto the same disk. With the array stopped, unassign Disk 2, start the array, stop the array, reassign Disk 2 and let it rebuild. And give some thought to improving the cooling.
 

From your syslog:
Nov 4 12:21:12 WellsTower kernel: uhci_hcd 0000:00:1a.0: irq 16, io base 0x00001f20 This shows that a USB controller is using IRQ 16. Also:
Nov 4 12:21:12 WellsTower kernel: scsi host11: ioc0: LSISAS1068E B3, FwRev=00192f00h, Ports=1, MaxQ=266, IRQ=16 IRQ 16 is being shared with an HBA. The USB controller is a version 1.1 type and you don't appear to have anything plugged into to it. You might be able to disable it in the BIOS. If interrupts from the HBA are being ignored you might see a loss of disk performance.
 
Things you could try include disabling the USB controller, moving the HBA to a different slot, looking for a BIOS update, following the advice in the error message:
Nov 4 12:25:14 WellsTower kernel: irq 16: nobody cared (try booting with the "irqpoll" option) or, if you don't notice any real performance issues, simply ignoring it.

It's the Power Supply Idle Control setting. You'll find it under the extensive AMD CBS section of the BIOS. The default setting is Low Current Idle (or maybe Auto). Change it to Typical Currrent Idle and leave the C states options at their default values.
 
However, this is only effective against freezes when idle, not re-boots.
 

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.
 

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.

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.