5 ms·
I've been running my macOS desktop in an ESXi VM for over a year now. I came from a hackintosh, but got tired of the fragility of some upgrades. Some notes on
by matthew-wegner 8y ago
I've been running my macOS desktop in an ESXi VM for over a year now. I came from a hackintosh, but got tired of the fragility of some upgrades. Some notes on this setup:
- Apple supports macOS running inside of ESXi. Officially, only on Apple host hardware (i.e. a Mac Pro, which is on the ESXi compatibility list). Apple even ships a VMXNet3 network driver in macOS.
- For ESXi specifically, you have to patch the host to boot macOS on non-Apple hardware. There's an explicit "am I running on Apple hardware?" check in there. DrDonk's unlocker on GitHub is what you need.
- You can specify board-id, ROM/MLB, etc values via your .vmx file. iMessage and everything work for me, but I'm also using identifiers from a real Mac Mini I retired a few years ago. I expect this will still work okay with generated data if you follow hackintosh guides.
- I pass through a GPU and a USB controller card for input/output. For USB, find an FL1100 chipset card, like the Inateck models, which works out of box on macOS, Windows, etc. Recently I moved my boot drive to a passed-through NVMe for extra speed. My other drives are ESXi virtual drives backed by storage elsewhere on my network.
- Most NVIDIA GPUs will need the NVIDIA Web Drivers to work. Kepler generation cards are the last to work out of box, and the only to currently work out of box on Mojave. If you don't need hefty performance, a GeForce GT 730 is a cheap card. Apple and NVIDIA are still not getting along, so I expect this will only get worse.
- However, I've never been able to get an AMD card to initialize via passthrough. The PCI device is seen, but the EFI strings or whatever else Apple is using to determine initialization paths are wrong. I recently spent awhile trying to figure this out, going so far as to write my own SSDT tables for the device, but finally gave up.
- This particular guide is using Chameleon, which is considered an outdated bootloader. Clover is far more flexible, and will work in VM setups that don't natively implement SMC like ESXi. (For the longest time Clover would crash an ESXi VM, but this now works as of a month or two ago).
And finally, on the context of this whole thing--I switched from a real Mac Pro to a hackintosh years and years ago, when it became clear Apple didn't care about upgrading the hardware. They still don't. The last Mac Pro release was 2013 (the 2013 iPhone was a 5S!). They've been promising things will improve "soon". They're the world's most valuable company; if they actually cared, at the organizational DNA level, it would have happened by now.
- supernes 8y agoCan you please elaborate on your GPU passthrough setup? I was under the impression that NVIDIA have explicit checks to see if you're trying to virtualize a consumer brand GPU and throw an error in that case. I have a PC with a GTX 970 that I wanted to try a similar install on, unfortunately the i5-3570K in there doesn't support VT-d from what I can tell.
- matthew-wegner 8y agoThose checks are at the driver level, and only for Windows (you can circumvent them by not exposing VM cpuid details to the guest). On macOS I haven't done anything special. Kepler cards work out of box, and other cards just need NVIDIA's own web drivers installed. Even on real Mac Pro hardware, those drivers are notoriously bad. They're tied to explicit macOS updates, so most people use something like this to patch older versions if new releases have issues: https://github.com/Benjamin-Dobell/nvidia-update https://github.com/Benjamin-Dobell/nvidia-update
- dperfect 8y agoFrom my experience with a GTX 950 and a GTX 1060, the macOS Web Driver from NVIDIA doesn't seem to care about virtualization, and it works fine (assuming the drivers and passthrough are configured correctly). Windows is a different story, and I had to use a patched vBIOS[1] to get my 1060 working without Windows 10 throwing the dreaded "Code 43" error (when it detects virtualization and refuses to work). In my case, the CPUID workaround mentioned in another comment didn't help. As for VT-d, I believe the unlocked "K" processors from Intel all have VT-d disabled for some reason. [1] https://github.com/Matoking/NVIDIA-vBIOS-VFIO-Patcher https://github.com/Matoking/NVIDIA-vBIOS-VFIO-Patcher
- SXX 8y ago> As for VT-d, I believe the unlocked "K" processors from Intel all have VT-d disabled for some reason. This was only the case up to Haswell CPUs. They stopped crippling IOMMU capabilities since Haswell Refresh (i7-4790K).
- 8y ago