itimpi

one begins to see a pattern after a while to certain types of error  
 
If no hardware is being passed through then there is no reason not to start the VM.

You left out the key step - Apply.   The Done button is equivalent to a Cancel.

Your syslog shows continual resets on the 8TB drives - in particular disk6 and disk7.  You should carefully check SATA and Power cabling to those drives.  
Since you have just added some extra drives are you sure the power supply can handle them?

Email limtech using the contact link at the bottom each forum page.

According to your diagnostics your docker.img file is corrupt.    It probably needs to be recreated and the docker applications reinstalled.
 
I notice that you have this file set to be 200GB - is there any reason you have it set to such a large value.    The 20GB default size is fine for most users and 30GB enough for the more extreme users. Have you had trouble with it filling up - if so this suggest misconfigured container(s) that is writing internally to the container rather than to externally mapped storage.

Have you read the 6.10.2 release notes and the issues around the tg3 NIC driver?   You may need to take the steps to unblacklist that driver to get your network working if you think your hardware is not one being affected by the tg3 issue.

That tends to indicate a problem reading a file off the flash drive.    You might want to try following the procedure here to see if it helps.

Have you checked to see if the EFI folder on the flash drive has trailing tilde character?   If so you need to remove this to enable UEFI boot.

You click on the pool on the Main tab; scroll down to the Balance section; select the Single option from the dropdown and then start the Balance as described here in the online documentations accessible via the ‘Manual’ link at the bottom of the GUI.

That looks as if no major corruption was found.
You need to run without the -n option if you want anything to be fixed, and if it asks for it add the -L option.
 
Restarting in normal mode should mean the drive then mounts OK.   Look to see if you now have a lost+found folder - if not all data should be intact.

it looks like disk have slightly different ways of reporting their serial numbers under 6.10.0 on your system.

You should be able to:
Use Tools->New Config and use the option to keep all assignments return to the Main tab and correct all drives to have their new version of the serial numbers tick the “Parity is Already Valid” checkbox start the array and with any luck everything will now come up as normal.

Just realised that I did not answer this bit.  In this case the time to rebuild a drive is determined by the size of the drive being rebuilt (at the same 2-3TB per hour estimate as used for the parity build) so if the disks are smaller than the parity drives it does not take as long.
 
Another way to look at it is that both processes involve writing to every sector on a drive so how quickly that can be done is the determining factor.
 

I assume the disk that should be disk3 is the one with WSD0QVWE as its serial? My guess would be that you disturbed its connection when adding the drives you now want as Unassigned drives.   It is showing up OK in the SMART reports and it looks OK there.
 
Does Unraid show that disk3 is currently being emulated?   If so check that the emulated disk has the content you expect as the process for getting it back into the array involves rebuilding the drive with the contents that are shown as present on the emulated disk3 by stopping the array; assigning the disk as disk3; and restarting the array to rebuild the physical disk3 to match the emulated one.
 
if the emulated disk3 does NOT show the expected content then do not rebuild but post back here for advice.

If the vdisks were in the 'domains' share then this is set with
shareUseCache="prefer" which meant you WANT the files on the cache, and if mover finds them on the array it should move them to the cache (space permitting).
 
You also do not have a Minimum free Space set for the cache, and it is a good idea to have this set to be at last the size of largest file you expect to copy there in normal use at it is not unusual for corruption to occur if is gets completely full.
 
 

Have you tried clearing cookies/cache in your browser (or using incognito mode).

The 2 step procedure is the way to go.  
 
At each stage make sure you keep the disk just removed with its contents intact until that stage has successfully completed as that gives you a fallback option if anything happens to go wrong.

The syslog suggests you are getting a crash in the driver that handles your NIC.   It might be worth trying the 6.10-rc8 release to see if that has an updated driver/kernel that works OK on your hardware,

You have the CA Backup plugin scheduled to start at 6:00 am every day and that will be what is stopping the containers until the backup is finished.

It depends on the BTRFS profile they are set to use.   The default is raid1 and that means they are protected, but the usable space is only that of the smaller device.

I think you have to copy/paste it into a new script entry within the User Scripts plugin.

I think you have two conflicting requirements here?    If you have the GP’u isolated so that it can be passed through to a VM then it is not visible at the Unraid level and needs to be controlled from within the VM.

After initial boot Unraid runs from RAM so the /etc location is only in RAM and (as you found) not persistent.  If you want to make such a change persistent then you need to apply it every boot.  This is typically done either by adding appropriate entries in the /config/go file on the flash drive or by using the User Scripts plugin.
 

The easiest thing would be to plug the drives into Unraid as Unassigned Devices and use the UD plugin to partition and format them correctly for Unraid (as XFS or BTRFS) drives.   You can then use them on other systems to add files and when you add them to Unraid (as long is there is no current parity drive) then Unraid will accept them and leave their data intact.

Handling of unmountable disks is covered here in the online documentation that can be accessed via the Manual link at the bottom of the GUI. 

If the folder really is empty then you can safely delete it. Nod sure why it was created in the first place if it really is empty.
 
It should also get removed if you:
Disable the Docker service (under Settings->Docker) to ensure it is not holding anything open at that location Run mover manually from the Main tab to move any files that might be there to the cache. Re-enable the Docker service.