JorgeB

This is not normal.

Yep, it should work with virtIO and SCSI, not sure about SATA, note that you then should run trim inside the VM at least once after the change.
 
Doing this and running TRIM on all VMs should reclaim most of the space.

Yep.

Recreate the docker image
https://docs.unraid.net/unraid-os/manual/docker-management/#re-create-the-docker-image-file
Then:
https://docs.unraid.net/unraid-os/manual/docker-management/#re-installing-docker-applications
Also see below if you have any custom docker networks:
https://docs.unraid.net/unraid-os/manual/docker-management/#docker-custom-networks

It's possible, you can try swapping/using a different m.2 slot if available.
 
It's not not recommended, but for a single device pool, and if you don't care about checksums or snapshots, xfs is fine, but the issue was not caused by zfs, it just adds the not able to stop the array problem, that won't happen with btrfs or xfs.

SMART looks OK, check/replace cables and assuming contents for the emulated disk look correct you can rebuild on top.

Update all plugins, especially Connect, then try again

xfs_repair is failing, you can try 7.0.0-beta, since it includes a newer version, if the same, the best bet will be using a file recovery app, like UFS explorer.

Check filesystem, for the emulated disk1, run it without -n, and if it asks for -L use it.

v6.12 only supports replacing one device at a time, even for raidz2/3, v7.0.0-beta can do both at the same time.

I believe this is normal with Ubiquity equipment if you have bridging disabled, if you are on v6.12.10 try bridging enabled with ipvlan, with 7.0.0-beta you should be able to use macvlan with bridiging enabled without issues.

Jul 19 02:38:55 Flair kernel: nvme nvme2: Does your device have a faulty power saving mode enabled? Jul 19 02:38:55 Flair kernel: nvme nvme2: Try "nvme_core.default_ps_max_latency_us=0 pcie_aspm=off" and report a bug  
Add 
nvme_core.default_ps_max_latency_us=0 pcie_aspm=off to the syslinux boot options, then power cycle the server to bring the device back, a reboot is usually not enough, and run another scrub.

See here:
https://docs.unraid.net/unraid-os/release-notes/6.12.0/#share-storage-conceptual-change

Probably due to errors in one or more disks, but would need the diags to confirm

Jul 18 22:30:21 Tower emhttpd: device /dev/sde problem getting id  
This means Unraid is seeing some devices twice, this will happen if you have multiple cables connected to an enclosure, Unraid does not support SAS multipath, so make sure there's only one cable going from the server to the enclosure.

You just need to create a new pool in the GUI, change to two slots, assign both disks, click on the first pool device, then erase, then set to zfs and stripe, then start he array and format the pool.

That confirms no valid xfs filesystem exists on that disk

That confirm the new disk is larger, this is uncommon, any of the drives came from USB enclosures?
 
Solution is to do a parity swap.

That crash is related to zfs, start by running memtest, could also be related to the Intel 13/14 series instability issues.

Why not just recreating the image?
 
https://docs.unraid.net/unraid-os/manual/docker-management/#re-create-the-docker-image-file
Then:
https://docs.unraid.net/unraid-os/manual/docker-management/#re-installing-docker-applications
Also see below if you have any custom docker networks:
https://docs.unraid.net/unraid-os/manual/docker-management/#docker-custom-networks

There are two libvirt images, one on cache and one on disk1, see witch one is the correct/better one and delete the other.
 
Thanks for the beer money!
 
 

Could be related to this issue:
https://forums.unraid.net/bug-reports/stable-releases/61210-cannot-fork-resource-temporarily-unavailable-r3020/?do=findComment&comment=28397
 

Most likely 
 

You should ask in the existing support thread for that plugin:
 
 

Then it's almost certainly hardware, if it's not RAM, could be board/CPU