GUIDE How to Install macOS on Hyper-V - OpenCore Install Guide

[EliteMacx86]

How to Install macOS on Hyper-V - OpenCore Install Guide​

Booting the OS X/macOS installers on a non-Apple computer can be challenging for new users and when it comes to Virtualization, it can be more complex. This guide is intended for those who wish to use OpenCore as a Bootloader and it covers a step-by-step process to boot the OS X/macOS installer on your target Desktop or Laptop using the OpenCore bootloader on a Hyper-V along with the installation and post-installation. Both installing using OpenCore UEFI and OpenCore Legacy are described in this guide.

By following this guide, you'll also be able to create a complete OpenCore EFI for your particular system. This guide supports both Intel and AMD Desktops and Intel and AMD Laptops with UEFI/Legacy boot mode. Of course, the hardware compatibility must be taken care of. Those who are still using Clover as a primary bootloader, can either switch to OpenCore or can follow Clover Installation Guide.

Although UEFI Capable Systems have several advantages over Legacy, there can be systems that do not support UEFI booting and are only capable of Legacy booting. But if you do have a system that supports UEFI booting, it is recommended to use UEFI booting over the legacy boot.

• If you have a computer that is UEFI capable, follow the UEFI instructions.
• If you have a system that doesn't have UEFI capabilities, then follow the Legacy instructions.

If you have requirements like Graphics acceleration, we highly recommend installing macos on bare metal.


Unlike other virtualization platforms, graphics artifacts are expected, audio are pretty common issue with this method

Please note that unlike other common Virtualization Platforms like VirtualBox, and VMware, Hyper-V is also limited, and certain hardware and features will not work on macOS under Hyper-V. If you require such a feature, we highly recommend installing macOS on Bare Metal. See Installing macOS on Desktops and Laptops for more information

Although macOS can be installed on a supported bare metal machine along with almost all the features that a real Mac offers. However, a few users can be interested in running macOS inside Windows for several purposes.

What Hyper-V?​

Hyper-V is a virtualization product developed by Microsoft and is a native hypervisor. It allows users to create and run multiple virtual machines (VMs) on a single physical server. Each VM acts like a complete computer, running an operating System and programs. A Hyper-V can have multiple virtual machines, each with its own operating system on the host computer. You can select the operating system that you want to use. You can install different Operating Systems as per your needs such as Windows, macOS, or any distribution of Linux.

What's the difference between running macOS on a bare metal and Hyper-V?​

Running macOS on a bare metal means you're running macOS on the native hardware, without any layers in between.


everything can be done on the same target machine you want to use Hyper-V.

Can you install macOS on an AMD System in Hyper-V?

Is AMD CPU supported on Hyper-V for running macOS?​

AMD CPUs have never been supported by Apple officially. However, with the community efforts, from modifying the kernel to allowing it to boot on AMD Systems. With consistent community efforts, today the Kernel can be patched on the fly using Clover or OpenCore allowing you to install the latest macOS. Despite booting macOS is possible on AMD bare metal, AMD is currently unsupported and requires additional patches beyond the standard patches from Shanee and the team. Currently, only Intel CPUs are supported at the moment.

Is Graphics Acceleration possible in Hyper-V?​

It is understood that the Graphics acceleration is really important, even for a basic user i.e. who doesn't have editing/rendering needs. Without the Graphics acceleration, there are a lot of artifacts, and random freezes, and some Applications may not even support certain functions, or simply executing such Apps will not work. However, the GPU passthrough is quite limited in Hyper-V and Windows in general. It's because the passthrough is not a real GPU passthrough, unlike the KVM, this is a layer so it just passes over / translates the Graphics API that's why only D3D works and supports no other Operating System than Windows itself. Unless Microsoft decides to add support for a real GPU passthrough there is no way it will work with any other Operating System like macOS.



Can you passthrough PCI Devices on Hyper-V?

Can I use the VHD File from somewhere else?

Is it possible to perform a clean install?
Yes, using this guide, you can perform a clean install of the desired macOS version as long as you meet the requirements.

As long as you meet the requirements, you can perform a clean install a desired copy of the macOS version as a guest Operating System.

Is it recommended to install macOS on Hyper-V?​

Generally, no. If your hardware is supported, installing macOS on bare metal is always recommended due to the ease of the installation and seamless support due to the maximum performance, support and compatibility.

What is OpenCore?​

OpenCore is a bootloader - Unlike any other bootloader such as GRUB, it is an advanced bootloader especially designed to boot macOS/OS X on Non-Apple computers and is capable of booting a variety of other Operating Systems including Windows and Linux. OpenCore differs a lot from Clover and has been designed with security and quality, allowing us to use many security features found on real Macs such as System Integrity Protection and FileVault. Moreover, configuring an OpenCore EFI (used for booting) is way less complex than Clover and provides much more modern functionality than Clover. Although, still lacks some of the great features which are implemented in Clover such as on-the-fly hot patching. However, there are more advantages to using OpenCore due to its easy-to-configure in nature and regular updates. More in-depth information can be found in Why you should use OpenCore over Clover and other Bootloaders.

For users who are not familiar with OpenCore or if they haven't used it before, this guide may seem a bit complex to them, but it is quite simple if you read and go through the steps carefully. Those users who are familiar with OpenCore or have used it before will find this guide relatively easy to follow than any other guide!

Can I skip this guide and use the OpenCore EFI from somewhere else?​

The purpose of this guide is to show how to create a macOS Bootable USB and create OpenCore EFI which can be used to install macOS on a target Chromebook, Chromebase, and Chromebox. Where creating EFI is the main essence of the guide as that's what most people are looking for. It is strongly advised to create a configuration (OpenCore EFI) from scratch without the involvement of someone's else configuration and files and this is where this guide comes into place.

Using OpenCore EFI from another system or picking from the Internet (mostly from Github or other forums) is relatively easier than creating on your own, but will not result in many benefits due to the difference in the hardware and the vendor. Although it may be capable of booting macOS on a target system, these pre-made EFIs not only come with a lot of unnecessary and irrelevant SSDTs, Kexts, Quirks, and settings but sometimes also include custom branding and are usually way lot cluttered than the vanilla method and are generally not reliable (missing hardware functionality and/or features or even random freezes, crashes, etc.) which is not the preferred choice. Often, it becomes difficult to inject patches, Device Properties, and Quirks due to being prevented from being injected which is one of the reasons why most of the vanilla guides and/or post-install steps generally don't work with such EFIs. Everything is injected forcibly to ensure the macOS installer boots anyhow on the target system, which still fails in several cases.

Moreover, just because the random EFI you use boots on a target device, it does not necessarily mean every hardware component and the related functions are performing as expected. There could be known performance-related issues i.e. getting less performance than the system is actually capable of or it may not perform well on your system in general (even if it is working for the primary user). In addition, despite having the same hardware configuration, there are chances that your system may require some additional configuration than the EFI you're using to boot. Most of the users just want to boot the macOS installer on their systems, without getting to know the basics involved which is the key and this is why it makes it more difficult to troubleshoot if such configuration fails to boot the macOS installer on the target system and such users don't have clue where the problem is coming from.

Just to avoid reading and investing time into building a proper EFI, several users use the EFI of someone else. This is a very common practice often followed by new users building their OpenCore EFI and this is why such users run into different issues and invest their time effortlessly to fix the junk. Rather than investing time in troubleshooting the installation and fixing someone's else EFI configuration, which is not even intended for your particular system, it would make more sense to create your own OpenCore EFI and move in the right direction in the first place. Using someone's EFI not only makes it difficult to boot the macOS installer, but it invites way more issues than it could have originally. A lot of problems can be eliminated just by following the guide precisely.

Due to all these reasons, using OpenCore EFI from some other computer or user is never advised and such practice is highly discouraged, especially on this forum. If you don't follow the guide carefully, after a point of time, you will end up frustrated if you lack time and patience. Of course, it's your computer and you have the right to decide whether to install macOS for your use case or not.

macOS Support Table

As of now, the Hyper-V supports the installation of macOS to macOS Sonoma.

macOS version	Status	Minimum Version	Maximum Version
macOS Sonoma
macOS Ventura
macOS Monterey
macOS Big Sur
macOS Catalina
macOS Mojave
macOS High Sierra
macOS Sierra

Current Status​

Although different models can have different specs and the hardware component/model can differ from manufacturer to manufacturer, here is a list of the current status in terms of functions under macOS.

Hardware/Function	Status	Notes
Brightness Control	Working, including the Brightness Hotkeys
USB Ports	Working
Keyboard	Working
Keyboard Backlight	Working
Trackpad	Working
Touchscreen	Working
Camera	Working
Card Reader	Not working	Intel Card Readers are simply not supported
Battery	Working
Ethernet	Working
WiFi/BT	Working	Realtek and MediaTek Chipsets are not supported
Audio	Working
HDMI	Working
Power Management	Working
Shutdown/Reboot	Working
Sleep/Wake	Working
iServices	Working

In addition, this guide does not discuss existing VHDX or anything similar but a clean install.



This guide will be specifically focused for Windows users assuming that the user has only access to the target machine with Windows installed. In addition, this guide will focus on installing macOS Monterey and later using the Online (Recovery Method) for the ease of this guide.

Requirements​

Following are the requirements for installing macOS on Hyper-V. Please ensure you meet the requirements before proceeding with this guide.

CPU	Intel CPU. AMD CPUs are not supported at the moment. 4 Core or more. 6 or more is recommended. Haswell and later is recommended. macOS Compatible CPU. See Chromebook and Chromebox Compatibility for more information.
Memory	16GB or more
Storage	50GB of free space on the Windows Drive or a separate drive with 128GB or more capacity. A separate Drive is usually recommended.
Operating System	Windows 8.1 or newer. Windows 11 is recommended. Windows Server 2012 R2 or newer. Windows Server 2022 or newer is recommended. Windows Server 2016 and prior is currently unsupported. Windows 10/11 Home Edition is not supported and Hyper-V cannot be installed on such editions. You can upgrade from Windows 10/11 Home Edition to Windows 10/11 Pro/Enterprise from Settings > Update and Security > Activation.
Tools	OCAT or any equivalent .plist editor

As Hyper-V runs on Windows, this guide will be especially focused on Windows for creating the Bootable USB.

CHAPTER 2: Creating macOS/OS X Bootable USB

If you determine that your hardware is compatible according to the above-provided compatibility lists, you can start your journey by creating a Bootable USB for your target computer.

I. Requirements

• Access to a computer with Windows installed (Online Method).
• Internet connection to download the required files.

STEP 1: Downloading macOS
Using this method, you can download from OS X Lion 10.7 to macOS Ventura 13.4. However, these are the recovery image and therefore requires an internet connection to download the full installer during the time of installation. You'll need to have the exact Recovery image of the target OS you want to install. To download the recovery image, follow the steps below.

1. Install the latest Python from the Microsoft Store.
2. Download OpenCore Pkg from the downloads section of this forum.
3. Extract the downloaded file to your Desktop.
4. Move into the OpenCore-0.X.X-RELEASE/Utilities directory
5. Right-click on macrecovery folder and select Copy as path.

6. Open Command Prompt with Administrator Privileges

7. Type cd and then paste the path you copied earlier in step 5 and then press enter key. The command would be the following

Bash:
cd "C:\Users\Your User Name\Desktop\OpenCore-0.X.X-RELEASE\Utiities\macrecovery"

NOTE: Replace the X with the OpenCore version. Replace Your User Name with your actual username

8. Depending on the macOS version you need (See Recovery Table below), execute the commands. When prompted, enter your password.

Recovery Table

OS Version	Command
OS X Lion	./macrecovery.py -b Mac-C3EC7CD22292981F -m 00000000000F0HM00 download
OS X Mountain Lion	./macrecovery.py -b Mac-7DF2A3B5E5D671ED -m 00000000000F65100 download
OS X Mavericks	./macrecovery.py -b Mac-F60DEB81FF30ACF6 -m 00000000000FNN100 download
OS X Yosemite	./macrecovery.py -b Mac-E43C1C25D4880AD6 -m 00000000000GDVW00 download
OS X El Capitan	./macrecovery.py -b Mac-FFE5EF870D7BA81A -m 00000000000GQRX00 download
macOS Sierra	./macrecovery.py -b Mac-77F17D7DA9285301 -m 00000000000J0DX00 download
macOS High Sierra	./macrecovery.py -b Mac-7BA5B2D9E42DDD94 -m 00000000000J80300 download
macOS Mojave	./macrecovery.py -b Mac-7BA5B2DFE22DDD8C -m 00000000000KXPG00 download
macOS Catalina	./macrecovery.py -b Mac-CFF7D910A743CAAF -m 00000000000PHCD00 download
macOS Big Sur	./macrecovery.py -b Mac-E43C1C25D4880AD6 -m 00000000000000000 download
Latest Version	./macrecovery.py -b Mac-E43C1C25D4880AD6 -m 00000000000000000 -os latest download

The script will start downloading the required recovery files:

9. Once the download is completed, you'll see something like below:

This will create a com.apple.recovery.boot directory inside OpenCore-0.X.X-RELEASE/Utilities/macrecovery directory.

You can find BaseSystem.dmg and BaseSystem.chunklist in OpenCore-0.X.X-RELEASE/Utilities/macrecovery/com.apple.recovery.boot directory.

NOTE: Depending on the macOS version, the script will either download BaseSystem or RecoveryImage files.

Converting DMG/ Create Bootable Disk​

As BaseSystem.dmg cannot be read directly by Hyper-V, you need to convert the image from DMG to a suitable format which can be recognized by Hyper-V (such as .VHDX). Using QEMU, you can easily convert the BaseSystem.dmg to a readable format. QEMU supports multiple formats including KVM, RAW, VDI, VHD, and VMDK.

This step will eliminate the requirement of an additional virtual USB (Hyper-V) and a physical USB (VMware Workstation) along with Transmac and other complicated and lengthy steps. In addition, this will also make the booting faster, reducing the boot times due to the latency. However, if you want to go with that route you can skip this step if you're interested in knowing other ways.

1. Download and install QEMU. You can just select the Tools and DLL Library when you run the installer and that would be enough for converting the DMG.
2. Navigate to OpenCore-0.X.X-RELEASE/Utilities/macrecovery/com.apple.recovery.boot directory.
3. Within the directory, right-click and select Open in CommandPrompt from the context menu.
4. Now execute the following command in the Command Prompt:
c:\"Program Files"\qemu\qemu-img convert -f raw -O vhdx BaseSystem.dmg Recovery.vhdx
Now, the qemu-img will convert the BaseSystem.dmg to Recovery.vhdx which can be used as an existing disk in Hyper-V.
Once the conversion is completed, you'll find a Recovery.vhdx file in the same directory.

CHAPTER 3: Preparing OpenCore EFI​

To prepare the OpenCore EFI, you'll need to download OpenCorePkg. Follow the steps below to prepare OpenCore EFI for Hyper-V.

Requirements​

• OpenCore Package
• OCAuxiliary Tool

1. Download OpenCore Pkg. The OpenCore Pkg comes in two variants DEBUG and RELEASE.

Version	Notes
DEBUG	Helps in debugging boot issues Can add some delay in boot times Recommended for debugging purposes.
RELEASE	Not much help for debugging boot issues. Troubleshooting is difficult Recommended for production use.

2. Download the RELEASE version.
3. Extract the zip. When extracting, you'll get 4 directories as listed below.

Directories	Description
Docs	Contains documentation, changelog, sample config.plist, and ACPI samples for OpenCore.
IA32	Contains OpenCore EFI, 32-bit OpenCore Boot Loader. Required for OS X 10.4.1 through 10.4.7
Utilities	Contains several utilities.
X64	Contains OpenCore EFI, 64-bit OpenCore Boot Loader. Required for OS X 10.8 and newer

1. Copy the EFI folder from X64 to your working directory and you should have the following structure:

EFI
├── BOOT
│   └── BOOTx64.efi
└── OC
    ├── ACPI
    ├── Drivers
    │   ├── AudioDxe.efi
    │   ├── BIOSVideo.efi
    │   ├── CrScreenshotDxe.efi
    │   ├── HiiDatabase.efi
    │   ├── NvmExpressDxe.efi
    │   ├── OpenCanopy.efi
    │   ├── OpenHfsPlus.efi
    │   ├── OpenLinuxBoot.efi
    │   ├── OpenPartitionDxe.efi
    │   ├── OpenRuntime.efi
    │   ├── OpenUsbKbDxe.efi
    │   ├── Ps2KeyboardDxe.efi
    │   ├── Ps2MouseDxe.efi
    │   ├── ResetNvramEntry.efi
    │   ├── ToggleSipEntry.efi
    │   ├── UsbMouseDxe.efi
    │   └── XhciDxe.efi
    ├── Kexts
    ├── Resources
    │   ├── Audio
    │   ├── Font
    │   ├── Image
    │   └── Label
    ├── Tools
    │   ├── BootKicker.efi
    │   ├── ChipTune.efi
    │   ├── CleanNvram.efi
    │   ├── ControlMsrE2.efi
    │   ├── CsrUtil.efi
    │   ├── GopStop.efi
    │   ├── KeyTester.efi
    │   ├── MmapDump.efi
    │   ├── OpenControl.efi
    │   ├── OpenShell.efi
    │   ├── ResetSystem.efi
    │   ├── RtcRw.efi
    │   └── TpmInfo.efi
    └── OpenCore.efi

Directory Structure

Directories and Files	Notes
BOOT/ Bootx64.efi	Initial bootstrap loaders, which load OpenCore.efi. BOOTx64.efi is loaded by the firmware by default consistent with the UEFI specification. However, it may also be renamed and put in a custom location to allow OpenCore to coexist alongside operating systems, such as Windows, that use BOOTx64.efi files as their loaders.
ACPI	Directory for storing ACPI Files (DSDT and SSDTs) Only keep files with the .aml extension
Drivers	Directory for storing drivers (UEFI and Legacy) Only keep files with the .efi extension
Kexts	Directory for storing Kernel Extensions aka Drivers Only keep files with the .kext extension
Resources	Directory for storing media resources such as Audio and GUI, including fonts, icons, and images for Boot Picker for use by OpenCanopy.
Tools	Directory for storing tools Only keep files with the .efi extension
OpenCore.efi	The main booter application responsible for loading the operating system. The directory OpenCore.efi resides in is called the root directory, which is set to EFI\OC by default. When launching OpenCore.efi directly or through a custom launcher, however, other directories containing OpenCore.efi files are also supported.

Cleaning Up

By default, OpenCore includes numerous Drivers, Resources, and Tools for several purposes and all of them may not be required on Hyper-V. Therefore, a clean-up is required to ensure there is no clutter which makes troubleshooting difficult, and also to reduce the file size of the EFI. Follow the steps below to perform a cleanup.

I. Drivers
Drivers are essentials that allow several important functions and are required to boot the system, including Recovery mode. By default, OpenCore includes numerous drivers for different purposes. You need to use the drivers required by your system. For Hyper-V, only keep the required drivers as instructed below and delete the rest of the drivers (where applicable) from the EFI/OC/Drivers directory. You can find all the unlinked drivers in the EFI/OC/Drivers directory.

Drivers	Required	Notes
OpenRuntime.efi	YES	Runtime driver including several other drivers merged such as ApfsDriverLoader. OpenRuntime.efi is a replacement for AptioMemoryFix.efi driver. Required for booting and proper functioning of OpenCore
OpenCanopy.efi	Optional	Provides GUI functionality for OpenCore Boot screen. This driver is required if you need GUI for OpenCore. See Enabling GUI for more information.
ResetNvramEntry.efi	YES	Provides Reset NVRAM support. Required since OpenCore 0.8.1 and later See Resetting NVRAM for more information.

NOTES:

• OpenCore and Drivers should be from the same RELEASE version and should not mismatch.
• UEFI Drivers from Clover are not supported with OpenCore. See Switching Clover to OpenCore if you're using Clover and want to switch to OpenCore.

The resulting Drivers directory should look something like this:

picture here


II. Tools
Tools are of great use but are for specific purposes only and most of them are optional. Although, it will not harm even if you keep these tools. However, to reduce the size and have less clutter, it is advised to delete the tools which you don't need. For debugging and later use, it is recommended to keep these tools. You can either keep them or delete them as per your personal preferences. These standalone tools help to debug the firmware and hardware.

Tool Name	Required	Notes
BootKicker.efi	Optional	Enter Apple BootPicker menu (exclusive for Macs with compatible GPUs).
ChipTune.efi	Optional	Test BeepGen protocol and generate audio signals of different styles and lengths.
CleanNvram.efi	Optional	Reset NVRAM alternative bundled as a standalone tool.
ControlMsrE2.efi	Optional	Check CFG Lock (MSR 0xE2 write protection) consistency across all cores and change such hidden options on selected platforms.
CsrUtil.efi	Optional	Simple implementation of SIP-related features of Apple csrutil.
GopStop.efi	Optional	Test GraphicsOutput protocol with a simple scenario.
KeyTester.efi	Optional	Test keyboard input in SimpleText mode.
MmapDump.efi	Optional
OpenControl.efi	Optional	Unlock and lock back NVRAM protection for other tools to be able to get full NVRAM access when launching from OpenCore.
OpenShell.efi	Optional	Used for debugging Required for mapping entries for Dual Boot
ResetSystem.efi	Optional	Utility to perform system reset. Takes reset type as an argument: cold reset, firmware, shutdown, warm reset. Defaults to cold reset.
RtcRw.efi	Optional	Utility to read and write RTC (CMOS) memory.
TpmInfo.efi	Optional	Check Intel PTT (Platform Trust Technology) capability on the platform, which allows using fTPM 2.0 if enabled. The tool does not check whether fTPM 2.0 is actually enabled.

A cleaned-up EFI should be like the following:

For UEFI based Systems​

EFI
├── BOOT
│   └── BOOTx64.efi
└── OC
    ├── ACPI
    ├── Drivers
    │   ├── OpenRuntime.efi
    │   ├── OpenHfsPlus.efi
    │   ├── OpenCanopy.efi
    │   ├── AudioDxe.efi
    │   └── ResetNvramEntry.efi
    ├── Kexts
    ├── Resources
    │   ├── Audio
    │   ├── Font
    │   ├── Image
    │   └── Label
    ├── Tools
    │   ├── BootKicker.efi
    │   ├── ChipTune.efi
    │   ├── CleanNvram.efi
    │   ├── ControlMsrE2.efi
    │   ├── CsrUtil.efi
    │   ├── GopStop.efi
    │   ├── KeyTester.efi
    │   ├── MmapDump.efi
    │   ├── OpenControl.efi
    │   ├── OpenShell.efi
    │   ├── ResetSystem.efi
    │   ├── RtcRw.efi
    │   └── TpmInfo.efi
    └── OpenCore.efi

The resulting cleaned up EFI should look something like this:

STEP 4: Gathering Files​

Once you have the base OpenCore EFI containing the necessary boot files, you will need to add essential SSDTs, Drivers, and Kexts for booting macOS. As this step would require the system specification of the target machine, we assume that you're already aware of the specification. If you still aren't aware, see Gathering System Details for more information.

I. ACPI (SSDTs)
In order to boot into the installation, you need to add the necessary SSDTs. A majority of ACPI (SSDTs) are already included in the OpenCore Package. These ACPI (SSDTs) also must be linked in the config.plist which you'll get to know in Chapter 4 of this guide. Follow the steps below to place the necessary ACPI (SSDTs).

STEP 1: Depending on the Host OS you have, copy the SSDTs from OpenCore/RELEASE/Docs/AcpiSamples/Binaries to the EFI/OC/ACPI directory.

QUICK INFO:
SSDT marked with * are bundled with OpenCore. Additional SSDTs described here can be downloaded from the SSDTs Download section.

SSDT Name	Notes
SSDT-HV-DEV.aml*	Enables proper CPU detection under macOS. Disables incompatible virtual devices under macOS. Required on Windows Server 2019/Windows 10 and newer. Required for Hyper-V only. Not needed on Windows Server 2012 R2/Windows 8.1 and prior. Do not use it on a bare metal.
SSDT-HV-DEV-WS2022.aml*	Disables unsupported virtual devices under macOS. Required on Windows Server 2022/Windows 11 and newer. Required for Hyper-V only. Not needed on Windows Server 2019 and prior. Do not use it on a bare metal.
SSDT-HV-VMBUS.aml*	Enables ACPI node identification and correct Startup Disk operation. Required for Hyper-V only. Do not use it on a bare metal.
SSDT-HV-PLUG.aml*	Enables VMplatformPlugin loading on Big Sur and newer. Fixes freeze with the default PlatformPlugin. Required for Hyper-V only. This SSDT must be loaded after SSDT-HV-CPU.aml. Do not use it on a bare metal.

II. Drivers​

Unlike the SSDTs, the drivers are one of the essential elements in OpenCore EFI and are mainly required for booting macOS on the target machine for either UEFI or a Legacy environment.
Depending on the firmware, a different set of drivers may be required. Loading an incompatible driver may lead the system to an unbootable state or even cause permanent firmware damage. There are drivers which provide the ability to scan different formats of drives in the OpenCore picker (such as HFS+ Drives). These drivers also must be linked in the config.plist which you'll get to know in Chapter 4 of this guide. Follow the steps below to place the necessary Drivers.

STEP 1: Download OcBinaryData
STEP 2: Extract the downloaded .zip file.
STEP 3: Copy the appropriate drivers from OCBinaryData/Drivers to EFI/OC/Drivers directory.

Although OpenCorePkg contains the necessary drivers to boot the macOS installer on the target machine, there is an OpenHFSPlus.efi driver which is generally slow as compared to HFSPlus.efi proprietary driver. Therefore, it is advised to use HFSPlus.efi instead of OpenHFSPlus.efi to avoid unnecessary delays. The HFSPlus.efi driver comes in different flavors and must be used accordingly. You can find which version to use below.

Driver Name	Required	Notes
HfsPlus.efi	YES	HFS File System Driver with bless support. Provides reading of HFS+ Volumes/drives in OpenCore Boot Picker. Without HFSPlus.efi driver, you won't be able to see any HFS+ volumes including your macOS USB Installer. Recovery and installation drive for macOS Sierra and prior in OpenCore Boot Picker. This driver is an alternative to a closed source HfsPlus driver commonly found in Apple firmware.

III. Kexts
Unlike drivers for other OSes, a Kext (Kernel Extension) is a driver for macOS. In order to boot into the installation, you need to add the necessary kexts. Follow the steps below to place the necessary kexts.

STEP 1: Download the required kexts.
STEP 2: Extract the kexts from the RELEASE folder.
STEP 3: Copy the required kexts with .kext extension to EFI/OC/Kexts directory.

Lilu

• Provides arbitrary patching.
• Required for AppleALC, WhateverGreen, VirtualSMC and several other kexts.

VirtualSMC

• SMC Emulator. Emulates Apple hardware.
• VirtualSMC is a successor of FakeSMC.
• This kext requires Lilu.kext to function.

MacHyperVSupport

• Core Hyper-V support kext
• Required for macOS Mojave (10.14.x) to macOS Big Sur (11.x)

MacHyperVSupportMonterey

• Core Hyper-V support kext
• Required for macOS Monterey (12.x)

NOTES: Do not download the project files. The pre-built binaries/downloads are available in the README.md section. Make sure you read it carefully. Download the latest version for better support. Use the Kexts from the RELEASE folder and the RELEASE.zip file. Only copy the files with the .kext Extension. Do not copy the .dsYM file from the RELEASE folder. They're only for debugging purposes. Do not place unnecessary kexts here. It might prevent booting the installer. The VirtualSMC package includes Battery and Sensors plugins (SMCBatteryManager.kext, SMCDellSensors.kext, SMCLightSensor.kext, SMCProcessor.kext, and SMCSuperIO.kext). You do not need these kexts for booting the installer.

Here's what your EFI somewhat look like:

Now that you have obtained the OpenCore Base EFI and gathered SSDTs (.aml), Drivers (.efi) and Kexts (.kext), the resulting EFI folder in your working directory should look something like this:

CHAPTER 5: Setting up config.plist​

Now, that you have things in order, the next step is to set up config.plist. It is highly recommended to create your own config.plist for maximum reliability. Copying from somewhere else isn't a good idea. You can obtain a sample.plist which is bundled with OpenCore pkg and this sample.plist will be used as a base for setting up config.plist.

I. Obtaining Sample config.plist

1. As you already have downloaded OpenCore Pkg, simply copy sample.plist from OpenCore/RELEASE/Docs to the EFI/OC working directory and rename it to config.plist. The directory structure for OpenCore Pkg has been provided below:

Docs
├── AcpiSamples
│   ├── Binaries
│   └── Source
├── Changelog.md
├── configuration.pdf
├── Differences.pdf
├── Sample.plist
└── SampleCustom.plist

IMPORTANT: To avoid any conflicts and outdated settings, OpenCore and sample.plist should be from the same RELEASE version and should not mismatch


Now, as we have setup OpenCore and the required SSDTs (.aml), Drivers (.efi), Kexts (.kext) and config (.plist), the resulting EFI folder in your working directory should look something like this:

EFI
├── BOOT
│   └── BOOTx64.efi
└── OC
    ├── ACPI
    │   ├── SSDT-AWAC-DISABLE.aml
    │   ├── SSDT-EC-USBX.aml
    │   └── SSDT-PLUG.aml
    ├── Drivers
    │   ├── OpenRuntime.efi
    │   ├── OpenHfsPlus.efi
    │   └── ResetNvramEntry.efi
    ├── Kexts
    │   ├── Lilu.kext
    │   ├── VirtualSMC.kext
    │   ├── WhateverGreen.kext
    │   ├── AppleALC.kext
    │   ├── USBInjectAll.kext
    │   └── RealtekRTL8111.kext
    ├── Resources
    ├── Tools
    │   ├── BootKicker.efi
    │   ├── ChipTune.efi
    │   ├── CleanNvram.efi
    │   ├── ControlMsrE2.efi
    │   ├── CsrUtil.efi
    │   ├── GopStop.efi
    │   ├── KeyTester.efi
    │   ├── MmapDump.efi
    │   ├── OpenControl.efi
    │   ├── OpenShell.efi
    │   ├── ResetSystem.efi
    │   ├── RtcRw.efi
    │   └── TpmInfo.efi
    ├── config.plist
    └── OpenCore.efi

NOTE: Your EFI might differ as each system is different and will have different requirements.

II. Cleaning up config.plist​

Now before you start working with your config.plist, it is highly recommended to clean up the config.plist to have the required settings only. A basic clean-up is required as by default, OpenCore includes numerous settings, for several purposes and all of them may not be required by a particular system. You need to use the settings required by your system and remove all irrelevant entries and settings from your config.plist. Although, most of such settings are already off, but do exist. Keeping such settings will not harm but to reduce the size and have less clutter, it is strongly advised to delete the irrelevant settings which you don't need.

Starting from this step, you'll need to use a tool to edit the config.plist and we'll use OC Auxiliary Tools to edit the config.plist and configure it accordingly. With OC Auxiliary Tools, you have the advantage of Cross-Platform i.e. you can use the tool on Windows, Mac, and Linux. To edit your OpenCore config.plist using OC Auxiliary Tools, follow the steps below.

1. Download OC Auxiliary Tools from the downloads section of this forum.

For macOS
Mount the .DMG file by openening the .dmg file
Move the OCAuxiliaryTools to your Applications folder
Open OCAuxiliaryTools.app to launch the Application

For Windows
Extract the zip and you'll get the OCAT-Win64 folder
Use OCAuxiliaryTools.exe to launch the Application

For Linux

Update OC Auxiliary Tools
Perform an upgrade check for the OC Auxiliary Tools App using Help>Download Upgrade Packages. If there's any available package for an upgrade, it will download it. Once it finishes downloading, click on Close and start upgrade and the App will upgrade to its latest version. After the upgrade, when the App reopens, check for an update using Help> Update Check. If you're using the latest version, you'll see the following

Note that you don't need to follow this step if you have downloaded the latest OC Auxiliary Tools.

Update OpenCore Package
Now, click on the Sync icon Upgrade OpenCore and Kexts icon and you'll see something similar to the following
Select the Latest Version from the Choose OpenCore Version option.
Click on Get OpenCore and it will update the OpenCore Database.
Once the OpenCore Database is updated, you'll see the following

Open your config.plist using OC Auxiliary Tools from EFI/OC directory.

ACPI

---

Add

1. Select all the ACPI entries using Command+A or CTRL+A on your Keyboard.

2. Click on the delete button to remove all the entries and you should have all the entries removed.

Delete

1. Move to the Delete Tab and select all the entries using Command+A or CTRL+A on your Keyboard

2. Click on the delete button to remove all the entries and you should have all the entries removed.

Patch

1. Move to Patch Tab and select all the entries using Command+A or CTRL+A on your Keyboard

2. Click on the delete button to remove all the entries and you should have all the entries removed.

Quirks
Remove ResetLogoStatus

Booter

---

MmioWhitelist

1. Select all the entries using Command+A or CTRL+A on your Keyboard

2. Click on the delete button to remove all the entries and you should have all the entries removed.

Patch

1. Move to Patch Tab and select all the entries using Command+A or CTRL+A on your Keyboard

2. Click on the delete button to remove all the entries and you should have all the entries removed.

DP (Device Properties)

---

Add

1. Select all the Device entries using Command+A or CTRL+A on your Keyboard

2. Click on the delete button to remove all the entries and you should have all the entries removed.

Kernel

---

Add

1. Select all the Kext entries using Command+A or CTRL+A on your Keyboard

2. Click on the delete button to remove all the entries and you should have all the entries removed.

Block

1. Move to Patch Tab and select all the entries using Command+A or CTRL+A on your Keyboard

2. Click on the delete button to remove all the entries and you should have all the entries removed.

Force

1. Move to Patch Tab and select all the entries using Command+A or CTRL+A on your Keyboard

2. Click on the delete button to remove all the entries and you should have all the entries removed.

Patch

1. Move to Patch Tab and select all the entries using Command+A or CTRL+A on your Keyboard

2. Click on the delete button to remove all the entries and you should have all the entries removed.

Misc

---

Entries

1. Select all the Boot entries using Command+A or CTRL+A on your Keyboard

2. Click on the delete button to remove all the entries and you should have all the entries removed.

Tools

1. Move to Tools Tab and select all the Tools entries using Command+A or CTRL+A on your Keyboard

2. Click on the delete button to remove all the entries and you should have all the entries removed.

NVRAM

---

Add

1. Select the UUID 7C436110-AB2A-4BBB-A880-FE41995C9F82

2. From the right pane, select the entry shown and click on the delete button to remove the key and you should have the key entry removed.

3. From the right pane, select the value for the Key prev-lang:kbd and click on the Delete button to delete the value.

UEFI

---

Drivers

1. Select all the Drivers entries using Command+A or CTRL+A on your Keyboard

2. Click on the delete button to remove all the entries and you should have all the entries removed.

ReservedMemory

1. Move to Patch Tab and select all the entries using Command+A or CTRL+A on your Keyboard

2. Click on the delete button to remove all the entries and you should have all the entries removed.

Finally, Save your config.plist using the Menu File>Save option

III. Adding SSDTs, Kexts and Drivers in config.plist

---

Now, as we have got a cleaned-up config.plist, we can start adding the SSDTs (.aml), Kexts (.kext) and Drivers (.efi) to our config.plist. Unlike Clover, OpenCore requires the entries of the particular SSDTs, Kexts and Drivers in the appropriate section of the config.plist which are present in their respective directories. This linking step is necessary as OpenCore requires the entries to be present in the config.plist and without them, OpenCore will simply not boot to the target OS. To add the SSDTs, Kexts and Drivers, follow the steps below.

1. Open your config.plist using OC Auxiliary Tools from EFI/OC directory.

SSDTs

1. In the Add Tab, click on Add button and select all the .aml files from EFI/OC/ACPI directory and you should have all the .aml files entries added.

NOTES: The .aml files must exist in EFI/OC/ACPI directory As the ACPI loading order is important for OpenCore, it is advised to load the SSDTs in sorted order. This means all the necessary SSDTs should be loaded first and dependencies SSDTs should load later to avoid issues. Your entries might differ as each system is different and will have different requirements.

Kexts

1. In the Add tab, click on Add button and select all the .kext files from EFI/OC/Kexts directory and you should have all the .kext files entries added.

2. Arrange the kexts using arrow buttons. < button for up and > for down

NOTE: The .kext files must exist in EFI/OC/Kexts directory As the kext loading order is important for OpenCore, it is advised to load the kexts in sorted order. This means all the necessary kexts should be loaded first and dependencies kexts should load later to avoid issues. Your entries might differ as each system is different and will have different requirements.

Drivers

1. In the Drivers tab, click on Add button and select all the .efi files from EFI/OC/Drivers directory and you should have all the .efi files entries added.

2. Arrange the drivers using arrow buttons. < button for up and > for down

NOTES:

• The .efi files must exist in EFI/OC/Drivers directory
• As the driver loading order is important for OpenCore, it is advised to load the drivers in sorted order. This means all the necessary drivers should be loaded first.
• Your entries might differ as each system is different and will have different requirements.
• The config.plist must match the SSDTs, Kexts, and Drivers in the respective directories of the EFI folder. If you tend to delete a file in these directories and the entries are left linked in the config.plist, OpenCore will halt and will not boot further.

2. Finally, Save your config.plist using the Menu File>Save option.

IV. Editing config.plist for Hyper-V​

The main aspects of the config.plist have been already explained in the config.plist creation guide, it will include the relevant sections only. The properties which have not been discussed will remain as default as in the original sample.plist after cleaning (explained in section VU of this guide). In short, this will be a summary of the necessary SSDTs, Booter and Kernel Quirks, Drivers, patches, and defining additional parameters (wherever necessary). In addition, this summary assumes you have already followed the OpenCore Installation Guide. Please note that you might find this summary difficult to follow if you have not followed the OpenCore Installation Guide which involves the preparation.

WARNING: Read this guide carefully and make sure you have set it up correctly. The necessary files for the respective entries in the config.plist must exist in their respective directories. If an entry is added for a file in the config.plist but does not exist in the respective directory, OpenCore will halt and will not boot further.

ACPI​

---

This section is for loading, blocking, and patching the ACPI tables. The necessary sections are explained below.

Add​

This section is for adding the DSDT and SSDT files for your system which will allow booting macOS. This can include the mandatory SSDTs from the OpenCore package as well as any add-on SSDTs for specific purposes such as USB and Thunderbolt. Link the same SSDTs as in the EFI/OC/ACPI directory.

The required SSDTs for Hyper-V include:

SSDT	Required	Notes
SSDT-HV-DEV.aml*	YES	Enables proper CPU detection under macOS. Disables incompatible virtual devices under macOS. Required on Windows Server 2019/Windows 10 and newer. Required for Hyper-V only. Not needed on Windows Server 2012 R2/Windows 8.1 and prior. Do not use it on a bare metal.
SSDT-HV-DEV-WS2022.aml*	YES	Disables unsupported virtual devices under macOS. Required on Windows Server 2022/Windows 11 and newer. Required for Hyper-V only. Not needed on Windows Server 2019 and prior. Do not use it on a bare metal.
SSDT-HV-VMBUS.aml*	YES	Enables ACPI node identification and correct Startup Disk operation. Required for Hyper-V only. Do not use it on a bare metal.
SSDT-HV-PLUG.aml*	YES	Enables VMplatformPlugin loading on Big Sur and newer. Fixes freeze with the default PlatformPlugin. Required for Hyper-V only. This SSDT must be loaded after SSDT-HV-CPU.aml. Do not use it on a bare metal.

QUICK INFO:

• The ACPI table loading depends on the order of the items in the list. Therefore, the mandatory SSDTs should always load first. The loading order should be the same in your config.plist as shown in the above table.
• ACPI Tables defined here must exist in the EFI/OC/ACPI directory.
• Do not add anything extra ACPI files such as DSDT.aml. If any other SSDTs are present other than the above list, remove all such entries.

Delete​

This section allows blocking the ACPI tables from loading. This section requires no modification and will remain untouched for Hyper-V.

Patch​

This section is used for device renames such as USB, Graphics, and Audio. You can implement the necessary ACPI patches for optimizing the ACPI system components with DSDT and SSDT. This section is important when doing Hot-patch.

The required renames for Hyper-V include:

Base	TableSignature	TableLength	Find	Replace	Comment	Count	Enabled	Notes
\_SB.VMOD	DSDT	0	5F484944	58484944	_HID to XHID rename (Hyper-V VMOD)	1	YES	Renames EHC1 to EH01 for proper USB functioning. This rename is required for fixing USB Ports with EHCI Controller. Required for GIGABYTE and ASUS 500, 600, and 700 series Motherboards.
\_SB.VMOD.VMBS	DSDT	0	5F484944	58484944	_HID to XHID rename (Hyper-V VMOD)	1	YES	Renames ADBG to XDBG in the GSWApp SSDT Fixes Reboot after the second wake-from-sleep stage. Fixes AE_ALREADY_EXISTS error in the ACPI namespace Required for GIGABYTE 500, 600, and 700 series Motherboards.
\_SB.VMOD.TPM2	DSDT	0	5F535441	58535441	_STA to XSTA rename (Hyper-V TPM)	1	YES
\_SB.NVDR	DSDT	0	5F535441	58535441	_STA to XSTA rename (Hyper-V NVDIMM)	1	YES
\_SB.EPC	DSDT	0	5F535441	58535441	_STA to XSTA rename (Hyper-V EPC)	1	YES
\_SB.VMOD.BAT1	DSDT	0	5F535441	58535441	_STA to XSTA rename (Hyper-V battery)	1	YES
\P001	DSDT	0	5F535441	58535441	_STA to XSTA rename (Hyper-V processors)	240	YES
\P241	DSDT	0	5F535441	58535441	_STA to XSTA rename (additional Hyper-V processors)	1808	YES

Quirks​

This section allows to apply certain ACPI Quirks. This section requires no modification and will remain untouched for Hyper-V.

Booter​

---

This section is used for booting and provides firmware fixes in relation to boot.efi. The necessary sections are explained below.

MmioWhitelist​

Designed to be filled with plist dict values, describing addresses critical for particular firmware functioning when DevirtualiseMmio quirk is in use. This section requires no modification and will remain untouched for Hyper-V.

Patch​

Performs binary patching in booter. To be filled with plist dictionary values, describing each patch. This section requires no modification and will remain untouched for Hyper-V.

Quirks​

This section allows to apply certain Booter quirks.

The required Booter Quirks for Hyper-V include:

Quirks	Value	Notes
AllowRelocationBlock	Optional	Allows booting macOS through a relocation block. The relocation block is a scratch buffer allocated in the lower 4 GB used for loading the kernel and related structures by EfiBoot on firmware where the lower memory region is otherwise occupied by (assumed) non-runtime data. Right before kernel startup, the relocation block is copied back to lower addresses. Similarly, all the other addresses pointing to the relocation block are also carefully adjusted. The relocation block can be used when: No better slide exists (all the memory is used) slide=0 is forced (by an argument or safe mode) KASLR (slide) is unsupported (this is macOS 10.7 or older) This quirk requires ProvideCustomSlide to be enabled and typically also requires enabling AvoidRuntimeDefrag Quirk to function correctly. Hibernation is not supported when booting with a relocation block, which will only be used if required when the quirk is enabled. While this quirk is required to run older macOS versions on platforms with used lower memory, it is not compatible with some hardware and macOS 11. In such cases, consider using EnableSafeModeSlide Quirk instead. Required for OS X (10.7.x) and prior
AvoidRunTimeDefrag	YES	Protect from boot.efi runtime memory defragmentation Fixes certain UEFI runtime services such as date time, NVRAM, power control, etc. Apart from Apple and VMware, this quirk is required by the rest of the firmware Required for every platform including Hyper-V.
ForceExitBootServices	Optional	Retry ExitBootServices with a new memory map on failure. Try to ensure that the ExitBootServices call succeeds. If required, an outdated MemoryMap key argument can be used by obtaining the current memory map and retrying the ExitBootServices call. The need for this quirk is determined by early boot crashes of the firmware. Do not use this option without a full understanding of the implications. Required for OS X (10.7.x) and prior
ProvideCustomSlide	YES	Provide custom KASLR slide on low memory. This option forces macOS to use a pseudo random value among the available ones. Used for Slide variable calculation. However, the necessity of this quirk is determined by OCABC: Only N/256 slide values are usable! message in the debug log. If the message OCABC: All slides are usable! You can disable ProvideCustomSlide! is present in your log, you can disable ProvideCustomSlide.
RebuildAppleMemoryMap	YES	Generates Memory Map which is compatible with macOS. Since several types of firmware come with incorrect memory protection tables, this quirk often comes paired with SyncRuntimePermissions. Required for OS X (10.7.x) and prior
ResizeAppleGpuBars	-1	Reduce GPU PCI BAR sizes for compatibility with macOS. Usually relevant for bare metal. Not required for Hyper-V due to lack of Graphics support.

DeviceProperties​

---

This section is used for adding device properties. This includes PCI Device information such as Graphics, Audio, WiFi, Ethernet, and other controllers. This section can be also used for PCI Device implementation, Device Spoofing, and EDID injection. This section requires no modification and will remain untouched for Hyper-V.

Kernel​

---

This section is used for different kinds of Kernelspace modifications for Apple Kernel (XNU). This includes Kexts Injection, Kernel and Driver patching, driver blocking, and CPU spoofing. The necessary sections are explained below.

Add​

This section is for adding the Kexts files for your target system which will allow booting macOS. You can specify in what order to load the kexts and can also define the architecture of each kext(s). This can include the mandatory Kexts as well as any add-on Kext(s) for specific purposes such as USB and Card Reader. Link the same Kexts as in the EFI/OC/Kexts directory.

The required kexts for Hyper-V include:

• Lilu.kext
• VirtualSMC.kext
• MacHyperVSupport.kext
• MacHyperVSupportMonterey.kext

Notes:

• All the plugins must load after loading its dependencies otherwise the kext will no longer function even when loaded in OS X/macOS.
• The mandatory kexts must be loaded in sorted order as shown in the above table.
• *Indicates BundlePath i.e. Name of the Kext
• **Indicates mandatory kexts.
• The kexts defined here must exist in the EFI/OC/Kexts directory.
• The options which have been not discussed above, that will remain untouched.

Block​

This section is for blocking the Kext(s) from the prelinked kernel.

Although generally not required, blocking might be required if you're installing a Legacy version of OS X (10.4, 10.5, and 10.6 in 32-bit mode). Blocking the AppleEFIRuntime is required on the previous version as EFI runtime services and NVRAM are unavailable in those versions due to certain incompatibilities with the Hyper-V UEFI. If you're installing 10.7 or later, you can skip this or you can keep them enabled as long as you specify the MinKernel and MaxKernel to ensure that the kext is only blocked on OS X 10.6 and prior.

• Block AppleEFIRuntime
  • Arch = Any
  • Identifier = com.apple.driver.AppleEFIRuntime
  • Comment = Block AppleEFIRuntime
  • MinKernel = 8.0.0
  • MaxKernel = 10.0.0
  • Strategy = Disable
  • Enabled = YES

Force​

This section allows forcing kexts to load from the System Volume if they are not cached. This resolves the problem of injecting kexts that depend on other kexts, which are not otherwise cached. The issue typically affects older operating systems, where various dependency kexts, such as IOAudioFamily or IONetworkingFamily may not be present in the kernel cache by default.

Although generally not required, forcing kexts to load from the System Volume might be required if you're installing an older version of macOS such as OS X (10.6) or prior. If you're installing 10.7 or later, you can skip this step or you can keep them enabled as long as you specify the MinKernel and MaxKernel to ensure that the kext is only forced to load on OS X 10.6 and prior.

The required forcing of kexts for Hyper-V include:

• Force Load IONetworkingFamily
  • Arch = Any
  • BundlePath = System/Library/Extensions/IONetworkingFamily.kext
  • Identifier = com.apple.iokit.IONetworkingFamily
  • Comment = Force Load IONetworkingFamily
  • ExecutablePath = Contents/MacOS/IONetworkingFamily
  • PlistPath = Contents/Info.plist
  • MinKernel = 8.0.0
  • MaxKernel = 10.0.0
  • Enabled = YES
• Force Load IOSCSIParallelFamily
  • Arch = Any
  • BundlePath = System/Library/Extensions/IONetworkingFamily.kext
  • Identifier = com.apple.iokit.IOSCSIParallelFamily
  • Comment = Force Load IONetworkingFamily
  • ExecutablePath = Contents/MacOS/IONetworkingFamily
  • PlistPath = Contents/Info.plist
  • MinKernel = 8.0.0
  • MaxKernel = 10.0.0
  • Enabled = YES

Patch​

This section allows patching for Kernel and Kexts prior to driver addition and removal.

If you're installing 10.6 or later, you can skip this or you can keep them enabled as long as you specify the MinKernel and MaxKernel to ensure that the patches are only applied on OS X 10.5 and prior.

The required patches for Hyper-V include:

• Disable _hpet_init
  • Arch = i386
  • Base = _hpet_init
  • Comment = Disables _hpet_init due to no HPET hardware present
  • Count = 1
  • Identifier = kernel
  • MaxKernel = 9.5.99
  • Replace = C3
• Disable IOHIDDeviceShim::newTransportString()
  • Arch = i386
  • Base = __ZNK15IOHIDDeviceShim18newTransportStringEv
  • Comment = Fix crash in IOHIDDeviceShim::newTransportString() caused by NULL _deviceType
  • Count = 1
  • Identifier = com.apple.iokit.IOHIDFamily
  • MaxKernel = 9.6.99
  • MinKernel = 9.5.0
  • Replace = 31C0C3
• Disable scaling factor for X/Y mouse movement
  • Arch = i386
  • Base = __ZN16IOHIDEventDriver21handleInterruptReportE12UnsignedWideP18IOMemoryDescriptor15IOHIDReportTypem
  • Comment = Workaround for the absence of AbsoluteAxisBoundsRemovalPercentage in 10.4
  • Identifier = com.apple.iokit.IOHIDFamily
  • Find = BA1F85EB51
  • MaxKernel = 8.11.99
  • MinKernel = 8.0.0
  • Replace = BA00000000

Emulate​

This section allows you to spoof your CPU ID if you're using any unsupported CPU. CPU spoofing may be required depending on the host CPU for older versions of macOS

Properties	Value	Description
Cpuid1Data	55060A00 00000000 00000000 00000000	Fake CPUID Required for unsupported host CPU for older versions of macOS
Cpuid1Mask	FFFFFFFF 00000000 00000000 00000000	Mask for fake CPUID Required for unsupported host CPU for older versions of macOS
MinKernel		Minimum Kernel the CPUID will be applied to. If MinKernel is not specified, it will be applied to all versions of macOS.
MaxKernel		Maximum Kernel the CPUID will be applied to. If MinKernel is not specified, it will be applied to all versions of macOS.
DummyPowerManagement	YES	Disables AppleIntelCPUPowerManagement Provides Dummy Power Management. This option is an alternative to NullCPUPowerManagement.kext for CPUs without native power management drivers in macOS. Required for all AMD-based systems and Hyper-V as there is no native Power Management. Disabling this option will lead to Kernel Panic for AppleIntelCPUPowerManagement.kext.

Scheme​

This section allows settings related to Kernel. These settings are relevant for older Mac Operating Systems. This section requires no modification and will remain untouched for Hyper-V.

Properties	Value	Description
FuzzyMatch	YES	Use kernelcache with different checksums when available. On macOS 10.6 and earlier, kernelcache filename has a checksum, which essentially is adler32 from SMBIOS product name and EfiBoot device path. On certain firmware, the EfiBoot device path differs between UEFI and macOS due to ACPI or hardware specifics, rendering kernelcache checksum as always different. Enabling this option ignores kernelcache checksum and uses the latest available cache. This setting allows matching the latest kernelcache with a suitable architecture when the kernelcache without a suffix is unavailable, improving macOS 10.6 boot performance on several platforms. Required for macOS Big Sur and above.
KernelArch	Auto	Defines Kernel Architecture type. It's recommended to set this option to "Auto" and let macOS/OS X decide the Kernel Architecture.
KernelCache	Auto	Defines Kernel Cache type. It's recommended to set this option as Auto.
CustomKernel	Disabled	Use customized kernel cache from the Kernels directory located at the root of the ESP partition. Unsupported platforms including Atom and AMD require modified versions of the XNU kernel in order to boot. This option provides the possibility of using a customized kernel cache that contains such modifications from the ESP partition.

Quirks​

This section allows to apply certain Kernel quirks. It provides settings related to Kernel and several other options related to BIOS/UEFI and USB ports.

The required Kernel Quirks for Hyper-V include:

Quirks		Description
DisableLinkeditJettison	YES	Disables __LINKEDIT jettison code. This Quirk lets Lilu.kext, and possibly other kexts, function in macOS Big Sur at their best performance levels without requiring the keepsyms=1 boot argument. Required for macOS Big Sur and above.
ProvideCurrentCpuInfo	YES	Provides current CPU info to the kernel. Depending on the CPU, the Quirk performs the following function: Provides the correct TSC and FSB values to the kernel, as well as disables CPU topology validation (10.8+) for Microsoft Hyper-V. Provides precomputed MSR 35h values solving kernel panic with -cpu host for KVM and other hypervisors. Adds support for asymmetrical SMP systems for Intel CPUs (e.g. Intel Alder Lake) by patching core count to thread count along with the supplemental required changes (10.14+). Required for Alder Lake and AMD CPUs and for Hyper-V and KVM.
SetApfsTrimTimeout	-1	Sets TRIM timeout in microseconds for APFS filesystems on SSDs. Only applicable for macOS Mojave 10.14 and above. See macOS and TRIM for more information. The failsafe value -1 indicates that this patch will not be applied, such that apfs.kext will remain untouched. On macOS 12.0 and above, it is no longer possible to specify a trim timeout. However, trim can be disabled by setting 0. Trim operations are only affected at the booting phase when the startup volume is mounted. Either specifying timeout, or completely disabling trim with 0, will not affect normal macOS running.

Misc​

---

This section is used for miscellaneous configuration options affecting OpenCore Operating System loading behavior in addition to other options that do not readily fit into other sections. GUI, drive entries and debug. This includes GUI, Boot Entries, Debug, Security, and Serial.

Boot​

This section mainly provides functions for OpenCore GUI.

The required properties for Hyper-V include:

Properties	Value	Description
HideAuxiliary	Disabled	Hides auxiliary entries from the OpenCore picker menu. An entry is considered auxiliary when at least one of the following applies: Entry is macOS recovery. Entry is macOS Time Machine. Entry is explicitly marked as Auxiliary. Entry is a system (e.g. Reset NVRAM). To display all entries, the picker menu can be reloaded into “Extended Mode” by pressing the Spacebar key. Hiding auxiliary entries may increase boot performance on multi-disk systems.

Debug​

This section allows debug functions for boot.

The required properties for Hyper-V include:

Properties	Value	Description
Disable WatchDog	YES	Disables Watchdog Timer when set to true. Some types of firmware may not succeed in booting the operating system quickly, especially in debug mode. This results in the watchdog timer aborting the process.
AppleDebug	YES	Enable writing the boot.efi debug log to the OpenCore log. Requires macOS 10.15.4 and newer
ApplePanic	YES	Save macOS kernel panic output to the OpenCore root partition. The file is saved as panic-YYYY-MM-DD-HHMMSS.txt. It is strongly recommended to set the keepsyms=1 boot argument to see debug symbols in the panic log. In cases where it is not present, the kpdescribe.sh utility (bundled with OpenCore) may be used to partially recover the stacktrace. In cases where the OpenCore kernel panic saving mechanism is not used, kernel panic logs may still be found in the /Library/Logs/DiagnosticReports directory.

Security​

This section controls security related settings such as FileVault, Boot Protect, and Secure Boot functions.

The required properties for Hyper-V include:

Properties	Value	Description
Scan Policy	0	Defines Operating System Detection policy.
Vault	Optional
SecureBootModel	Default	Sets Apple Secure Boot hardware model and policy. Specifying this value defines which operating systems will be bootable. Operating systems shipped before the specified model was released will not boot. Not all Apple Secure Boot models are supported on all hardware configurations. See Apple Secure Boot and macOS for more information. If you're trying to install macOS Catalina/Mojave/High Sierra, set the Secure Boot Model to Disabled.
AllowSetDefault	YES	Allows setting the default boot option in the OpenCore picker using CTRL+Enter and CTRL+Index. May be used in combination with Shift+Enter or Shift+Index when PollAppleHotKeys is enabled. In order to support systems with unresponsive modifiers during preboot (which includes V1 and V2 KeySupport mode on some firmware) OpenCore also allows holding the =/+ key in order to trigger ‘set default’ mode.
BlacklistAppleUpdate	YES	Ignore boot options trying to update Apple peripheral firmware (e.g. MultiUpdater.efi). Certain operating systems, such as macOS Big Sur, are incapable of disabling firmware updates by using the run-efi-updater NVRAM variable.

Serial​

This section is used for debugging. This section requires no modification and will remain untouched for Hyper-V.

BlessOverride​

This section is used for adding custom scanning paths through the bless model. This section requires no modification and will remain untouched for Hyper-V.

Entries​

This section is used to create boot entries when having multi boot and OpenCore fails to recognise it.

Tools​

This section is used for running debugging tools such as UEFI Shell. This section requires no modification and will remain untouched for Hyper-V.

NVRAM​

---

This section is for adding NVRAM properties, boot args and configuring SIP. The necessary sections are explained below.

Add​

This section has various settings including UI, boot args, keyboard input, NVRAM settings and System Integrity Protection. The required Booter Quirks for Alder Lake include:

4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14


4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102

7C436110-AB2A-4BBB-A880-FE41995C9F82

Key

• boot-args
  
  • Additional arguments or boot flags. The required boot-args for Hyper-V include:

boot-args	Description
-v	Enables verbose mode. Replaces the progress bar below the Apple logo with a text output of the boot process. Helps to track the installation progress or when booting.
-legacy	Required for running 32-bit versions of macOS
debug=0x100	Disables macOS's watchdog which helps prevent a reboot on a kernel panic.
keepsyms=1	The companion setting to debug=0x100 that tells the OS to also print the symbols on a kernel panic. This can give some more helpful insight as to what's causing the panic itself.

• csr-active-config: 00000000
  • Defines System Integrity Protection (SIP) Type.
  • By default, the System Integrity Protection is set to 00000000 which enables the System Integrity Protection on the target installation. You can configure the SIP as per your requirements. See Disabling SIP for more information.

prev-lang:kbd
Sets Keyboard language

run-efi-updater: No

Delete​

Removes NVRAM variables from a map (plist dict) of GUIDs to an array (plist array) of variable names in plist string format. This section requires no modification and will remain untouched for Hyper-V.

LegacySchema​

This section is used for assigning NVRAM variables, used with LegacyEnable set to YES. Enables loading of NVRAM variable file named nvram.plist from EFI volume root. This section requires no modification and will remain untouched for Hyper-V. However, due to the fact users using config.plist from different sources rather than sticking to one guide, the properties are explained. These are the default values which is already present in the sample.plist which does not need to be configured again.

NVRAM Properties

Properties	Value	Description
LegacyOverwrite	False	Permits overwriting firmware variables from nvram.plist. Only variables accessible from the operating system will be overwritten. Only needed for systems without native NVRAM. See Fixing NVRAM for more information.
WriteFlash	True	Enables writing off added Variables to flash memory. It is recommended to have this value enabled on most types of firmware but it is left configurable for firmware that may have issues with NVRAM variable storage garbage collection or similar. This option is not compatible with Emulated NVRAM. See Emulated NVRAM for more information.

PlatformInfo​

---

This section allows to set SMBIOS. It's an important section and has various impact on your system. The sub-sections are explained below.

UEFI​

---

This section is for adding UEFI drivers and related settings. The sub-sections are explained below.

APFS​

Provides APFS Settings for APFS Driver.

By default, OpenCore only loads APFS drivers from macOS Big Sur and newer. If you're trying to boot macOS Catalina or prior, you'll need to set the minimum date and minimum version. Failure to configure the version can result in OpenCore not finding your macOS partition. If you're installing macOS Sierra or prior, you can skip this as prior to High Sierra, macOS uses HFS instead of APFS.

macOS Version	MinDate	MinVersion
High Sierra (10.13.x)	20180621	7480770080000000
Mojave (10.14.x)	20190820	9452750070000000
Catalina (10.15.x)	20200306	1412101001000000
Big Sur (11.x)	20210508	1677120009000000
Any	-1	-1

AppleInput​

This section provides settings to configure the Re-implementation of the Apple Event protocol. This section requires no modification and will remain untouched for Hyper-V.

Audio​

Provides Audio related settings for Audiodxe Driver and Boot Chime. This section is unrelated to the normal onboard Audio function. This section requires no modification and will remain untouched for Hyper-V.

Drivers​

This section is for adding .efi drivers.

The required drivers for Hyper-V include:

Drivers	Required	LoadEarly	Notes
OpenRuntime.efi	YES	NO	Runtime driver including several other drivers merged such as ApfsDriverLoader. OpenRuntime.efi is a replacement for AptioMemoryFix.efi driver. Required for booting and proper functioning of OpenCore
HfsPlus.efi	YES	NO	HFS File System Driver with bless support. Provides reading of HFS+ Volumes/drives in OpenCore Boot Picker. This driver is an alternative to a closed source HfsPlus driver commonly found in Apple firmware.
OpenCanopy.efi	Optional	NO	Provides GUI functionality for OpenCore Boot screen. This driver is required if you need GUI for OpenCore. See Enabling GUI for more information.
ResetNvramEntry.efi	YES	NO	Provides Reset NVRAM support. Required since OpenCore 0.8.1 and later See Resetting NVRAM for more information.

Connect Drivers: YES

• Force injects the added .efi drivers. Changing this setting to NO will automatically connect the added UEFI drivers. This can speedup the boot process, however, not all drivers will connect themselves.

Input​

This section provides settings for FileVault and Hotkey support for Keyboard passthrough. This section requires no modification and will remain untouched for Hyper-V.

Output​

This section provides settings for OpenCore GUI. This section requires no modification and will remain untouched for Hyper-V.

ProtocolOverrides​

This section provides settings for Virtual machines, legacy Macs, and FileVault users. This section requires no modification and will remain untouched for Hyper-V.

ReservedMemory​

This section is used for exempting certain memory regions from OS(s) to use, mainly relevant for Sandy Bridge iGPUs or systems with faulty memory. This section requires no modification and will remain untouched for Hyper-V.

Quirks​

This section allows to apply certain firmware quirks.

The required Quirks for Hyper-V include:

Quirks	Value	Description
DisableSecurityPolicy	YES	Disable platform security policy. This setting disables various security features of the firmware, defeating the purpose of any kind of Secure Boot. Do NOT enable it if using UEFI Secure Boot.
EnableVectorAcceleration		Enable AVX vector acceleration of SHA-512 and SHA-384 hashing algorithms. This option may cause issues on certain laptop firmware including Lenovo.
ForceOcWriteFlash		Enables writing to flash memory for all OpenCore-managed NVRAM system variables. This value should be disabled on most types of firmware but is left configurable to account for firmware that may have issues with volatile variable storage overflows or similar. Boot issues across multiple OSes can be observed on e.g. Lenovo Thinkpad T430 and T530 without this quirk. Apple variables related to Secure Boot and hibernation are exempt from this for security reasons. Furthermore, some OpenCore variables are exempt for different reasons, such as the boot log due to an available user option, and the TSC frequency due to timing issues. When toggling this option, a NVRAM reset may be required to ensure full functionality
IgnoreInvalidFlexRatio		Some types of firmware (such as APTIO IV) may contain invalid values in the MSR_FLEX_RATIO (0x194) MSR register. These values may cause macOS boot failures on Intel platforms. While the option is not expected to harm unaffected firmware, its use is recommended only when specifically required.
ReleaseUsbOwnership		Attempt to detach USB controller ownership from the firmware driver. While most types of firmware manage to do this properly, or at least have an option for this, some do not. As a result, the operating system may freeze upon boot. Not recommended unless specifically required.
RequestBootVarRouting	YES
UnblockFsConnect		Some types of firmware block partition handles by opening them in By Driver mode, resulting in an inability to install File System protocols. This quirk is useful in cases where unsuccessful drive detection results in an absence of boot entries.
ExitBootServicesDelay	0	Adds delay in microseconds after EXIT_BOOT_SERVICES event. This is a very rough workaround to circumvent the Still waiting for root device message on some APTIO IV firmware (ASUS Z87-Pro) particularly when using FileVault 2. It appears that for some reason, they execute code in parallel to EXIT_BOOT_SERVICES, which results in the SATA controller being inaccessible from macOS. A better approach is required and Acidanthera is open to suggestions. Expect 3 to 5 seconds to be adequate when this quirk is needed.
TscSyncTimeout	0
ResizeGpuBars	-1

Validating config.plist ​

Once you're done editing the config.plist file, the next step is to validate the config.plist to make sure no error exists. To validate your config.plist, follow the steps below.

CHAPTER 4: Enable Hyper-V on Windows​

Before you can create Virtual Machines, you'll need to enable Hyper-V. Hyper-V is a component built into Windows as an optional feature but is not enabled by default. Hyper-V can be enabled in many ways including using the Control Panel Power Shell or using the Deployment Imaging Servicing and Management Tool (DISM). This chapter will walk through each of those options.

Enable Hyper-V using PowerShell​

PowerShell is a task automation solution made up of a command-line shell, which can automate tasks, manage systems, and deploy systems. To enable Hyper-V using DISM, follow the steps below.

1. Open the PowerShell console as Administrator. When prompted, click on Yes.
2. Execute the following command:

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All

If the command couldn't be found, make sure you're running PowerShell as Administrator.

Windows will restart and process the features and updates.

Enable Hyper-V using DISM​

The Deployment Image Servicing and Management Tool (DISM) can configure Windows and Windows images. Among its many applications, DISM can enable Windows features while the operating system is running. To enable Hyper-V using DISM, follow the steps below.

1. Open PowerShell or CMD as Administrator. When prompted, click on Yes.
2. Execute the following command:

DISM /Online /Enable-Feature /All /FeatureName:Microsoft-Hyper-V

Windows will restart and process the features and updates.

Enable Hyper-V using Windows Features​

1. Right-click on the Windows Start button and open Windows Features. You can also open it from the Control Panel if you want.
2. Select Hyper-V and click on OK. Ensure that sub-options are checked.
When prompted, restart your computer.

CHAPTER 5: Create a Hyper-V Virtual Machine​

Before you install macOS, you'll need to create a Virtual Machine in Hyper-V. Follow the steps below to create a Virtual machine. To create a Virtual Machine in Hyper-V, follow the steps below.

1. Open Hyper-V Manager from the Start Menu.
2. From the right pane, click on New under Actions to launch the New Virtual Machine Wizard. Don't use Hyper-V Quick Create
3. Click on Next and specify a name for your Virtual Machine. For instance, we'll be using macOS. You can use any name.
By default, the Hyper-V will store the Virtual Machine in C:\ProgramData\Microsoft\Windows\Hyper-V. However, if you do not want to use the default location, you can specify a manual location to store the Virtual Machine data.

4. Select Generation 2 and click on Next. This is because MacHyperVSupport requires a Generation 2 Virtual Machine. Generation 2 has simply better support for virtualization features and supports UEFI. Please note that if you have created a Generation 1 by mistake, you must delete the virtual machine and configure it as Generation 2. Once a virtual machine has been created, you cannot change its generation.

5. Set the Startup memory as 8192MB and click on Next. Make sure Use Dynamic Memory for this virtual machine option is checked. If you have enough memory on the host system, 8GB would be preferred (see note below).

NOTE: Due to some unknown reasons, the macOS will not boot with less than 8192MB memory.

6. Select Default switch from the drop-down under connection.

7. Select Attach a virtual hard disk later and click on Next. We can skip this step now and create the required Virtual Drives in the next chapter of this guide. You can either create a virtual hard disk during the Wizard or use an existing one but it is not recommended.

8. Review the Summary and click on Finish. If you notice that the parameters are not set as recommended, you can still edit the options and then review the Summary and click on Finish.

Now Hyper-V will create a new Virtual Machine with the parameters you choose. A Virtual Machine should appear in the list of Virtual Machines in the Hyper-V Manager.

CHAPTER 5: Configure Virtual Machine Parameters​

In order to boot the macOS installer, you still need to configure the Virtual Machine Parameters. To configure the Virtual Machine Parameters, follow the steps below.

Disable Secure Boot​

In order to boot the OpenCore, you'll need to disable Secure Boot. By default, the Secure Boot is enabled for security purposes. Follow the steps below to disable Secure Boot.

1. Select the Virtual Machine you created and click on Settings from the right pane.
2. Select Security under Hardware and uncheck the Enable Secure Boot option. By default, the Secure Boot is always Enabled on the Generation 2 Virtual Machines. Please note that you will not have this when using a Generation 1 Virtual Machine.

Configure Processor​

Like a bare metal, a Virtual Machine also needs a Virtual Processor to process the given instructions. To configure the Processor, follow the steps below.

1. Assuming the Virtual Machine Settings Window is still open, Select the Processor under Hardware and change the number of Virtual Processors to no more than half of the Threads available on the host computer. The virtual core allocation should be always under 50% of the actual physical CPU Cores. Allocating more than 50% of the physical core may slow down the host computer.

(e.g. i5-10400 is a 6 Core CPU which has 12 Threads so allocating 6 Virtual Cores is under the 50% utilization limit).

By default, Hyper-V will automatically assign half of the physical cores to the Virtual Machine so that its under the 50% utilization and not over provisioned

/Create Virtual Hard Disks\​

Now it's time to create the Virtual Hard Disk. We'll be creating two of them. One for the Recovery (virtual Bootable USB) and the other (Virtual Drive) for the macOS installation. You can also use a dedicated SSD if you wish to.

/Creating Boot Disk\
Firstly, we'll create a New Virtual Hard Disk to use as a Boot Drive under macOS. This will be our Boot Disk, just like the physical USB you use on a Bare Metal but virtual

1. Select SCSI Controller under the Hardware section from the left pane.
2. Select Hard Drive and click on Add
3. Click on New and then click on Next
4. Select Fixed size and click on Next. As the recovery image requires the least capacity, a fixed-size disk would be ideal for this purpose.
5. Set the Name as EFI and click on Next. By default, the Virtual Disk location is C:\ProgramData\Micrsofot\ Windows\Virtual Hard Disks. You can change the location of the virtual drive if you want to as per your preferences, but usually not required.
6. Set the size to 1GB as that's the minimum capacity and click on Next. We don't need more than that as the recovery image is less than 600MB.
7. Review the Summary and click on Finish. If you notice that the parameters are not set as recommended, make the changes as needed and click on Finish.

A virtual Hard Disk will be added under the SCSI Controller

Creating macOS Disk
Now that we have the Virtual Bootable USB Disk ready, we need to create another Virtual Disk for the macOS installation.

1. Select SCSI Controller under the Hardware section from the left pane.
2. Select Hard Drive and click on Add

If you want to use a physical disk for the installation, follow the steps below

1. Select Physical hard disk under the Media selection. Select the target disk from the drop-down menu.
2. Click on Apply and then click on OK.

NOTE: If you do not see the physical disk listed that you want to use, make sure the disk is offline. Use disk management on the host computer to manage physical disks.


3. Click on New and then click on Next
4. Select Dynamically expanding and click on Next.
5. Set the Name as Virtual Disk and click on Next. By default, the Virtual Disk location is C:\ProgramData\Micrsofot\ Windows\Virtual Hard Disks. You can change the location of the virtual drive if you want to as per your preferences, but usually not required.
6. Set the size to 50GB. You can change the capacity as per your needs. 50GB should be enough to install macOS and keep some files. The drive capacity can expand upto the max size you select here so please keep that in mind. The minimum capacity is 1GB and the maximum capacity is 64TB.
7. Review the Summary and click on Finish. If you notice that the parameters are not set as recommended, make the changes as needed and click on Finish.

A virtual Hard Disk will be added under the SCSI Controller

Configure Integration Services​

Integration services (often called integration components) are services that allow the virtual machine to communicate with the Hyper-V host. Many of these services are conveniences while others can be quite important to the virtual machine's ability to function correctly. To configure the Integration Services, follow the steps below.

1. Select all the Services from the Integration Services list under the Management section.
2. From the Management section, select all the Services from the Integration Services list.
3. Once you're done with configuring the Virtual machine, simply click on Apply and then click on OK.

Configure Boot Priority​

By default, Hyper-V will always boot via Network. To configure the Boot Priority, follow the steps below

1. Select the Virtual Machine you created and click on Settings from the right pane.
2. Select Firmware under the Hardware section from the left pane
3. Adjust the boot order so that the EFI BOOT.vhdx Hard Drive is set as the first boot priority and the other Virtual Disk.vhdx is the second Hard Drive. If you have a network or any other relevant option, move those to the end of the list to have the least boot priority.
4. Click on Apply and then click on OK.

/Configure Bootable Disk\​

Now that we have the EFI and the recovery image ready, we'll need to copy it to our Virtual Disk so that we can boot via OpenCore. To configure the Bootable Disk, follow the steps below.

1. Select the Virtual Machine you created previously.
2. Click on Inspect Disk...
3. Right-click on EFI BOOT and select Mount to mount the EFI BOOT Drive in Explorer. It will throw an error, but you don't have to worry. This will just attach the VHD.
4. Click on Cancel
5. Right-click on This PC and select Manage.
6. Select Disk Management and you'll get a prompt to initialize the disk
7. Select MBR from the partition style and click on OK.
The VHD will be active and the status will be Online. As we haven't created any partition or formatted it yet, the Disk will appear as Unallocated.
8. Right-click on the Unallocated partition and select New Simple Volume.
9. Continue with the steps until the Format Partition
10. Select FAT32 under File system and type EFI in the Volume label field. The rest of the parameters will remain unchanged i.e. default values.
11. Review the summary and click on Finish.

A new FAT32 partition will be created and available on the host computer.

12. Open File Explorer and copy the com.apple.recovery.boot from OpenCore-0.X.X-RELEASE/Utilities/macrecovery directory and the EFI from the working directory to the root of the EFI BOOT Drive.
13. Once copied, open Disk Management using This PC > Manage > Disk Management
14. Select the VHD and click on Detach VHD.
15. When prompted, click on OK

The VHD should be detached from the host computer.

This is a one time process. Whenever you'll have to change the contents of the EFI BOOT VHD or any changes in the config.plist or the EFI itself, you can mount and Eject when you're done. It will detach the connected VHD afterward.

Please note that you must eject all VHD to start the Virtual Machine or it will throw an error during starting the Virtual Machine.

Spoiler: Making changes in the EFI BOOT Partition

As EFI BOOT is our Virtual USB, it can be understood that you may need to make some changes in the EFI or the config.plist or change the recovery image, you can do so using the steps below.

Select the Virtual Machine you created previously.
Click on Inspect Disk...
Right-click on EFI BOOT and select Mount to mount the EFI BOOT Drive in Explorer. Do NOT click on Open.
Now, copy the com.apple.recovery.boot and the EFI from xGxx to the root of the EFI BOOT Drive.
Right-click on the EFI BOOT and click on the Eject button within the context menu. This will unmount the drive to use it in Hyper-V.

Configure macOS Disk​

Due to some weird bug, if the macOS Disk (the disk on which you'll be installing macOS), macOS stops booting and fails to reach the recovery menu. To configure the macOS Disk, follow the steps.

1. Select the Virtual Machine you created previously.
2. Click on Inspect Disk...
3. Right-click on the Virtual Disk and select Mount to mount the Virtual Disk in Explorer. It will throw an error, but you don't have to worry. This will just attach the VHD.
4. Click on Cancel
5. Right-click on This PC and select Manage.
6. Select Disk Management and you'll get a prompt to initialize the disk
7. Select GPT from the partition style and click on OK.
The VHD will be active and the status will be Online. As we haven't created any partition or formatted it yet, the Disk will appear as Unallocated.
8. Right-click on the Unallocated partition and select New Simple Volume.
9. Continue with the steps and perform a quick format using the default options.
A new NTFS partition will be created and available on the host computer.
10. Select the VHD and click on Detach VHD.
11. When prompted, click on OK

The VHD should be detached from the host computer.

CHAPTER 6: Installing macOS​

Once everything is set, you're ready to perform a clean install of the desired macOS version on Hyper-V.

STEP 1: Booting the macOS Installer
After preparing the OpenCore EFI and the Virtual Machine, you're ready to install macOS on Hyper-V.

1. Select the Virtual Machine and click on Connect.
2. When prompted, click on Start
3. When at OC Boot Picker, you'll something similar:
4. Select EFI (dmg) and press enter to boot and the installer will load in a while. You'll see lots of scrolling texts while the installer loads.

STEP 2: Installing OS X/macOS
1. When at the installation screen, select your preferred language and continue
2. Select Disk Utility and continue, click on View, and select Show all Devices.
3. Now select Msft Virtual Disk Media and use the following parameters to erase your drive:

Name: Macintosh HD
Format: APFS
Scheme: GUID Partition Map

NOTES:

• The target disk/partition must be GUID
• APFS format is recommended for High Sierra and Later
• Users who plan to use High Sierra on HDD should use macOS Journaled (HFS+) Format instead of APFS Format.

4. Close Disk Utility
5. Select Install macOS and continue with the options.
6. Now select Macintosh HD and click on Continue.

NOTES:

• Step #6 will format the target disk. Proceed with caution.
• This will take a couple of minutes and will restart at "Less than a minute is remaining". Upon completion, the system will automatically restart. Your Mac will restart to complete the installation.

Here it ends the first phase of the installation.

7. When the installer reboots, it might be possible that it will get stuck. Turn off the Virtual Machine and then turn it on again. When at OC, select Boot macOS Install from Macintosh HD or (Your drive name) and then press enter to boot. The installer screen will appear and continue the second phase of the installation. During this phase, the installer will install files to your target disk and create a Recovery HD partition. Upon completion, your Mac will automatically restart and will stuck again. Turn off the Virtual Machine and then turn it on again. When at OC, select Macintosh HD and then press enter to boot.

STEP 3: Finishing macOS Setup
After finishing the macOS installation, it's time to set up the macOS for the first usage with the newly installed macOS.

When you're at the welcome screen, continue with the basics options such as Keyboard setup, Network, Computer Account, and Privacy settings.

Now the installation is complete! You should be logged in to your Desktop with the beautiful Wallpaper

CHAPTER 7: Post-installation​

Although a bare metal involves a lot more post-install steps such as fixing Graphics, Network, Thunderbolt, etc due to the hardware not being utilized properly, the post-install step on a Hyper-V involves booting without Virtual USB. The instructions are almost the same as bare metal.

1. Mount the EFI Partition of your macOS Disk.
2. Open the EFI mounted on the Desktop and copy it to the ESP you just mounted.
3. Once copied, unmount the EFI Partition of your macOS Disk. You can also eject the partition to unmount it.
4. Shut Down
5. Select the Virtual Machine and click on Settings from the right pane.
6. Select SCSI Controller under the Hardware section from the left pane.
7. Select Hard Drive followed by the EFI BOOT and click on Remove.
8. Click on Apply. When prompted, click on Continue.

Now you can start the Virtual Machine and enjoy macOS on Windows.

 

[Alias6302]

Great guide. Unfortunately, I am not able to follow Chapter IV, section ACPI, sub-section Patch. The columns in your table do not match what I am seeing and I am not able to figure out the correct mapping.

See screenshot below.
Thanks!

 

[EliteMacx86]

Great guide. Unfortunately, I am not able to follow Chapter IV, section ACPI, sub-section Patch. The columns in your table do not match what I am seeing and I am not able to figure out the correct mapping.

See screenshot below.
Thanks!

View attachment 7182

The guide is updated. You should be good now!

 

[Alias6302]

The guide is updated. You should be good now!

Thanks so much for the update. One point of clarification: the table signature column is asking for a HEX value so do I enter DSDT as an ASCII value like so:

 

[EliteMacx86]

Thanks so much for the update. One point of clarification: the table signature column is asking for a HEX value so do I enter DSDT as an ASCII value like so:

View attachment 7193

Yes, you can convert it to HEX.

 

[Alias6302]

Having an issue with validation. I added the two entries as the guide notes in Kernel -> Force, but OC validation complains of the following:

NOTE: This version of ocvalidate is only compatible with OpenCore version 0.8.8!


Kernel->Force: System/Library/Extensions/IONetworkingFamily.kext is duplicated at Index 0 and 1!
CheckKernel returns 1 error!

Completed validating E:/EFI/OC/config.plist in 1 ms. Found 1 issue requiring attention.

 

[EliteMacx86]

Having an issue with validation. I added the two entries as the guide notes in Kernel -> Force, but OC validation complains of the following:

NOTE: This version of ocvalidate is only compatible with OpenCore version 0.8.8!


Kernel->Force: System/Library/Extensions/IONetworkingFamily.kext is duplicated at Index 0 and 1!
CheckKernel returns 1 error!

Completed validating E:/EFI/OC/config.plist in 1 ms. Found 1 issue requiring attention.

View attachment 7200

Its required for old macOS versions. You don't need it. Remove it and you should be good.

 

[Dreaded2400]

Hi,

Thanks for the guide.

I managed to get it running, but I was just wondering whether there is any way run the VM at a resolution other than 1024x768? I assume it's not possible to get Enhanced Session mode working for MacOS.

 

[EliteMacx86]

Hi,

Thanks for the guide.

I managed to get it running, but I was just wondering whether there is any way run the VM at a resolution other than 1024x768? I assume it's not possible to get Enhanced Session mode working for MacOS.

Hello,

Not as of now. Hopefully, anytime soon.

 

[Valnomien]

not sure what I'm doing wrong, but I have reviewed every step and each time I make a change or correction I get a little further.