Re: What is Unraid and how to build an Unraid media server
Posted: Thu Jan 20, 2022 5:26 pm
Hi Paul,
Thanks, the above was more an update as I was moving on with the process, just sharing progress. Yes there were many things already discussed, so I didn't spend too much time on these. Overall, there is no real issue.
Thanks for the info re tuning and check, I'll ask in the forums if things don't improve with a cache. It might be that because I had some system files in the array itself, it was trying to read files at two different places on the same disk. That's another reason why I wanted to moved system files and VMs to a cache (see below).
I have no way to know if the server was on sleep or had shut down, because when the issue happened I didn't realise it could be the S3 sleep kicking in and I simply turned it back on. However, I remember that the second time I was surprised by how quick it became accessible again, so I suspect it was simply on sleep. Since I disabled the auto sleep, I haven't had the issue. The pre-check was going fine, I just stopped it after the pre-read completed because I wanted to setup the cache and move the VM.
I found a better way to move a VM, as I also wanted to move all the system files that had been installed in the arrray and that kept some of the disks spinning (plus could cause some stutter). Here is how you do it:
1) Stop all the dockers and VMs
2) Disable the docker and disable the VMs in the settings. You shouldn't have a VM or a Docker tab in the GUI.
3) Go to shares and select "prefer" for cache for the Domains share (where all the VMs are located) as well as any other share you want to move to the cache. I selected the Appdata, ISO and the System share, plus my Multimedia share where I store the MyMovies metadata (for Dune).
4) Optional, but reset the stats that way you'll see more easily what happens in real-time during the next step (you'll see which disk is being read and the cache being written).
5) Mover should start automatically, but if it doesn't simply click on "move" in the "Array operations" of the Main tab in the GUI. When mover is working, the option is greyed out so it's easy to know if you need to help it manually or not. This should start moving all the files from the array to the cache, and you can see it in the GUI.
6) When the operation is over (no more read/writes, assuming no other user/process is accessing the array, and the "move" option isn't greyed out anymore) you can re-enable the VMs and Docker in the settings and relaunch your dockers/VMs. No paths to change manually, it's all automatic.
When that finishes, I'm going to enable the two parity disks to secure this array on this "production" server (they were disabled to speed up the data transfer process), then I'll move to the next server (to pre-test the 24-port board before I get the case next month).
By the way, re a question asked by Jamie, I realised that just as there is an "Automount" switch for the VMs, there is also an auto start setting for the array itself. You have to stop it, and it's in the settings (the first one I think). When enabled, the array auto-starts if there is no integrity issue detected with the array (such as a disk not detected, etc). As soon as everything is stable, I'll enable that option, because I find it convenient to have the array start and the VM to automount right away.
I'll do more tests with sleep, pre-clear etc on the second server as I really need this one to be operational and protected. The second one will have no data to start with, it will only be a test array.
Thanks, the above was more an update as I was moving on with the process, just sharing progress. Yes there were many things already discussed, so I didn't spend too much time on these. Overall, there is no real issue.
Thanks for the info re tuning and check, I'll ask in the forums if things don't improve with a cache. It might be that because I had some system files in the array itself, it was trying to read files at two different places on the same disk. That's another reason why I wanted to moved system files and VMs to a cache (see below).
I have no way to know if the server was on sleep or had shut down, because when the issue happened I didn't realise it could be the S3 sleep kicking in and I simply turned it back on. However, I remember that the second time I was surprised by how quick it became accessible again, so I suspect it was simply on sleep. Since I disabled the auto sleep, I haven't had the issue. The pre-check was going fine, I just stopped it after the pre-read completed because I wanted to setup the cache and move the VM.
I found a better way to move a VM, as I also wanted to move all the system files that had been installed in the arrray and that kept some of the disks spinning (plus could cause some stutter). Here is how you do it:
1) Stop all the dockers and VMs
2) Disable the docker and disable the VMs in the settings. You shouldn't have a VM or a Docker tab in the GUI.
3) Go to shares and select "prefer" for cache for the Domains share (where all the VMs are located) as well as any other share you want to move to the cache. I selected the Appdata, ISO and the System share, plus my Multimedia share where I store the MyMovies metadata (for Dune).
4) Optional, but reset the stats that way you'll see more easily what happens in real-time during the next step (you'll see which disk is being read and the cache being written).
5) Mover should start automatically, but if it doesn't simply click on "move" in the "Array operations" of the Main tab in the GUI. When mover is working, the option is greyed out so it's easy to know if you need to help it manually or not. This should start moving all the files from the array to the cache, and you can see it in the GUI.
6) When the operation is over (no more read/writes, assuming no other user/process is accessing the array, and the "move" option isn't greyed out anymore) you can re-enable the VMs and Docker in the settings and relaunch your dockers/VMs. No paths to change manually, it's all automatic.
When that finishes, I'm going to enable the two parity disks to secure this array on this "production" server (they were disabled to speed up the data transfer process), then I'll move to the next server (to pre-test the 24-port board before I get the case next month).
By the way, re a question asked by Jamie, I realised that just as there is an "Automount" switch for the VMs, there is also an auto start setting for the array itself. You have to stop it, and it's in the settings (the first one I think). When enabled, the array auto-starts if there is no integrity issue detected with the array (such as a disk not detected, etc). As soon as everything is stable, I'll enable that option, because I find it convenient to have the array start and the VM to automount right away.
I'll do more tests with sleep, pre-clear etc on the second server as I really need this one to be operational and protected. The second one will have no data to start with, it will only be a test array.