JonathanM

Try nomachine instead of RDP.

I can't help with details, but broad strokes, yeah, you could theoretically check for a VM to be running with virsh commands and if it's shut down you could then script unraid to shutdown. The tricky bit is figuring out how you want to handle troubleshooting scenarios where you DON'T want unraid to shutdown if the VM isn't running for some other reason.

It probably won't work as presented. There is a good possibility it could be forced to work properly, but the amount of manual manipulations is unknown until you try. If you are more familiar with a windows environment the closest analogy I can offer is trying to get a windows 95 program to work on windows 10. Small chance it works out of the box, likely can be forced by manually copying things where they should go, still possible it will never work properly. The linux environment is a little better, especially if they offer low level files that could be compiled for slackware, but not all companies do that. Many just put together a precompiled binary package that they know works with a specific version. If you want to start an internet argument, slack vs ubuntu / debian is a pretty good firestarter. They each have strengths and weaknesses, so it's easy to argue passionately for either one.

Compare is only as important as you need it to be. If everything worked properly, it will show zero differences. It's there to catch errors in the copy process. Totally your call, especially since you will still have the data on the removed drives if something shows up as corrupt or missing later. If everything works properly with the copy command the verify isn't needed, but I like to give the safest advice possible. Since your first copy went well, you likely will be ok for the rest. When you rebuild parity you can put the data drives wherever you please. Just be sure to never put a data drive in a parity slot, as that will irretrievably remove any data that was on the drive. If you select the retain parity assignments on the new config screen that will reduce your chances of messing up.

Linux Ubuntu, Red Hat, CentOS From that page, no slackware support yet, they say other OS in future, but don't say which ones. Unraid is built on slackware.

Temporarily switch back to VNC as your video adapter so you can access the VM OS. Install remote access software such as nomachine, or enable RDP. Make sure you can use that access method while VNC through Unraid is still available to troubleshoot. Once you successfully can access it using a different method, then switch back to your GPU.

Yes, with some additional info. The reason I had you specifically rearrange the drives was to put the data that had been on drive 3, back in the drive 3 slot. What you are proposing will work fine, and you can remove all the drives at once with a single new config and parity rebuild operation. However, once you are done, the data will be on different data slot numbers. If you haven't customized any share allocation settings, that will be fine. However, if you had defined any shares to specifically use drive slots, those will need to be changed to the new drive slot numbers. Unraid by default doesn't care which data goes on which disk, but you can force it to only use certain disks, which is why I told you to put the destination disk back in slot 3. That way if you HAD customized things, they wouldn't break. BTW, if you poke around you will find other methods of getting data from drive to drive, most involve moving instead of copying. I advocate copying for several reasons. It's faster. You can verify the copy before you make things permanent. You still have the data as a backup on the removed disk. The biggest reason to move instead of copying is verifying all the data is on the destination if you insist on actively using the array while the file operations are taking place. As long as you do not add or modify data while doing the copy, you won't have any issues. You can read and play files from the array during the copy with no problems. Adding or modifying files in a user share while the copy is taking place could possibly result in the changes not transferring to the new drive. If you are ok with not adding or modifying files on the server while you get this done, then you are good to go.

Good! Hopefully it's not just similar, but identical. The commands you ran first copied, then compared what was copied, and no differences were noted, so you should be fine there. This next bit assumes you want disk 13 to be in the 3 slot, and 14 to be in the 13 slot. If you DON'T want the current disk14 in the array right now, make sure it is empty and just don't assign it in this next step. Now, with a printed hard copy of the serial numbers and slots they are currently assigned to in hand, stop the array, go to tools, new config, preserve current assignments all. Apply that, then on the Main GUI page, set disk 14 to none, set disk13 to the disk that was in 14, and set disk3 to the disk that was in 13. Do a last verification that the disks are in their correct slots, all the data disks will have their current contents retained, both parity disks will be fully erased and rebuilt in this next step. Start the array, DO NOT CHECK THE BOX STATING PARITY IS VALID. It is not, and you must rebuild parity from scratch at this point. If you are unclear on any step or why it's needed, stop and ask, don't blindly follow.

That part looks good. If you click on the "view" folder on the far right of the main GUI screen for disk 3 and disk 13 and compare, do they look identical? Does disk 13 now show 1.62 TB used instead of 69.7 GB?

Is there a checkbox to specify that parity is already valid?

How do you know? A mistake here will be fatal to your data.

not sure what you meant from the way you worded that, but there is only one step there, parity is realtime, so as soon as the mover transfers a file to the array, parity is updated simultaneously , there is no "and then"

Do you have the drive serial numbers in exactly the same slots as they were before?

For safety's sake, this is a multi step process. At the local console (attached keyboard and monitor) or using the screen application over SSH, issue these commands. rsync -arv /mnt/disk3/ /mnt/disk13 That command copies everything on the disk3 data slot to disk13. After that has completed, run rsync -narcv /mnt/disk3/ /mnt/disk13 That command compares all the files on disk3 to the files on disk13. It should not show any files, if it does it means that something didn't compare identically. After you have completed those two commands with the second command showing no results, then you can move on to rearranging the drives and rebuilding parity. Be VERY precise when entering the commands, the placement of the slashes is very important.

Shares, user shares, size, compute?

Parity in Unraid doesn't have ANY overhead, it doesn't modify the data drives in any way. Free space is solely determined by the data drive slots.

Not what I asked, but I see why you thought that. Many (most?) motherboards with more than 4 or 6 ports use additional chips onboard to drive the extra ports. They may or may not be a different color, or be silkscreen labeled with a different number scheme.

Are all 8 ports driven by the same controller? I'd pick up a cheap asmedia 2 port pcie1x controller and see if that changes things. Should be able to find one for under $20USD.

Is there an option for VNC Remote when you click on the VM icon on the dashboard?

When you start the array without adding the drive, and leave it unassigned, does it mount and show the contents?

You should still be able to click on the VM icon on the dashboard and select the VNC Remote option.

Check network, those speeds sound suspiciously like a 100Mb connection somewhere in the chain.

If you need individual private support, I suggest you contact limetech directly https://unraid.net/contact All volunteer free support in this forum is public. I'm not a limetech employee.

I don't know if it's "normal" but it is typical. Mine is exactly that same size.

Is data slot 3 mounted and showing the correct content? You really need to attach your diagnostics zip file to your next post.