JonathanM

Memtest?

No PCIE slots?

Windows update will fill that space rather quickly. If you can't give the VM more space, maybe try using one of the "Lite" windows installs with all the extra junk stripped out.

If possible replace the liquid cooling with standard heatsinks and fans. Liquid cooling is great for gaming machines that are in view constantly while in use, but very bad for unattended servers. The failure modes for liquid cooling can be catastrophic if not caught quickly.

Unraid doesn't require it, but some motherboards halt before booting if no graphics chip is found. Some of those motherboards do have a setting to boot regardless, but you need to be able to get into the BIOS setup to make the change. How do you know the motherboard is actually set to boot from the Unraid USB stick?

Holy necro batman!

This is the server. The client is packaged with it, and is deployed from the server GUI. I use binhex version extensively, the basic premise is that you log in to the server GUI, add the client description, then download the client from the server's GUI.

What differentiates your template from @binhex's? Whenever there are different templates for the same app, it helps if you tell people why your implementation is different so they can choose wisely.

Not directly. You could create a script that watched for a specific named file in a private share, that user could create said file, the script would reboot the container and delete the file.

?

Sometimes they work, many times they don't. The translation circuits between USB to SATA vary wildly in quality and performance, it's much better to use direct SATA or SAS.

Good news is, GUI boot order is working, sort of, mostly, now. At least it's better than it was when I wrote that.

Unraid doesn't support EXT4 for the array or pools, so that's one choice out of the way. 🙂 Multiple simultaneous writes are better suited for pools, the legacy "Unraid" parity array is more suited to write once read many, like media archives and such. The single or dual dedicated parity disks are the limiting write performance factor in the "Unraid" array. Be very careful using encryption, it limits recovery options if things go wrong, so be extra careful with your backup strategy if you decide to use encryption. Good news though, each disk in the Unraid main array can have a different filesystem, so you can have XFS, encrypted XFS, BTRFS, encrypted BTRFS, ZFS, encrypted ZFS, all protected from single or dual disk failure by 1 or 2 parity drives. Parity in the Unraid main array is file system agnostic, it recreates the entire disk regardless of filesystem. ZFS is only available in 6.12 Pools can be single volume XFS, or RAID BTRFS or ZFS. So, your storage can be tuned to your needs, fast SSD pools for high I/O, and mix/n/match disks in the parity array.

Don't know if it applies to your specific setup, but I've seen anecdotes of needing to keep a VM running to keep the power consumption of a graphics card low. Apparently some cards stay in high power mode until told to simmer down by their drivers, which in Unraid generally means inside the VM if you are using the card for VM's.

Now that pools have ZFS and BTRFS RAID options available, feel free to mention RAID whenever the need arises. 🤣 Unraid is so much more than just the way it handles disks.

The only issue I see with leaving them in the array is if one of them fails, it puts your data at risk, even if they are empty. Personally I'd dev/zero them, and do a new config without them. If your server stays up for months at a time between reboots, they can stay spun down in UD, ready to be put into use at a moments notice (hot spare, sort of)

Try setting the array NOT to autostart. If it works after a hard boot with a manual array start, it's probably a network timing issue.

Starting a parity operation spins up all drives. Spin up events are far and away the highest current draw, but only for a few moments.

Random(ish) errors after adding a drive are typically caused by power issues, either poor connections or lack of capacity to service the extra load. Parity checks are a point of maximum power use, especially when first initiated and multiple drives are spun up. A high resistance connection caused by a splitter can also be an issue, as it causes a voltage sag under load.

Unfortunately Marvell has a bad reputation with linux compatibility. They work for some people, but other systems randomly drop drives.

Depending on the USB implementation, network may actually be faster. Give it a try, but if you have a healthy 1000Mb network, your overall time to transfer will probably be either the same or better there, and it's going to be less hassle.

Different versions wouldn't "matter", but could effect which files you wanted to copy from one USB to the other. Having the same version means just the config folder is all that needs to move. This, partially. Definitely wait to assign parity, since all your data is going to be a copy anyway. If a drive in the new server pukes during transfer, just replace it and move on, no data lost. Pools, on the other hand, I would create initially, as you will usually want your docker containers and system files to go there. I would NOT, however, set any of your shares to use the pools as the initial place for the transferred data, set those shares to cache:no, or set the array as the primary destination with no secondary if you are using 6.12.X when you get around to doing the transfer. Initial data loading from the old array drives should bypass any pools and go directly to the new array, then build parity after all the data is safely across.

Can't think of anything major. Just remember to delete the trial key from the new config when you put it on the old key. Are you planning on running the same version (6.11.5) of Unraid on both servers while you do the data transfer?

Is your monthly check correcting or non-correcting? If it's correcting, run a non-correcting check to be sure everything got back in sync. If it's non-correcting, run a correcting check followed by a non-correcting to make sure it's done. All this presupposes all your current drives are perfectly healthy. If you don't know how to be sure of what I'm saying, attach diagnostics to your next post in this thread.

Yes, I was saying you could avoid the license transfer by continuing to use the old USB stick. If you put the old license file on a new stick it will prompt you to transfer the license, blacklisting the old USB GUID. You can do that automated transfer once a year, if you do it sooner you have to contact support and tell them your situation. Why not continue to use the old stick? In my experience it's hard to find a good quality USB stick, I'd prefer to keep using a known good one than take a gamble on a new one until forced to by failure. If you keep a current backup it's a matter of minutes to do a transfer to a new stick. I'm not sure what happens if you try to move an existing license to a stick that has been issued a valid trial. Presumably you could do that, but the automated system might not work, forcing you to contact support to get it moved. @SpencerJ?