bland328

Members
  • Posts

    105
  • Joined

  • Last visited

Posts posted by bland328

  1. 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. 😉

    • Like 1
  2. 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.

    • Like 1
  3. On 10/25/2019 at 11:06 AM, Jagadguru said:

    @bland328 After injecting that kext, networking works great, but there is a process called kernel_task which now has constant 115% CPU usage. Is your VM doing that as well?

    Sorry for being so slow to respond, @Jagadguru! Yes...turns out I also have that going on. Odd. And unfortunate.

    On 10/30/2019 at 4:27 PM, Jagadguru said:

    EDIT: a New Macinabox install works with e1000-82545em on unRAID v6.8.0 rc5, Tested on two machines, both not working with 6.7.2 and both working with 6.8.0 rc5.

    Are you saying that with MacinaBox & Unraid v6.8.0rc5, e1000-82545 is successfully providing both bridging and Apple ID/iCloud/App Store functionality?

  4. 16 hours ago, Jagadguru said:

    Yes this is exactly my problem. But I also need bridging because I need my VM to have an address on the main subnet for automated ssh, etc. Yes vmxnet3 has a crippled slow upload speed, so it fails at some connections.

    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!

     

    • Like 1
  5. Just now, ghost82 said:

    everyone should read it BEFORE attempting to make the mac os to work

    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.

    • Like 1
  6. For anyone running into the e1000-82545em bridging-to-br0 weirdness under Catalina, I have a workaround that's working fine for me:

    1. 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).
    2. 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.

    • Like 3
  7. @ghost82, thanks for that. The only differences between your working configuration and my non-working configuration are:

    1. Your br0 is running over bonded interfaces, whereas mine is running over a single interface.
    2. 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! 😅

  8. On 10/14/2019 at 2:31 PM, Jagadguru said:

    Glad to hear you finally got it! Now if I could get e1000-82545em to work with Catalina. Does the above pic look right?

     

    A lot of things break when that driver loads. Finder won't open, screenshot doesn't work, won't shut down, preferences crashes.

    @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. 😓

  9. @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.

    • Like 1
  10. 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?

  11. 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:

     

    681184911_ScreenShot2019-10-14at5_20_42.thumb.png.b5c713ba586887be5f3db2bfa75f5bef.png

     

    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!

  12. 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.

  13. 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!

     

  14. 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?

  15. 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.

    • Thanks 1
  16. 22 hours ago, limetech said:

    The compromise reached was to revert our change to pass the actual inode values.

    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!

  17. On 12/22/2018 at 6:04 PM, limetech said:

    Your 'ls -li' command is listing "pseudo" inode numbers in the fuse file system.

    Ah! I think this explains the hard link struggles I'm experiencing when attempting to de-dupe files using rmlint.

     

    So, @limetech, do I understand correctly that:

    1. If I make a hard link in a User Share (e.g. in /mnt/user/test), it will indeed make a hard link on the Device (e.g. in /mnt/disk3/test), but...
    2. The shfs FUSE file system generates "pseudo" inode values, and therefore...
    3. There's no way to detect hard links in User Shares--I can only detect them by examining the inodes of files on Device(s)?
  18. In this 2017 post:

    @llonca13 says:

    Quote

    ...if anyone has a problem with Ethernet showing disconnected...edit your xml under ethernet device - address type - put the slot number higher (for example slot=0x05)...EDIT: just seen that gridrunner already pointed out this in another thread.serves me right for not reading everything first  

    That sounds promising! Though I haven't been able to find the original @SpaceInvaderOne (formerly @gridrunner) post referenced, I have attempted to change the slot number in the XML as follows:

    ...
          <address type='pci' domain='0x0000' bus='0x01' slot='0x05' function='0x0'/>
    ...

    However, when I make just the single-digit change and then click Update in the XML View, I immediately get this error pop-up from Unraid:

     

    VM creation error
    XML error: Invalid PCI address 0000:01:05.0. slot must be <= 0

     

    Any thoughts on what I'm doing wrong? Do I need to somehow update the definition of PCI bus 1, or otherwise "create" slot 5?

     

    Or am I just all confused because @llonca13's original post above is only about passing through a physical NIC, and wouldn't apply to a virtual bridge? 

    • Thanks 1
  19. Aside from an Ethernet issue I haven't solved, I've got what seems to be a rock-solid Mojave VM running under Unraid 6.6.6.

     

    My Ethernet issue is simply that often (but not always) after I boot the VM, I don't have Ethernet access. In this case, System Preferences > Network says that my Ethernet cable is unplugged.

     

    If I then issue

    $ sudo ifconfig en0 down && sudo ifconfig en0 up

    from the Terminal, Ethernet starts working, and I've never seen it then fail again until I reboot the VM.

     

    My network configuration looks like this (MAC address censored):

    ...
        <type arch='x86_64' machine='pc-q35-3.0'>hvm</type>
    ...
        <interface type='bridge'>
          <mac address='99:88:77:66:55:44'/>
          <source bridge='br0'/>
          <model type='e1000-82545em'/>
          <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
        </interface>
    ...

    Any thoughts on how I might fix this? Or, at least, gather more data?

  20. 23 hours ago, user2352 said:

    This happens when you change the name of the VM. The primary vdisk location is set to auto and is still looking for the "oldname.img". You will need to manually select the correct img file.

    I see where you are coming from there, and I have indeed changed the name of my VM at some point, but the current situation is that I have manually selected the correct img file, and have to re-manually select it every time I attempt to submit any changes made in Form View.

     

    So, feels like a straightforward GUI bug, but I'm not sure exactly what is triggering it.

     

    Or, do I misunderstand your point, @user2352?

    • Upvote 1