JorgeB

You can ignore that message.

Did you import it before or after the array started? If it was mounted, Unraid cannot import it, and it will show unmountable.

A kernel change can sometimes affect things like that, where in some boards or hardware it worked with the previous kernel, and it doesn't with the current one. If that's the case, a future kernel update may also resolve the issue.

Not that I'm aware, the way I see it is if it's only writing to one disk or multiple.

The UUID doesn't match the pool, how did you format that disk? Also post the output from zpool import (withthe array started)

Does creating a new VM with the same settings but a new vdisk work?

Those stats suggest one of the devices dropped offline in the past, scrub the pool, and if there are no errors or all errors are corrected, reset the stats and keep monitoring, if it drops again, replace the cables for that device.

I wouldn't move before figuring out what is causing the current issues.

Btrfs is detecting data corruption; the first recommendation is to run memtest.

Post the diagnostics after array start.

BTW, just found a user with a 9305-16i running Unraid without this issue, so it's not a general problem: 08:00.0 Serial Attached SCSI controller [0107]: Broadcom / LSI SAS3224 PCI-Express Fusion-MPT SAS-3 [1000:00c4] (rev 01) Subsystem: Broadcom / LSI SAS9305-16i [1000:3190] Kernel driver in use: mpt3sas Kernel modules: mpt3sas Jun 1 22:06:14 DL380G9 kernel: mpt3sas_cm0: FW Package Ver(16.00.12.00) Jun 1 22:06:46 DL380G9 emhttpd: Unraid(tm) System Management Utility version 7.3.1

I'll need to investigate why you ae siieng a different behaviour than in my testing. I don't think that would work using the CLI, and could leave the pool in an unexpected status. It should work using the CLI, but then I would expect it would take a similar amount of time moving the data to the new vdevs.

Check/replace cables for disk5

A single 2 way splitter per cable should be OK, but it's always best to avoid them when possible.

Look on Main for the flash drive identifier; it should show in the unassigned devices section.

Please post the diagnostiscs and VM name (if there's more than one)

Please post the diagnostics

Best bet is to use the Nvidia plugin support thread.

Please recheck; those diags are form two different servers.

You don't need to do anything, but if you want to use an internal boot pool instead of using the flash drive, you now can.

Try recreating the flash drive, first backup the current one, then recreate it using the USB tool, confirm the flash drive boots with the stock install, and if yes, restore only the /config folder from the backup overwriting any existing files.

The flash drive wasn't using the correct partiton layouit: Jun 2 21:53:24 Hells5 emhttpd: Error: (/dev/sdg) not known 7.3.x is more strict about that.

Best bet is to look for the support thread for that container

You can create a Linux kernel bug report, or just wait for a newer release, since those controllers are well used, I would think a fix would be available soon.

It should import it cleanly, and you can delete the snapshots after.