Install OS X to physical via VMware


General guide for installing physical boot OS X from a Windows VMware hosted guest instance – Including some specifics for Yosemite, El Capitan latest macOS, the Clover boot loader, and my specific hardware.

This guide is admittedly dense with detailed experience (for my own reference), yet the core idea is simply this: get into an OS X virtual machine and from there, install OS X to your physical drive 🙂

The one main snag to this Virtual to Physical approach was that, even when the physical installation drive was taken “offline” via Disk Management, Windows still had a readonly lock on the boot parition such that the bootloader install (Clover) would fail… and we’re not going anywhere in h@ckintosh land w/o a bootloader… fortunately I finally came upon a couple smarties in the VMware forums that suggested a rather obscure hack that works (see “MBR trick” below).


  • This approach generally assumes you’ve got a WinPC already and you want to leverage that same hardware to physically boot OSX at times as well.
    • Once you’re in OSX, Parallels and VMware Fusion do both support running your physical Windows instance as a VM… this corresponds to VM’ing your Bootcamp partition under a real Mac… so to be clear, we use a Windows host to run an OSX VM from where we install OSX to a physical drive, then boot that OSX host and run that same original Window host installation as a VM under OSX 🙂
  • To put it out there up front – The convenience of ready-to-run VMware OSX images are the primary timesaver in this approach. Full disclosure, if you hadn’t heard it before, H@ckintosh is already a grey area, and the bits required to patch VMware to run OSX are more shades of grey. I’ve included links to finding the bundle we’re counting on. That VMware stuff can admittedly get fiddly and the convenience factor drops off fast when that happens… I intend to document that better next time I go through the process.
  • Secondly – I had trouble getting my USB stick to boot with Clover on my hardware – which appears to be a known issue on my mobo (Gigabyte X99-UD4) – so on the way to prepping a USB for UniBeast, I figured why not see how tough it is to install directly from VM OSX to my intended physical drive vs fighting the USB.
  • Even if you don’t have an inherent USB problem like me, I still feel strongly this approach dodges a lot hassle by skipping the whole routine of applying the latest desired OSX installer to a USB… that is not a trivial process…
  • For what it’s worth, this approach pretty much guarantees you won’t run into issue just getting the vanilla OSX bits on your physical drive… you will naturally still have to slog through whatever your individual hardware compatibility effort requires to actually boot up… but at least you only fight that battle once with the real boot vs once with the USB and then again with the real boot
  • now one could argue we’re shifting our annoyance burden from building USB boots to fiddling with this special VMware install… and that’s fair… but once you’ve mastered a known good VMware+OSX, you can readily archive & restore that bundle of files whenever you need… you can leave that version of OSX as it stands (say at Yosemite)… from that known working baseline, the processof getting the latest greatest OSX (El Capitan and beyond) onto your physical drive is a breezy affair of running the upgrade from the App Store…
  • Apple does keep locking down kext security more and more so there’s been a trickle of tweaks necessary on the SIP/CSR end of things going from Mavericks to Yosemite to El Capitan… those have been trivial settings to apply once identified but as is typical in this space, one must scrounge the interwebs to find those clever souls who’ve figured out the latest little trick… yet this is the nature of the game and would be just as necessary (doubly so) with the USB route.
  • Extra bonus – when troubleshooting is necessary, it is way easier to noodle around on your physical drive from the full working OSX VM environment vs the constrained environment you get from USB boot into Installation / Recovery mode.

Hardware as of this guide:

  • FYI – This is a perfectly copacetic Hackintosh build… sleep works great, dual screen digital video is perfect as well as audio and network.
  • Mobo: Gigabyte GA-X99-UD4 – LGA 2011-v3
    • bios: F12
    • onboard ethernet: Intel I218-V (kext required)
    • onboard audio: Realtek ALC1150 (vanilla support)
  • CPU: Intel i7-5820k – 6 core Haswell-E (vanilla via Clover flags)
  • Video: Asus Strix Nvidia GeForce GTX 750Ti 2GB – a nice fit indeed:
    • No drivers necessary to vanilla boot into Yosemite – understand there is no QE/CI out of box but a very workable low res mode for initial install and then full QE/CI via Nvidia “webdriver”.
    • ! fanless ! unless pushed hard by a game, which never happens to me 🙂
    • 3 simultaneous digital outputs, INCLUDING DisplayPort – I can confirm this card supports at least dual monitors under Yosemite via any combination of DP / HDMI / DVI (dual- link) with any of them driving 2560 x 1600 res…can now also confirm 4k @ 60Hz @ Chroma 4:4:4 over DisplayPort on this card… currently doing active conversion from DP to HDMI for this screen (Samsung 49″ TV UN49MU6500)… direct HDMI did NOT go full 60Hz as expected due to lack of HDMI v2.0 support

    • no more horsepower than I care to pay for => $160 at the time … and was well stocked in major outlets circa April 2015
  • Corsair H80i Cooler USB – caused OS X “re-wake” issue Corsair’s “i” models sport temperature and fan speed sensors that drive monitoring software (Windows only) via USB … if one goes looking, it’s easy to see the USB drivers have been a mess for years … even with the well known hacks applied, i only got occasionally working guages after reboots let alone the annoying wake issue … highly recommend avoiding any of these “Corsair Link” products… or simply leave the USBs disconnected if you fall for the marketing like i did

Obtain Software Bits:

Software versions only listed for reference as of this build, not crucial unless noted.

  1. VMware Workstation (v11.1)
  2. Find a recent OSX VMWare image (I started with Yosemite v10.10(.0) 14A389)
  3. latest VMware unlocker – crucial to enabling OS X guest functionality in VMWare
  4. Yosemite latest macOS via App Store download (v10.10.*2* 14C109)
    • get this download running as soon as you can get into the VM since it takes a while
    • if curious, you can confirm which version of OSX you got from the app store via the “Startup Disk” popup that comes when you quit out of the installer.
  5. Clover Configurator (v4.23.0) – essential, seals the deal on Clover
    1. Later, use Clover Configurator to download and install latest Clover – Clover version history
    2. while UniBeast still seems to cover more diverse hardware situations, Clover is pretty slick if your hardware is copacetic (basically starting with a UEFI capable mobo)
    3. the “EFI partition only” footprint is nice for vanilla segregation – it sits there intact if you want to completely wipe & reinstall OS X primary partition
    4. Couple nice bits for my hardware
      1. HaswellE kernel patch is a checkbox vs manually patching the kernel – nice!
      2. no fuss NVRAM checkbox which effortlessly enables iMessage and App Store connectivity
  6. KextWizard (v3.7.11) – one handy feature above other more well known kext loaders, it will target another drive which is perfect for this side-load scenario
  7. Nvidia’s web driver (my hardware)
  8. Raw kexts
    1. FakeSMC – bare minimum DSMOS avoidance for non apple hardware
    2. AppleIntelE1000e (v3.1.0) (my hardware) – for X99-UD4’s onboard Intel I218-V ethernet
    3. VoodooTSCSync patched for 6 core (my hardware) – author site says this addresses “spin lock” issue
    4. GenericUSBXHCIin conjunction with disabling XHCI in bios, this kext enabled night and day improvement in VM performance under **Yosemite** … under El Capitan v10.11.2 my USB devices stopped working… removing this GenericUSB kext allowed them to work again and fortunately the previous Parallels VM performance problems didn’t manifest after that… I also up’d from Parallels V10 to V11.1.1 (32312) since then which might be aiding this complex compatibility equation as well.

BIOS settings:

  1. SATA controller in AHCI mode – classic requirement
  2. xHCI = manual, xHCI handoff = disabled – (Reference) this made a major difference on running VM’s

VMware Guest Configs:

  1. add ‘smc.version = 0’ to the VMX file in order to resolve error: vmcore/vmm/main/physMem_monitor.c:1123
  2. Add physical disk to guest – In addition to the main vmware virtual drive that your guest OSX boots from
    1. i found SATA interface to *never* work vs IDE or SCSI… SCSI gave some minor warning so i went with IDE / full disk / persistent
  3. MBR trick to allow boot utilities (e.g. Clover installer) under vmware guest to write to physical disk:
    • sure am **grateful** these guys figured out how to hack around this issue, otherwise this whole approach would be dead in the water with no way to write to the physical disk
    • pretty surprised vmware hasn’t been blasted into fixing this issue… it doesn’t seem OSX specific but maybe that’s why it’s remained obscure
    • In my experience on Win8.1 & Win10, simply taking the drive “offline” via DiskManagement was not enough… even though I’ve seen that suggested several times… maybe Win Server behaves differently?? and therefore works out for the majority of folks running VMs… or maybe OSX install does some rather uncommon boot partition writes vs other operating systems??
    1. ** This must be done BEFORE firing up vmware guest
    2. hide the physical disk from Windows by temporarily clearing the “MBR magic” signature in the very last 2 bytes of sector 0 (see DirectDisk tool screenshot at bottom under “MBR Trick”)
    3. then refresh Disk Management (or DiskPart.exe > rescan) and the drive will show that it’s now completely unknown
    4. now put the 55AA signature back so the Mac guest can see the drive – but be careful not to refresh Disk Management or DiskPart
    5. now fire up vmware guest and you’re good to slam that drive all day long

Lessons Learned:

  1. For Clover boot errors like “Couldn’t allocate runtime area” or “requested memory exceeds our allocated relocation” on UEFI boot X99 mobos, see this post… in a nutshell, that smart dude has created a better combined replacement for the LowMemFix and AptioFix drivers

  2. Major Parallels/Fusion VM performance fix!! – the nutshell is apparently the xhci stuff has a major impact… i had mine disabled but then didn’t have xhci manual mode selected nor the GenericUsbXhci.kext loaded (see El Capitan update under Software Bits 8.4) and after doing both of those my Parallels 10 performance was respectable…prior to that all Windows VM spinups were major slow and obviously just hammering the first core from Activity Monitor, afterwards all cores jump around randomly.

  3. Bootcamp under Parallels, fix “missing operating system” – first shutdown the Bootcamp guest VM so you can make configuration edits, then “Edit Partitions” and for me, my little recovery partition wasn’t selected vs the main Windows OS partition, just had to select it (in addition) and restart.

  4. Updating OSX <=> Nvidia driversSEE THIS POST – the Nvidia “web drivers” are rather obnoxiously hard wired to each specific OSX point release (e.g. just going from 10.12.5 to 10.12.6)… so the first boot right after an upgrade requires special attention because the previously installed driver is no longer compatible… the main thing to be aware of is temporarily adding nv_disable=1 to your boot args via the Clover “options” page, which gets you back into a working low res desktop where you can follow the Nvidia driver automatic update process…

    • UPDATE: in more recent version of Clover (4049), I needed to go into the Clover options > Graphics Injector submenu and uncheck the Nvidia Web Drivers entry… nv_disable didn’t seem to work anymore
  5. Using MacPro6,1 for your SMBIOS requires a special patch – see Fix#4

  6. I’ve come to understand that iMac14,1 is one of the more forgiving choices… Apple is changing the USB game a lot starting with El Capitan… they are restricting USB ports depending your SMBIOS machine… reportedly iMac14,x does not currently (v10.11.2) receive any restrictions on the USB 2.0 side (EHCI)… i can report at least all my USB2.0 devices operate (Logitech Z305 speaker, Logitech C910 webcam, Logitech Anywhere receiver)

  7. starting from a completely bare drive – just format it as GPT Journaled with a single partition via DiskUtil – this will create an unavoidable ~200MB EFI partition which is good for clover

  8. Yosemite installer or Recovery script will add “Recovery HD” partition – however, i don’t particularly see the need for Recovery mode vs booting into full OSX VM for any troubleshooting

  9. on the VM image i had major kernal_task CPU crunches that would storm in and bring everything to a stand still… guessing thru googling that some IO kext is getting hung up… i disabled sleep and this issue no longer occurred, no big surprise.

  10. easy success with Migration Assistant restoring from Time Machine backup after booting into a fresh OSX install makes this my preferred approach – see “Time Machine saving to Windows share” under Misc tweaks below.

System Integrity Protection (SIP)

Under OS X 10.11 El Capitan and beyond, SIP presents a new challenge to hacking kexts
(good ref)

  1. Under Clover Configurator set the follow RT Variables:
    1. CsrActiveConfig = 0x03 (for full) – or 0x01 (for partial)
    2. BooterConfig = 0x28
  2. remove the old rootless=0 and kext-dev-mode=1 from boot args
  3. Kext Utility 2.6.4 seemed to resolve refusal to load S/L/E kexts after edits were made

Install Steps:

  1. Fire up the VMware OS X guest on pre-installed virtual Yosemite image (Bits 1 & 2 above)
    1. Make sure BEFORE launching OS X guest, perform “#3. MBR trick” under “VMware Guest Configs” above
    2. if you install the darwin.iso tools the resolution does get a nice little bump from 1024×768 to 1920×1080… and it seems to be slightly more responsive – find in: C:\Program Files (x86)\VMwareVMware Workstation\darwin.iso
    3. Physical drive must be formatted before Yosemite installer will recognize as a valid installation point (specify GPT & Journaled)
  2. Install Yosemite latest macOS to the physical drive via Apple App Store download
    1. I counted 3 restarts… first round ended with a few mins stuck on “1 sec remaining”, second round was ~20 mins long… 3rd and final looped me back to the beginning of the install, confusing if you’re not paying attention… just bail out and reboot back into virtual Yosemite
    2. If you wind up fumbling that last stage like i did, then you’re the proud owner of a fresh new install WITHOUT ANY WAY TO LOGIN, doh! …  this article is handy 🙂
    3. since you now have 2 viable boot drives under VMware (the original virtual disc and this new physical), make sure to select the virtual as your default startup disc via the mac “Startup” preferences panel… after some fiddling i got VMware to load my physical for kicks but typically the reason you need to be in VMware is your physical is hosed and you’re looking to troubleshoot from your virtual
  3. Use Clover Configurator to download and install latest Clover – Remember to select the physical drive as the installation point
    • I went with the EFI only install with no other checkboxes necessary
  4. Clover Configurator settings – these need to get saved to your EFI partition/EFI/Clover/config.plist, so you’ll need to mount your EFI partition and make sure to select this file before you start applying settings, and then don’t forget to save before quitting.
    1. Boot tab:
      1. -v – verbose, you’re going to want to watch for any clues if it blows up
      2. npci=0x2000 – everybody says this one is crucial
      3. nvda_drv=1 – (my hardware)  enables loading Nvidia kexts
      4. (El Capitan no longer honors this flag) kext-dev-mode=1 – this enables loading of unsigned kexts
      5. slide=0 – pulled this from a guide (not sure necessary)
      6. (my hardware) Legacy = LegacyBiosDefault – this enables Windows to boot when it’s been installed in MBR (aka Legacy) mode vs UEFI mode
    2. GUI – hiding entries on the clover boot menu is complicated by all the different combinations… this is the strategy that was the most rational for me
      1. Scan = Custom, then select Entries & Tool (leave Legacy and Kernel unchecked) – i couldn’t figure out how to hide my Windows EFI partition from the legacy scan so this disables legacy scanning entirely
      2. Hide Volume => Recovery HD – this was the only one that still needing specific hiding
      3. Custom Entries
        1. one for the OSX volume by name (not the mac/clover EFI volume), don’t forget to set the Type field or it won’t save to config.plist, no other fields required, but you might want to set a specific image file (e.g. EFICLOVERthemesthinkpadiconsos_yos.icns)
        2. one for Windows volume by UUID, always set the Type field, no others required
    3. Kernel and Kext Patches
      1. KernelHaswellE (my hardware)
    4. Install Drivers – for Yosemite everything will be 64bit and I’m doing UEFI only so we’ll be selecting only from the two bottom sections on the Install Drivers tab (i.e. “Drivers UEFI 64 bit” and “Extra Drivers”)
      1. remove VBoxHfs
      2. add HFSPlus UEFI
      3. —- my hardware — otherwise Clover will hang trying to allocate contiguous memory right after OS selection
      4. add OsxAptioFixDrv
      5. add OsxLowMemFixDrv
      6. add OsxFatBinaryDrv UEFI
    5. Theme – my chosen them never seemed to save to the config.plist for me so i just found the <theme> section and put the one i wanted manually (textedit works fine here).
  5. Copy kexts to EFI\EFI\CLOVER\Kexts\10.10
    1. FakeSMC
    2. VoodooTSCSync (my hardware)
    3. GenericUSBXHCI (my hardware) – no longer recommended, see El Capitan update under Software Bits 8.4
    4. AppleIntelE1000e (my hardware)
  6. You should now be able to reboot into this new physical OS X – *** I’ve needed to include “nv_disable=1” in the boot args until i’ve gotten the Nvidia WebDrivers loaded ***; THIS POST is very helpful for all the different issues
  7. Play it safe, do a Time Machine backup of this pristine install before you do anything else to screw it up (see “Time Machine saving to Windows share” below) – *** especially before the Nvidia drivers ***, i’ve had them black screen me… if that happens, try nv_disable=1 boot arg first before starting completely over.
  8. Last juicy step is to go ahead and install latest full Nvidia web drivers (Tip: confirm your specific OS X version via Finder > About This Mac > and hold ⌘ when you click the version number)

Misc tweaks and tools:

  • DiskPart cheat sheet
  • XtraFinder – dual panes!, tabs, F2=rename, Enter=launch file, Delete=delete file
  • Kext Utility
  • Clover Preference Pane
  • Installing Windows in UEFI Mode – this makes it more straightforward to target the drive for booting from Clover… it’s also supposed to be the fastest way to boot up
  • Fix Home/End keys: Karabiner > “PC style” keys options
  • Show All Drives in DiskUtility:
    defaults write DUDebugMenuEnabled 1
  • Resolve Microsoft Remote Desktop self signed cert lockup (ref#1, ref#2)
    1. Use Activity Monitor > View > All Processes to kill SecurityAgent which will dump the hung authorization popup
    2. Open Keychain Access app in OSX
    3. Select Certificates under the category heading – trusted certs are marked with a white plus in blue circle
    4. double click your untrusted certificate
    5. expand Trust section
    6. select Always Trust for SSL
    7. close, done
  • Enable Time Machine saving to Windows share (smb)
    1. Save a “sparsebundle” image to your share via DiskUtil > new image… 500GB or whatever… it’s “sparse” so it won’t use all the space right away… go with “Single Partition – GUID” and Journaled
    2. “Mount” your share via Finder ⌘-k, confirm by Finder > prefs > SideBar > Devices > {your machine}…  look for share as a drive icon there
    3. Double click the sparsebundle to get that mounted as well
    4. Terminal: sudo tmutil setdestination /Volumes/{sparsebundle drive}
    5. Fire up Time Machine prefpane and select that drive, yay!
    6. Use Users prefpane > Login Items to make the two mounts automatic after reboots so that Time Machine has continuous access to do its background backup magic
    7. CONFIRM THAT YOU CAN RECOVERY RESTORE from this rather unsanctioned source – traditionally one does this from a “Recovery HD” partition with the special Time Machine Restore tool available to that environment but i ran into enough snags that my preferred approach is to reinstall OSX from scratch from the OSX virtual machine, then boot back into the fresh install and use Migration Assistant to restore from the Time Machine backup. This is a resilient solution because if we somehow trash this guest VM, we can readily recreate it from the source vmdk file.
      1. If you’re still interested, here’s notes on creating a bootable Clover recovery partition – i had a lot of trouble modifying the BaseSystem.dmg to include my NIC’s kext such that i could point the Time Machine tool at my backup volume over the network
      2. (unsuccessful) Time Machine restore over NFS from Recovery mode
        • SMB is not supported in the limited Recovery environment so NFS is the next obvious choice to restore from a network source
        • NFSAxe was the one Windows NFS server that did at least support the basic OSX client to Windows mount (after trying both FreeNFS and haneWin NFS)
        • Time Machine via NFS on Mavericks and Mac NFS client tutorial – details pertinent Terminal commands… but ultimately ran aground with “sparsebundle not compatible” error which seemed like a limitation of the mount util (hdiutil) or the underlying filesystem libraries not available under recovery mode
          • make root drive writeable: mount -uw /
          • create mount point: mkdir /private/MacBackups
          • mount -t nfs beejquad:/m/macbackups /private/MacBackups
        • If curious to try, the Recovery mode tools can be fired up under standard OSX
          • mount any “Recovery HD” partition you can get your hands on
          • then under, find BaseSystem.dmg and mount that (it is hidden)
          • Then the special Time Machine full restore app is under: /System/Installation/CDIS/Time Machine System Machine System Restore … but again, this didn’t pan out for me since i wasn’t able to mount my sparsebundle image that contained the Time Machine backups… it seemed to be a Recovery mode limitation because the sparsebundle file continues to mount fine under standard OSX boot
  • Mounting EFI partition under windows
    1. launch cmd.exe, then:
    2. diskpart
    3. list disk (looking for the right drive)
    4. select disk x (where x is drive number)
    5. list part
    6. select part 1 (EFI will be first on a normally formatted GUID drive)
    7. assign letter=e
    8. (when done) remove letter=e
    9. Then need to launch explorer.exe as admin to access this E: drive
      1. cmd.exe as admin
      2. taskkill /im explorer.exe /f
      3. explorer

MBR Trick:

Leave a Reply