Im running a supermicro superserver. 

Supermicro X10DRi-T4+

2x Intel® Xeon® CPU E5-2697 v4 @ 2.30GHz - just upgraded

Memory: 256 GiB DDR4 Multi-bit ECC - just upgraded

intel arc 380 video card

nvidia p2000 card I pass to the vm

 

I only every used the server for all my media/data/backups. Its job has just been to do plex and storage and has been great at it.

 

I recently started doing some cad work and decided running a Windows 10 vm was the best solution. I run linux on all my pc's. The problem is even with the new upgrades - its slow. I have given the windows basically every core except 0 and most of the ram I have along with the p2000 gpu.

 

I started thinking that maybe the reason for the cpu's to hit this frequent 100% usage was that the vdisk was stored on a standard hdd. I decided I would get a pcie 3 expansion card and run a m.2 on it.

 

https://www.amazon.com/dp/B07JKH5VTL?ref=fed_asin_title

 

I shut unraid down for the first time in awhile and installed the card with m.2 and rebooted the server. The server detected the card and m.2 without a hitch but immediately started giving me drive errors on my array. one of my parity drives and disk 1 both were disabled.

 

I removed the pcie card and I am now rebuilding the array but is there any way the hooking up of the card somehow messed up the array?

tower-diagnostics-20250307-1745.zip

38 minutes ago, blackbox said:

is there any way the hooking up of the card somehow messed up the array?

Disturbing disk connections when the case is open is probably the most common reason users get disabled disks.

7 minutes ago, trurl said:

Disturbing disk connections when the case is open is probably the most common reason users get disabled disks.

I could see that being a good reason but I don't think that's the case here. There really is no way for me to bump the drives or the connections on this setup.

Looks like rebuild is going OK now though. If you didn't fix any connections maybe they weren't the problem.

 

Are you only using the m key slot and not the b key slot? You have to have a SATA cable connection to use the b key slot.

Just now, trurl said:

Looks like rebuild is going OK now though. If you didn't fix any connections maybe they weren't the problem.

 

Are you only using the m key slot and not the b key slot? You have to have a SATA cable connection to use the b key slot.

Correct. I was just using the m.2 slot that doesn't require the sata cable.  One goes with the pcie slot directly and the other requires the cable for this card.

After rebuild you might set the array to not auto start (Settings - Disk Settings) before trying again. That way nothing will get disabled and you can check to make sure all disks are present and maybe post diagnostics.

10 minutes ago, trurl said:

After rebuild you might set the array to not auto start (Settings - Disk Settings) before trying again. That way nothing will get disabled and you can check to make sure all disks are present and maybe post diagnostics.

I will do that.

I was just going to add the m.2 to the array but limit it to its own vm share and try to copy my vdisk over to it or start a new vm on that share if the copy didnt work. Am I on the correct thinking for setting this up or is there a better way to give the vm the m.2 speed?

51 minutes ago, blackbox said:

was just going to add the m.2 to the array but limit it to its own vm share and try to copy my vdisk over to it or start a new vm on that share if the copy didnt work. Am I on the correct thinking for setting this up or is there a better way to give the vm the m.2 speed

This will result in writes being limited by the speed at which parity can be updated and thus limit VM performance.  To maximise performance it needs to be in a pool.

And SSDs in the parity array cannot be trimmed

2 minutes ago, itimpi said:

To maximise performance it needs to be in a pool.

 

27 minutes ago, itimpi said:

This will result in writes being limited by the speed at which parity can be updated and thus limit VM performance.  To maximise performance it needs to be in a pool.

I'm glad I asked. The whole point of this is just to get the most vm performance my hardware will allow.

 

25 minutes ago, trurl said:

And SSDs in the parity array cannot be trimmed

 

Thanks again for the help

On 3/7/2025 at 6:46 PM, trurl said:

After rebuild you might set the array to not auto start (Settings - Disk Settings) before trying again. That way nothing will get disabled and you can check to make sure all disks are present and maybe post diagnostics.

So I did the rebuild and from what I can tell everything is working. no more disabled drives. I have to be honest, that kind of freaked me out but that's why I choose Unraid. I actually purchased two replacement drives just to keep as backups in case something happens again.

 

I post the diag file if someone wouldn't mind seeing if I have any issues that I don't know about.

tower-diagnostics-20250308-2311.zip

Edited March 9, 20251 yr by blackbox

Your system share has files on the array. Nothing can move or delete open files, so you have to disable Docker and VM Manager to work with that share.

 

I didn't check SMART reports, do any have SMART ( 👎 ) warnings on the DASHBOARD page?

On 3/9/2025 at 9:49 AM, trurl said:

Your system share has files on the array. Nothing can move or delete open files, so you have to disable Docker and VM Manager to work with that share.

 

I didn't check SMART reports, do any have SMART ( 👎 ) warnings on the DASHBOARD page?

After the system did its ?rebuild? everything seemed to be fine again. no issues/smart warnings or anything with the hdd's. I turned off the auto start for the array for now on. I also shut down the vm and docker and moved around alot of my files. Domains, isos, got moved and I removed everything from the array that was not needed. I should have it setup where only a few things touch the array and everything else is on/limited to the ssd's.

post new diagnostics