Symple

Looks like you were right on the money with that suggestion 👏 Temporarily disabling the Cache Dirs plugin just about eliminated the spikes. I will look into tweaking it to avoid such spikes going forward. Thank you so much!

I'm experiencing some strange periodic CPU spikes every 13-15 seconds and I'm struggling to figure out what is causing it. Using top/htop doesn't reveal any processes using any significant amount of CPU (or perhaps I'm just not clever enough to read it). With all dockers and VMs shut down, spikes are still happening. In order to stop the spikes I need to fully stop the array, so I assume that it is caused by one of the tools or plugins performing some action on a schedule. Spinning up the array reintroduces the spikes. Any tips on diagnosing the culprit are very welcome. thevault-diagnostics-20240116-2130.zip

I updated the path to the vdisk using the GUI but I did not change the format as that is not available through the GUI once the VM has been created. Nevertheless, that was EXACTLY the problem! Somehow the format had changed to 'raw'. Changing it back to 'qcow2' in the xml fixed everything! 😄 Thank you to all who participated! 👍

I did to begin with, in which case it would start the OS installation wizard. When the ISO is not mounted I get a "No bootable device" error in the VM when starting it (see below for complete message).

Dang....I was hoping that I had made a mistake somewhere - then at least I would have had an explanation as to why it isn't working. I don't recall having made any changes to the configuration other than what can be done in the GUI. I had some problems creating the VM working initially and I had to use the SeaBIOS in order to get the Windows installation to run, but other than that it ought to be "just another VM". I did grab a backup of the xml but I forget whether that was before or after I changed the path - I will have to take a look to confirm. The vdisk should be in perfect order although I haven't been able to figure out how to mount it in order to inspect it (unfortunately I'm not Linux savvy and it seems to be rather difficult to do on Windows). The new drive is a Samsung 850 EVO SSD which should be in perfect working order. Also, the copy process finished well in advance of me spinning up the VM again, so that also shouldn't be the issue. I also copied the vdisk several times while attempting to fix it but this seemingly had no effect.

Hi experts, I've attempted to move a Windows Server 2019 VM from my cache drive to an unassigned drive in order to separate things a little bit. The problem is that when I go to spin up the VM again it boots straight into the Server 2019 installation wizard instead of simply booting into Windows. I assume that I screwed up royally somewhere along the way, but I could really use some help with figuring out where as well as what the correct procedure would be. In order to move the VM I did the following: - shut down the VM - copied folder containing the vdisk img from "/mnt/user/domains/Server 2019" to "/mnt/disks/vdisks/Server 2019" (I named the partition on the unassigned device "vdisks") - edited the configuration of the VM and changed the "Primary vDisk Location" setting to "/mnt/disks/vdisks/Server 2019/vdisk1.img" - spun up VM As already mentioned this resulted in the installation wizard starting up. I can only assume that somehow the information that there is already an OS installed on the VM is somehow lost, although I cannot quite figure out why that would happen. Any pointers on how to do this correctly would be hugely appreciated! 🙂 UNRAID v6.7.2

I have to admit that in 20+ years of working with computers I have never identified a bad RAM stick by using MemTest. However, taking your advice I ran it and lo and behold, there were consistent errors in the same test on every pass. So I removed one stick, re-tested, and the error was gone. Put it back in as 2*single channel - no errors. Put it back in its original location as dual channel - still no errors. Apparently, a re-seating of that particular stick was all it took. Have since copied ~4TB in a single session to the drive that was causing trouble without any problems what so ever, so at least for now I believe the error to be fixed. Oh, and also updated the BIOS while I was at it. This was prior to running MemTest though. Thanks a lot for your assistance, @Squid - much appreciated 🙂 Best regards

Hi all, I am fairly new to Unraid (3 days remaining on my trial installation so still learning my way around). I have set up what I think is a pretty decent server with good hardware and storage (i5 9600k, 32GB RAM, 40TB storage so far). During the past couple of weeks I have been moving files and drives over from my old NAS and have managed to copy about 10TB over the network without any problems. However, suddenly I have started experiencing some odd problems where a file copy from a Windows 2012R2 will suddenly stop and complain that the file being transferred is locked. This can happen after transferring 300GB without issue (most recent example). Looking at the directory through the webUI I can see that the file has been created but I can't tell if the data was actually transferred or not. However, trying to access the folder using Explorer will fail and time out, probably due to a lock of some kind. Further attempts seem to mess up Explorer quite badly. Also, the file systems on the Unraid server seem to get messed up and the 1st time it happened I was forced to do an unclean shutdown because the array got stuck in "Sync file systems" while stopping. I am really puzzled as to why this has started happening. It began after adding the 2 latest drives (am now up to 4 drives + 1 parity) where one of them is reporting 17 "UDMA CRC errors". Those errors should be harmless from what I can gather, and besides I am writing to the other drive so in any case this should have no effect. I have added a diagnostics file, hoping that this will show something useful to someone who actually knows what to look for. Any help on this issue would be greatly appreciated. Best regards, Symple thevault-diagnostics-20190605-2205.zip