JonathanM

Sounds perfectly reasonable for a core temp.

It's a good idea to do a non-correcting parity check after doing a disk rebuild. Rebuilds don't "check their work" by reading what was written to the rebuilt drive, it's assumed if a write completes without error, it wrote correctly.

Depends. There are other things you can tweak with regards to memory, cache pressure and such, and honestly Unraid is tuned for best performance with smaller amounts of RAM and may not make the best use of more than 64GB of RAM. I don't have the luxury of owning any systems with more than 32GB right now, so I must leave hands on research as an exercise for the reader.

It will kill performance if run too often, as caching data is what speeds many things along. As a clean up tool run when performance isn't a priority, or before starting a task, it should be fine. It does prove to some extent that you are over committing the memory you have for optimum performance, so more RAM would help if you really need to reserve that much RAM for VM use. I would try reducing the VM RAM allocations and see if it hurts or helps the VM performance. RAM caching by the host is one of the things that can really speed up a VM, and if you deny the host that RAM it can hurt the VM speed.

After a minute of googling (as in, no real research) I found this which may or may not do something in Unraid, haven't tried it, so use at your own risk, it was billed as a "linux" solution. This apparently a. clears speculative data that was cached b. consolidates the in use memory. If you are game to try this, execute at a point where the VM would fail to launch. To repeat, I HAVE NO CLUE IF THIS WILL DO BAD THINGS TO UNRAID.

Perhaps out of unfragmented memory. Some operations require contiguous blocks, and over time more and more addresses can be tied up and unable to be reallocated, even if the total amount free is plenty.

If the stock scheduling doesn't give you the flexibility you need, maybe look into the tuning plugin?

Expander is not quite the right terminology.

Don't do that. You need to leave resources available for the host (Unraid) to emulate the motherboard and other I/O. At the very least leave CPU 0 available for Unraid. Since you only have 4 threads, I'd only use CPU2 and CPU3 for the VM, maybe try with only the last thread for the VM and leave the other three for the host. That may also be too much, depending on how much RAM the system has. If the physical box has 32GB, 8 for the VM should be fine. If it has 16 or less, reduce the VM to 4096. The more resources you tie to the VM, the slower the host is going to run, which in turn slows the VM way down. Give the VM the absolute minimum and add a little at a time until performance doesn't increase.

Just the reverse array -> cache, or cache only The advantage of having the cache primary and array be a secondary with a move to cache setting is that if you ever accidentally fill the cache and the minimum free space is set correctly the excess data will go to the array, then when the cache has room, the mover will put the data back on the cache. Cache only will give an out of space error when it gets below the minimum free space set.

Yes, the parity array is great for mass storage, very bad for random I/O, especially random writes. SSD or NVME is a must for vdisks.

Yep, that would be why the VM is dog slow. vdisks should be on fast pools, not parity protected array disks.

All support questions for specific containers should be posted in their thread, not spread out across the forum. That way people can easily see what others have asked, and the answers they received. Many problems have already been asked and answered.

At any point did you format a drive? If so, you erased all the existing files.

1. What drive is the VM using for vdisk or passthrough? 2. Try changing the RAM to 8GB