jonp

any attached storage devices count towards the licensed limit, regardless of whether or not they are assigned to the array, cache, parity, or left unassigned. Sent from my Pixel 3 XL using Tapatalk

What about a bios update? Sent from my Pixel 3 XL using Tapatalk

The answer definitely lies somewhere in the bios. Got a link to the manual? Sent from my Pixel 3 XL using Tapatalk

Yours or his? This is what I set as his avatar just before banning the account:

Hey guys, in case you're wondering, the troll has been vanquished and all posts relating to his content have been bilged. In other words:

Please post a screenshot of your Main tab. Do you not have a cache device?

Ok, I see lots of CSRF token errors on your logs which indicates a browser left open to Unraid after a reboot. Let's try this: 1) Close out of all browser sessions connected to the Unraid webGui. 2) Restart your server. 3) Attempt to adjust the CPU pinning again. 4) Verify it didn't take. 5) Collect diagnostics and repost them here. I want to see the logs right after you attempt to change the pinning and it fails. Want to see what it says. Also can you confirm what type of browser you're using and try using a different one just to make sure this isn't a weird browser issue.

I think you can add that command to the go file located under the config directory of the flash device. That should make that happen each time at boot.

I would definitely create a post in the feature request forum. This isn't really something we would directly develop ourselves, but if we could find a way to "script" around this, I could see us devoting some time to doing that. As of right now, it's not a development priority because there just aren't enough users out there complaining about it. There are plenty of things we want to see improved and this is one of them, but we have to tackle things in the order of what's going to bring the most value to the most people first, and this definitely slides down the task list as a result.

Couldn't agree more with @bonienl here. Using consistent and reliable hardware is definitely key to a well functioning system. Cheapening out on parts is obviously a viable way to save money, but it comes with more headache as you update.

I deleted that part of my post because it was adversarial and we try our hardest to keep these forums exactly the opposite of that. So did we then confirm this was a configuration problem, not a software bug? Update: Seriously asking and curious how your MTU setting would work previously but not now.

Based on these last two replies, I think the issue that @BennTech is having is clearly specific to his setup.

@BennTech I get that you're frustrated because you're dealing with troubleshooting an issue, but let's get a few things straight here. Is it possible that your ReadyNAS is outdated and maybe can't support the updates to the SMB protocol in both the software/kernel that are in the latest build's of Unraid? QUESTION TO ANYONE: Does anyone here use Unassigned Devices + Remote Shares with two servers and its working fine? How about anyone with 2 Unraid servers using the latest build? Bottom line: If you or others can reproduce this issue consistently when using remote shares to multiple platforms (not just your ReadyNAS), it may elevate the priority of the issue with us, as we know plenty of folks dependent on this plugin. So far, I only see you complaining which leads me to believe this is likely an issue specific to that ReadyNAS you're using. Maybe we update our OS/kernel/packages far more frequently than ReadyNAS? At this point, we need to see evidence that this affects more than just one user with one specific setup (ReadyNAS + Duplicati backups over SMB/NFS). Can you reproduce the issue just manually copying a large volume of data from a Windows PC to a share? What about over NFS from another Linux client? If you can show this issue has a wider impact to the community, I will look closer and try to replicate, but if you can only show the problem with your specific setup, you're just going to have to wait for future updates on both us and ReadyNAS to see if that resolves the issue in the future (as we update kernels/packages including SMB). Also, what about using ReadyNAS to map remote shares to Unraid instead of the other way around?

Qemu doesn't seem to like that PCIe splitter you're trying to use. Might need to submit a bug report to the qemu project given the segfault message in there.

Been working on it for almost a year now. I actually trimmed it up for the podcast but yeah, it's still long. My wife and daughter have threatened me with physical harm if I shave it, so probably going to stay looking like grizzly adams for a while! Sent from my Pixel 3 XL using Tapatalk

Believe it or not it was actually iced tea though actually I wish I would have had a beer considering the conversation!! Sent from my Pixel 3 XL using Tapatalk

Oh yes, these are definitely my kind of people!

We do not support SAS multipathing at this time and it is currently not an intended item to add to the short-term road map. Sent from my Pixel 3 XL using Tapatalk

If someone can confirm this, it would be a good reason to keep Q35, but I don't know if this is accurate. Not sure where you heard that, but it's not true. i440fx works perfectly fine when moving a VM from one set of electronics to another. Not sure where you got the impression otherwise. You mean like Hyper-V, VMWare, and VirtualBox? I've had no problems using i440fx with any of those in the past, albeit I haven't had to do that in a while. If you change the motherboard of your computer, Windows wants you to call MS to reactivate the license (if you're not signed in with a Microsoft account). This applies the same with virtual motherboards like i440fx and Q35. If you've associated your registered copy of Windows with your Microsoft account, you'll just need to resign in once you change the gear and all is good. Links to relevant articles you've read would help here, but to be fair, there is a lot of misinformation on the web about KVM and QEMU, especially when it relates to GPU pass through.

Hey everyone! Just thought I'd chime in with an update here on this PCIe Root Port Patch, the Q35 machine type, GPU pass through performance, and the future of those things within Unraid. I actually had an e-mail discussion with Alex Williamson on this subject. From Alex: So if you're using an i440fx VM, this patch will do nothing for you. Furthermore, i440fx VMs don't have the issue of GPUs not up-clocking under load. I've tested this on both an RTX 2080 Ti and an EVGA GTX 1080 Ti, both work properly under load and do not show any signs of performance bottlenecks. As such, the logical question I am asking myself is: why are people using Q35? I'd like to ask the community at large here to answer that question because while there are a few specific situations where Q35 is required, passing through a GPU to a Windows-based VM is not one of them. And for anyone in this thread reporting a performance increase after this Q35 patch, I would kindly ask you retest using an i440fx based VM and see if you get any different results. The only specific reason why someone would perhaps want Q35 is for Linux-based gaming VMs that have an AMD-based GPU passed through to them, but even that very niche use-case could be deprecated as I think the newer kernels have fixed i440fx for that case. I think the only use-case so far that makes sense is for Mac-based VMs, which is understandable, but other than that, who is using Q35 and why not i440fx? Feedback is critical here. We are seriously considering removing the option to select Q35 for Windows-based VMs from VM manager. If you can provide a use-case for why we shouldn't, please do!!

If you remove that custom edit, does editing in normal mode work again? Just curious so we can debug this.

Yeah, Johnny Black is literally giving you the exact reason why write speeds when transferring data from disk to disk INSIDE the array are slow. It's because for each write (either deleting from the one disk or writing to the other), it has to update the parity disk for BOTH transactions. That's why writing to disks in the array are fast when the source ISN'T on the array.

Did you originally edit your VM in XML edit mode? What setting(s) did you adjust using that edit mode?

Just Ryzen, but there are some games that don't perform well in a VM because of CPU exits that can occur. It seems pretty rare, but I think WoT is one of them. Try a few other more common games like Fortnite, Counterstrike, Dota, or any of the other big ones and see if you get the same performance dip. If so, there may be more to look at in your configuration. If not, it's a game specific issue.

What errors?