JonathanM

try changing raw to qcow2

You are checking the emulated drive. Instead of polluting the plugin support thread, please start a new thread in the general area, include your diagnostics and a link back to your post here so anyone wishing to help can see what's happened so far.

Do not post copyrighted material in this forum.

Do a filesystem check using the GUI, on the main tab click on the Disk #.

How do you know it's dead? The majority of the time Unraid fails a drive is because of a cabling or power issue, dead drives are relatively rare. When a write fails, for whatever reason, Unraid disables access and emulates the data using all the rest of the drives. See if you can get a SMART report on the "dead" drive, and see if it will mount in the Unassigned Devices plugin.

Try deleting the /mnt/cache folder, disable the docker service, not just stop the containers, and restart.

The folder referenced in the title of your post, /mnt/cache

What is the content of the folder?

If you disable the docker service and restart does it come back?

Keep in mind that running Unraid as a VM is not supported, if you have issues it's on you to solve them. It's not forbidden, plenty of people do it, but if you have a problem you will be asked to recreate the problem running Unraid bare metal before it will be considered an actual issue that the developers need to look at. There is a section of this forum dedicated to users helping each other with virtualizing Unraid.

Are you using bridge mode?

As much as you can give it. The host RAM is used to cache disk access, so the more RAM it has, the better it will perform. https://www.linuxatemyram.com/

Do you have any ports exposed to the internet? Is there a proper firewall in place between your public IP and Unraid?

For best performance start at the lowest amount of RAM that will allow the VM to boot successfully, and add RAM in small chunks until the performance doesn't increase any more, then back it down to the last amount before it topped out. The host needs the RAM to emulate all the I/O and motherboard functions, so the more you can give to the host without slowing down the guest will give the best overall performance. RAM allocated to the guest is totally gone from the hosts viewpoint, so the more you can give to the host the faster virtual hardware you will be running on. You wouldn't intentionally cripple a bare metal PC by giving it the slowest motherboard you could find and maxing out the RAM to compensate.

It is an issue, usage doesn't matter, any RAM allocated is denied to the host completely. Try setting the windows to 8GB and the linux to 4GB and see how they perform.

You can do it simultaneously but it will be excruciatingly slow. Why not just remove the disks all at once and rebuild parity one time with the final complement of disks?

Maybe when you finalize your directions to yourself, use Slot instead of Disk when referring to the logical positions, and fill out the last 4 of the drive serial numbers so you keep it straight in your head and can cross check things. For example, select slot 1 and assign disk A54E or something like that. Also, I suggest actually committing a document to print after verifying all your steps, then physically cross things off the list as you do them.

Why? If you are retiring the disk, why not just leave slot 9 blank, and NOT check "parity is already valid" so it calculates parity from the disks you wish to use? The only other gotcha I see is if files are added or modified while the copy process is running you may not have the full up to date copy. You can either stop all the things that could write to the disk, or use rsync to verify the copy and list differences until the verify is perfect. It's not a bad idea to verify the copy anyway, but not the end of the world since you are keeping the old disk(s) intact as you go.

Download the latest and overwrite everything EXCEPT the config folder.

Attach diagnostics to your next post. syslog is included in diagnostics.

Yes, you can't use parity to rebuild to a smaller disk. You will have to set a new config in tools, then recalculate parity after switching the disks.

So you have the license *.key file that was issued for the broken stick? All you need to do is copy that file into the config folder of the new stick and delete the trial.key, then the registration wizard will step you through blacklisting the old key and getting a new one to match the current stick.

It's not measuring RAM, it's showing how much of the docker image file is in use. All three of the non-RAM items are percentage of allocated storage in use.

Familiarity, greater control, etc. Mostly just personal preference and fear of learning new stuff.