1812

You did not follow the steps in the first post for "VM problems - pass-through" your logs show 0000:04:00.1: DMAR: Device is ineligible for IOMMU domain attach due to platform RMRR requirement. Contact your platform vendor. 0000:04:00.1: DMAR: Device is ineligible for IOMMU domain attach due to platform RMRR requirement. Contact your platform vendor. your fix is:

For real. I've gotten a few kernel panics/crashes on my m1 Mac.... early adopter price....

any reason why virtmanager won't connect to my server? I keep getting port 22 connection refused.... yes I have a pw on the server also, can anyone else confirm that removing a video card and going back to vnc makes the vm hang on "Guest has not initialized the display (yet).

The current method of RMRR patching is now deprecated. For the new method of RMRR patching please see here:

Welcome to the new method of working around HP's RMRR problem on unRaid. For the previous/deprecated method which was no longer working, see: https://forums.unraid.net/topic/72681-unraid-hp-proliant-edition-rmrr-error-patching/ First the disclaimer: This has been tested with no negative attributes observed. Many have been running an RMRR patched version since mid 2018 when we first started producing them, and so far have had no reported issues. As it only omits RMRR checks, it should not affect any other core function of the OS. But a

Simply amazing stuff. You are a credit to the community.

It keeps pulling Catalina instead of Big Sur for me even though I selected Big Sur twice with method 1....macOS Product: 061-86291 Switched to method 2 says it's trying for Product: 001-86606... I guess I'll leave it overnight and see what greets me in the am. update: method 2 downloaded Big Sur

People testing network throughput ¯\_(ツ)_/¯

I don't think you understand, I am not contradicting your statement regarding Ram vs HDD speeds. I am saying that it is not as relevant to the topic as you attest. The topic is not Ram vs HDD speeds in unRaid via SMB. It is about working around the bottleneck of user shares to achieve greater SMB performance. As a side note, Disk Shares don't work for pools as of 6.9.0 rc 2, although the same effect of bypassing the user shares is achieved.

As I wrote above, I did use a large file for file transfer testing. This did exceed my dirty ram percentage but I did not include that bit of information. And retesting using the ram clearing command shows the same resulting speeds as before, which is expected because I exceed the dirty ram percentage. But I will disagree with you on using Black Magic. Those results demonstrate and reinforce the point of this thread, that SMB transfers are bottlenecked using regular user shares on Unraid on macOS, and that high rate SMB transfers are possible using this workaround. Your implied poi

Firstly, credit to @testdasi for sharing this info in a similar thread by @mgutt for windows. (edited to fix attribution) I looked around the board a bit to try and figure out why mac's get such horrible smb performance on unRaid, the os we all know and love. I wanted to setup a faster network scratch drive, but seemed to hit a wall at 400-600ish MB/s. Setup: M1 MacBook Pro running Big Sur 11.1, connected to an OWC thunderbolt pro dock with 10GBE <--Cat6a--> MikroTik CRS305-1G-4S+IN <--DAC--> ML350p Gen 8 with a cheap mellanox connectx-2, running unRai

hp ml350p kernel panic after boot. booting into safe mode with no plugins allows boot. Not sure which was causing the issue as I manually nuked them all and only reinstalled a few that I know I use regularly. I know this isn't that helpful, but reporting nonetheless.

testing in progress..... ... ..

Hello not yet. I'm going on holiday soon but should be able to start on it sometime around the 27th or so