1812

Glad it’s all working now

trying this out, thanks for making it!

OK, so maybe try this: with no network nic in delete network.cfg again make a backup copy of network-rules.cfg, like on your desktop then modify the network-rules on the flash to the following (only modification is changing NAME="eth1" to "eth0" # PCI device 0x8086:0x1539 (igb) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="10:7b:44:92:78:83", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0" save reboot and report back My thought is that if it was initially booted with the nic card, then the onboard was somehow assigned as eth1 and for some reason is not being changed later when it's the only ethernet port available. And the forced change/rename in the network-rules causes it to make a bond with a now nonexistent eth0. and if that doesn't work, delete the network rules-cfg all together and reboot (again with no nic)

you should. also I spent some time with your logs: I can see where the onboard changes during boot: Jun 17 13:58:00 Obi-Wan kernel: igb 0000:05:00.0 eth1: renamed from eth0 I've never encountered this but just search for " eth1: renamed from eth0" reveals fixes and pinpoints the problem on the kernel, so not an unRaid problem. (ex: https://www.centos.org/forums/viewtopic.php?t=49338) additionally, loading the out of tree driver for the 10gbe may cause network issues that are undesirable, including interface assignment (though I doubt it, but it is worth mentioning.) Yes, numerous others are running the same out of tree driver, but most likely using the 10gbe card as primary, which would have meant this issue would have gone unnoticed. ixgbe: loading out-of-tree module taints kernel. but back to the issue at hand, I would recommend what I did before and delete the network.cfg file, power down, remove the ethernet nic, boot up, confirm all is good, power down, add card in, reboot, then see what happens. Normally the web gui can make interface assignment changes with no issue, but this may be a side case....

Have you tried deleting the network config, and then reboot with just onboard? If not, do that, make sure the array starts, then power down and add the other nic back in. It “should” add them after the onboard in eth numbering. I can take a look at diags in the am of someone else doesn’t beat me to a solution.

Ubuntu vm with team viewer on the server. Remote in on teamviewer, then use Ubuntu web browser to access server.

Check bios for network preference options ( prob none) and disable any network boot options if you have any failing that, assuming you’re on 6.7.0 (on my phone and couldn’t access diag zip] and with the understanding that the pci nic is for pass through, then bind it per the new method outlined in the release thread and see if that forces the onboard into etho

remote transcoding server

I'm not directly answering your question, but why that? seems very expensive. I am in the process of moving from an md1000 hooked up to a z420 to moving the disks into a converted fractal R5: Go from the hba in the server out to an 8088 to 8087 adapter (https://www.amazon.com/gp/product/B00PRXOQFA/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1) 2 cables then into another of the same adapter, then breakout cables from the adapter to the drives (gives me 8 sata cables for the 8 drives.) add in a small 400 watt power supply I have laying around and its done. If I want to add more drives in the future, I can use an sas expander and add a drive cage with fans.

it's been a while since I've passed an entire ssd to an osx vm. It would just depend on how macOS sees the drive. If it reads it w/out the quemu arg and other bits then you can check if trim is enabled or not (which I think for aftermarket drives you have to force enable anyways.) if its not recognized as an ssd, I don't know why it would not work, but again, I haven't tested it. I may have to do that just to see how it sees the disk.

I'm no expert, but yes, and it "takes out the trash" when you delete a file, vs not really deleting the file, requiring deletion next time the "drive" attempts to write to those blocks, causing degraded performance while the write function waits. And additionally, over time, the lack of trash collection always seems to slow my disk image files after about 4-6 months of use. Which makes sense because if macOS thinks its a rotational disk, the data remains after deletion but is just blind to the os, essentially filling up the image. and when the data actually hits the ssd, having to deal with all the existing occupied blocks causes excessive overhead on ssd operations to perform basic functions that involve writes. along with the discard=unmap in the xml, yes is should, , which releases the removed blocks back to the ssd, vs having a static mapped section that may be going unused in the vm. better wear-leveling, meaning it's not writing to the same section over and over and over and over, where the image resides, causing premature failure of those blocks/sectors. there may be others as well.

search function is awful. its much more useful to go to google and use that to search the site.

it's not permanent see here to "fix"

As I said, opinions.... not necessarily facts I considered it but parity checks and disk writes didn’t seem that much faster based on reported posts to justify spinning up extra disks or adding another layer of configuration for me. And pcie slots are a premium for me. a couple years ago when I started with unRaid, I use to have lots of enterprise equipment and a big rack. Now I find that I’m more interested in density, and seeing how much I can cram into smaller spaces, finding better way to use my smaller iso box rack.

We’re you looking for more kudos? Here’s a few more Side note: some folks have done hardware raid for parity before. Some kept it, some abandoned it. It’s not a popular route for various opinions. I think Johnny still does this.