bland328

Sorry...should've explained! I was lucky enough to have recently migrated the VM in question to a second, non-Unraid box to use as a template for another project, so I was able to simply go grab a copy of the OVMF_VARS.fd file from there. Had that not been possible, I suppose I would've grabbed a clean copy of that file from here or here, the downside being the loss of my customized NVRAM settings. I didn't notice if any cores were pegged with this happened, but I rather doubt it, because in my case there was no boot activity--I didn't get to the Tianocore logo, nor even to the point of generating any (virtual) video output for noVNC to latch onto.

I humbly nominate the moreutils collection for inclusion in NerdPack. I'm particularly interested in the sponge and pee commands, but there's a variety of good stuff in there. moreutils is a nice complement to coreutils, which I believe is already included in Unraid. Thanks for considering, @dmacias, and for your generous work on NerdPack!

For the record, I solved this...but I'm not sure what to make of it. And it almost surely has nothing to do with the OP's problem, but I'll leave the solution here anyway, in case it helps someone else: Apparently, the 'OVMF_VARS.fd' file (OVMF NVRAM backing for the VM) for that VM became corrupt. It is stored in an unassigned btrfs volume on an NVME drive, and the btrfs volume itself does not appear to be corrupt. I've no idea what happened there, but hopefully (and probably) it has nothing to do with Unraid 6.8.1.

+1 here, too.

I'm having a somewhat similar problem. My trusty macOS VM that I've been running 24/7 for years suddenly won't start. And by that I mean that the VM claims to have started (green 'play' button lights up in the Unraid GUI), but nothing ever happens--I don't get even as far as being able to VNC in (I get the "Guest has not initialized the display (yet)" message). In the log file for the VM, not much appears--when I try to start the VM, it spits out the long set of qemu args, then this standard stuff: 2020-01-15 01:06:05.240+0000: Domain id=4 is tainted: high-privileges 2020-01-15 01:06:05.240+0000: Domain id=4 is tainted: custom-argv 2020-01-15 01:06:05.240+0000: Domain id=4 is tainted: host-cpu char device redirected to /dev/pts/1 (label charserial0) and then...nothing. I know this may not actually have anything to do with 6.8.1, but in the name of research...is anyone else having VM woes under Unraid 6.8.1?

Thanks for the update, @ryoko227. If/when I get some time, I'll also put some work into this, and will post here. EDIT: For the record, I'm on an ASUS PRIME X370-PRO + AMD Ryzen 5 2600, with a 500GB Kingston NVME drive in the motherboard slot, formatted BTRFS, and unassigned. Turning off IOMMU in the BIOS does stop the flood of page faults, but I need to turn that back on soon 😅

Thanks for the info, @Gitchu. I've upgraded to Unraid 6.8.0 final, and now find that VMXNET3 (+Q35-3.1, which may or may not have anything to do with it) is working great with Catalina, as well. Though, to be fair, I haven't freshly logged into iCloud services (iMessage, App Store, iCloud Drive, etc.) recently; for anyone else reading this, I've run into problems in the past with VMXNET3 working fine with those services only after I've successfully logged in with a different (e1000 or passed-through) NIC. Fingers crossed that those days are now behind us, but I don't feel like logging out of what's now working just to test it. 😉

Just learned I'm also affected by this, and do need to keep IOMMU turned on. @ryoko227, did you have any luck with the patch?

For the record, I'm currently experimenting with running Catalina under qemu/kvm/libvirt on a non-Unraid Linux box (still an Unraid fan here...this is just a side project!), and I find that using when qemu-4.1.1_1, a virtual e1000-82545em NIC is working just great with br0: bridging. To be fair, this br0: bridge is one I configured, and I'm not currently quite savvy enough to know if that could be the difference...but I doubt it. So, I'm looking forward to Unraid 6.8.0, suspecting an updated qemu will fix everything for me, as it did for @Gitchu. Assuming it does, I'll stop using qemu's virtual e1000 NIC+e1000 kext, and return to using e1000-82545em.

Thanks for the update, @Gitchu! So now, with Unraid 6.8.0 RC9, which are you are successfully using? VMXNET3 or e1000-82545em?

Sorry for being so slow to respond, @Jagadguru! Yes...turns out I also have that going on. Odd. And unfortunate. Are you saying that with MacinaBox & Unraid v6.8.0rc5, e1000-82545 is successfully providing both bridging and Apple ID/iCloud/App Store functionality?

Thanks for the information, @Jagadguru. I'm not sure if it is faster than vmxnet3 or not, but you can have a look here: to see how I solved/worked around this issue by using e1000E, if you like!

That's a very good point. If you get everything together before installing macOS, it's all painless. This morning, I carefully chose a MAC address, ROM, MLB, SMBIOS Board Serial Number and SmUUID for a new virtual macOS install in about 10 minutes (I've done it before, which helps!), installed Catalina, and logged right into iCloud.

For anyone running into the e1000-82545em bridging-to-br0 weirdness under Catalina, I have a workaround that's working fine for me: Install AppleIntelE1000e.kext (I'm using the latest build from the fork at https://github.com/chris1111/AppleIntelE1000e) either to /Library/Extensions (the advantage being simplicity; you can install it manually or with the simple KextBeast utility) or by injecting it with Clover (the advantage being that it will likely work while installing macOS or when booted into Recovery Mode). Change the Interface definition in your XML to use the 'e1000e' virtual NIC: <model type='e1000e'/> Having done this, I can bridge to br0 under Catalina without issue, and even access the App Store and use iCloud services. I'm hoping to be able to make 'virtio-net-pci' work one of these days, but no luck so far.

@ghost82, thanks for that. The only differences between your working configuration and my non-working configuration are: Your br0 is running over bonded interfaces, whereas mine is running over a single interface. My PCI address is bus='0x00' slot='0x05'. You may (in my experience so far, probably will) need to move yours to bus='0x00' in order to get it to look to macOS like a built-in Ethernet port (which can be confirmed by searching for 'en0' in the IORegistryBrowser app); the App Store and iCloud stuff only works over a built-in Ethernet port. Meaning that if you had a MacBook with a broken Ethernet port and plugged in a third-party USB-to-Ethernet adapter to get back online...you then couldn't use iCloud (at least, not without some icky low-level spoofing trickery)! Sounds crazy, but it is discussed online by people who've run into precisely that. That's a serious DRM/security pain point! 😅

@Zer0Nin3r, are you saying that your Mojave networking is working with virtio? If so, would you mind sharing the snippet of XML that defines your connection?

@Jagadguru, are you bridging your e1000-82545em to br0? I ask because I've been running e1000-82545em bridged to br0 for years, with both High Sierra and Mojave. But Catalina melts down (doesn't fully paint the menu bar, gives me lots of beachballs, won't shut down) with that same configuration. If I change to a non-bridged e1000-82545em configuration, it works great...but I really need bridging back. No luck fixing it yet. Along the way, I've learned that vmxnet3 bridging works...but then I can't log into App Store or iCloud. 😓

@ghost82, when you turn on e1000-82545em bridging (to br0, I assume), does Catalina fundamentally function correctly? If so, are you on Unraid 6.7.2, or a beta? If your QEMU version is newer than mine, it might include a change to the vmxnet3 implementation. For me, it's still the case that when I shut down, switch from the default network to the br0 bridge, and reboot, Catalina won't even finish painting the menu bar, gives me lots of long beachball pauses, and won't successfully shut down. Also, regarding your "cannot verify your identity" issues, are they possibly because your Model, MAC address, ROM, MLB, SMBIOS Board Serial Number and SmUUID aren't all carefully chosen and in sync? If you aren't familiar with all these DRM-related issues, https://www.tonymacx86.com/threads/how-to-fix-imessage.110471/ is a great resource, but there's plenty to wade through that's more about issues specific to physical Hackintosh builds.

Edit: I wasn't quite right about this! It's true that that some or all of Apple's online services require communication over an en0 device that appears to be "built in"...but vmxnet3 does appear as a built-in interface if the system configuration is right. For my earlier testing, my virtual vmxnet3 interface was configured on bus 3/slot 0, in which case macOS decides it isn't built-in (IORegistry says IOBuiltin=False and IOPrimaryInterface=False, though I'm not clear if the latter matters). When I move my vmxnet3 to bus 0/slot 5, macOS does see it as built-in (IORegistry says IOBuiltin=True and IOPrimaryInterface=True). However, I still can't use it to log into to the App Store, as I get a "There was an error connecting to the Apple ID Server" error. If I switch back to an unbridged e1000-82545em configuration, I can log into the App Store. But, then I can't bridge, or Catalina has a nervous breakdown. Some progress on this...it looks like vmxnet3 simply won't work for Apple cloud services (including the App Store) by design, because macOS (for whatever security reasons, I suppose) requires a built-in Ethernet adapter for such things. Since vmxnet3 is a paravirtualized NIC powered by an Apple driver, it makes sense that macOS would know it isn't a real, built-in NIC. Just to confirm, with vmxnet3 networking active, I used IORegistryExplorer (an Xcode-related developers' tool) in the Catalina VM to search for 'en0' and, sure enough, found: IOBuiltin Boolean False So, vmxnet3 doesn't look like a good solution for those of us who use iCloud/iMessage/App Store/etc. At least, not without some low-level game playing that I'd rather not get into, if I can avoid it. So, that focuses my question: Why might bridging to br0 using e1000-82545em work under High Sierra and Mojave, but not Catalina? Is there a macOS virtual networking guru out there (perhaps even @SpaceInvaderOne?) who might be able to point me to something to analyze or try?

tl;dr: My Catalina VM doesn't like the same bridged network configuration I used with High Sierra and Mojave, and I can't make any sense of it. I've been running a simple (no GPU or other passthroughs) macOS VM on my Unraid server for years now--first High Sierra, then Mojave, and now Catalina. Before Catalina, I always successfully used a bridged network configuration like this (phony MAC address below): <interface type='bridge'> <mac address='00:11:22:33:44:55'/> <source bridge='br0'/> <model type='e1000-82545em'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </interface> When I boot Catalina with the configuration above, however, things go really strangely--the Ethernet cable is reported as unplugged, the system lags, the menu bar either never appears or is only ever partially rendered, sometimes the keyboard doesn't work at all, and I can't ever successfully shut down. I use Clover as my bootloader, so I tried this configuration with both same older bootloader and UEFI driver versions that worked with Mojave, as well as with everything updated to Clover v2.5k 5070; I saw no difference either way. So, I changed to a non-bridged configuration, like this... <interface type='network'> <mac address='00:11:22:33:44:55'/> <source network='default'/> <model type='e1000-82545em'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </interface> ...and everything works fine, which is surprising, given that it is still a virtual e1000-82545em NIC with the same MAC in the same virtual PCI slot. I wouldn't imagine that Catalina would even know the difference! It's better than nothing for the moment, but I really do need the VM to be bridged for my purposes. So, as another experiment, I tried bridging using the 'vmxnet3' virtual NIC, like this... <interface type='bridge'> <mac address='00:11:22:33:44:55'/> <source bridge='br0'/> <model type='vmxnet3'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </interface> ...which sorta surprisingly does make Catalina work properly, except I get bumped off all Apple cloud services, and System Preferences asks me to log in again. By itself, that isn't shocking, since I did change the (virtual) hardware out from under Catalina. The surprising part is that Catalina then can't reach the Apple ID servers: I did a fair amount of Googling about this result, and while I couldn't find anyone really getting into a discussion or analysis, I did find a few offhand references to vmxnet3 causing iCloud login woes. So, out of desperation, I tried installing Catalina again using vmxnet3 bridging from the start, but it made no difference. So, does anyone have any idea why a straightforward e1000-82545em bridge that worked fine under High Sierra and Mojave might cause Catalina to melt down? Or (though I'd much rather just get the e1000-82545em bridging working) does anyone have any experience getting communication with the Apple ID servers working properly with a vmxnet3 bridge? Thanks for any help!

Thanks for the response, @jonathanm. I've revised my original post just a bit to clarify that I'm not shooting for the host discerning the trajectory of the guest--I'm looking to get a chance to do some work before (or even as) the host makes an effort to shut down the guest. That is, I'm only trying to catch the case that Unraid/libvirt is making an attempt to shut my VM down from outside the guest. It's easy to learn that my VM was shut down, but I'm hoping to be called before it happens.

I'm not quite sure where to ask this question! It could end up being appropriate here, or perhaps it's a plugin question, or perhaps it's something else. What I'm trying to do: I'm looking for a way to run a custom script on my Unraid server (on the host, not the guest) before one of my VMs is shut down by the host. Also, while I do want to catch the case that my VM is shut down from the Unraid GUI, I could live with only catching the case that the array is being stopped. What won't work: Building a manually-executed script that does my additional work and then shuts the VM down won't do the trick, since I need to do this additional work automatically even in the cases that the VM is being shut down from the GUI or is being shut down automatically as a result of the array being stopped. What doesn't work: To catch the case that the array is being stopped, I've tried the User Scripts plugin, with a script that runs "At stopping of array," but that's too late--my VM has already been shut down by the time my script is called. To catch that same case, I've also tried a bare-bones custom plugin (/usr/local/emhttp/plugins/my_custom_plugin/event/stopping_svcs), but that's also called too late. I've even looked into modifying the libvirt /etc/libvirt/hooks/qemu script, but it too is called after a VM has been stopped. Any thoughts on how to catch an attempt at shutting a VM down, or at least being called early in the array-stopping procedure? Thanks for any ideas!

This thread initially seemed bizarre to me, but now I think I get it; I'd appreciate any feedback on my understanding: On a real SSD, as I understand things, TRIM speeds up some writes and reduces wear on the flash chips by telling the SSD which blocks are no longer in use by the file system, so that the SSD controller can more efficiently deal with them. So...for a virtual qcow2 disk image, enabling TRIM helps keep the dynamically-allocated disk image from growing more quickly than necessary? And, assuming I'm right about that...are there any other advantages?

For anyone else chasing this broken-Ethernet-at-boot issue, I seem to have fixed it on my system by changing the bridge PCI bus to '0x00' and slot to '0x05' thusly: ... <interface type='bridge'> ... <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> ... Since making the change, over a couple dozen boots, I haven't again seen macOS report the (virtual) Ethernet cable as being unplugged.

That's painful, but makes perfect sense. NFS implementations that only consider 32 bits of a 64-bit value are why we can't have nice things Thanks for the explanation!