TL;DR: Yes, you can run macOS on VMware on an AMD system. No, it won't be easy. This guide documents what actually worked — including the failures — so you don't have to spend your weekend on it.
- Overview
- Prerequisites
- Why Monterey and Not Ventura?
- Downloading macOS
- Installing QEMU
- Creating the VMDK
- Preparing VMware with Auto-Unlocker
- Creating the VM
- Critical .vmx Configuration
- Installing macOS
- Troubleshooting — The Ventura Experiment
- Post-Install
This guide walks through installing macOS Monterey 12 as a virtual machine inside VMware Workstation Pro 17 on a Windows 11 host with an AMD CPU.
- Developers who need macOS for UI/compatibility testing (e.g., a Python Tkinter desktop app) but don't own Apple hardware
- People who have already tried following a generic VMware/macOS guide and hit a black screen, kernel panic, or the prohibited symbol (🚫)
- Anyone on AMD who found that Intel-focused guides don't quite work
A functional macOS Monterey 12.7.6 VM running inside VMware on a Windows AMD machine, suitable for app testing and light development work.
| Component | Detail |
|---|---|
| Host machine | ServeHer (Windows 11 Pro, Build 26200) |
| RAM | 32 GB |
| CPU | AMD (Ryzen series) |
| VMware Workstation Pro | 17.5.2 build-23775571 |
| Guest OS | macOS Monterey 12.7.6 |
| Guest config | 4 vCPU cores, 8 GB RAM, 80 GB disk |
⚠️ Legal note: Running macOS in a VM on non-Apple hardware is technically against Apple's EULA. This guide is intended for legitimate development and testing purposes only.
⚠️ Virtualization must be enabled in BIOS. Before starting, open Task Manager → Performance tab and confirm virtualization is enabled. If not, boot into your BIOS and enable it. Without this, VMware cannot run any virtual machines.
Gather all of these before you start. Everything links to official sources.
| Tool | Purpose | Where to get it |
|---|---|---|
| VMware Workstation Pro 17 | The hypervisor | vmware.com — free for personal use |
| Auto-Unlocker v2.0.x | Patches VMware to allow macOS as a guest | GitHub: paolo-projects/auto-unlocker |
| OpenCorePkg | Contains macrecovery.py to download macOS |
GitHub: acidanthera/OpenCorePkg — get the RELEASE zip |
| QEMU for Windows | Converts .dmg to .vmdk |
qemu.weilnetz.de |
| Python 3 | Required to run macrecovery.py |
python.org |
- VMware Workstation Pro is installed and has been opened at least once
- Virtualization is enabled in BIOS (check Task Manager → Performance)
- Python 3 is on your PATH (
python --versionworks in PowerShell) - At least 80–100 GB of free disk space available
- Auto-Unlocker downloaded but not yet run (we'll do that after closing VMware)
If you're here because Ventura didn't work, this section is for you.
macOS on VMware requires spoofing the CPU to look like Intel hardware (via CPUID values in the .vmx file). This works — but macOS Ventura (13) introduced stricter kernel-level CPU validation that CPUID spoofing cannot fully satisfy on AMD hardware.
The failure isn't obvious because Ventura doesn't fail immediately. It gets through the installer, runs the progress bar to completion, and then kernel panics on the first real reboot. When you add CPUID spoof values to try to fix it, the failure mode changes to the prohibited symbol (🚫) — a different and harder failure. We documented this entire sequence. See Troubleshooting for the full story.
After going through the whole Ventura failure sequence, we found the underlying technical reason documented in the QuickEMU project wiki:
macOS Ventura (13), Sonoma (14), and Sequoia (15) have stricter TSC (Time Stamp Counter) requirements than earlier versions. On certain AMD Ryzen mobile CPUs, the TSC is marked as unstable during boot calibration, causing these newer macOS versions to freeze or fail to boot with "Non-monotonic time" errors.
Affected CPUs:
- AMD Ryzen 4000U series (Renoir)
- AMD Ryzen 5000U series (Cezanne/Lucienne)
- Some AMD Ryzen Zen 4 mobile chips (7945HX, Z1 Extreme)
Not affected:
- AMD Ryzen 6000U series (Rembrandt)
- Intel CPUs
- AMD desktop CPUs (generally)
This is why CPUID spoofing alone can't fix Ventura — the kernel panic isn't about CPU vendor identity, it's about the TSC being flagged as unreliable at a lower level than the spoof can reach. macOS Monterey (12) predates the stricter TSC requirements and is stable on AMD VMware installs with the correct CPUID configuration.
| macOS Version | AMD VMware Compatibility | Notes |
|---|---|---|
| Monterey (12) | ✅ Reliable | Use this. Stable with correct CPUID spoof. Tested: 12.7.6. |
| Ventura (13) | Installs, then kernel panics on first reboot. TSC instability on AMD Ryzen mobile CPUs. | |
| Sonoma (14) | ❌ Very difficult | Same TSC issue, stricter still. Not recommended for AMD VMware. |
| Big Sur (11) | ✅ OK | Predates TSC requirements. Works, but older. Monterey is the better choice. |
We use macrecovery.py from the OpenCorePkg project to download a genuine macOS recovery image directly from Apple's servers. This is preferred over random ISOs — the integrity is verified and the source is Apple's own CDN.
Download the latest RELEASE zip from GitHub: acidanthera/OpenCorePkg, extract it, and navigate into:
OpenCorePkg-X.X.X-RELEASE\Utilities\macrecovery\
You'll see macrecovery.py, boards.json, recovery_urls.txt, and a few other files.
Hold Shift and right-click inside the Explorer window (not on a file), then select "Open PowerShell window here" or "Open in Terminal".
Run the following command:
py macrecovery.py -b Mac-FFE5EF870D7BA81A -m 00000000000000000 downloadBoard ID
Mac-FFE5EF870D7BA81Atargets macOS Monterey 12. Do not change it if you want Monterey. If you want a different version, look up its board ID in the OpenCore Install Guide.
The script will download two files and verify the image against Apple's chunklist:
When it finishes you'll see:
com.apple.recovery.boot\BaseSystem.dmg(~623 MB)com.apple.recovery.boot\BaseSystem.chunklist
Cut or copy the BaseSystem.dmg file out of the com.apple.recovery.boot subfolder and paste it directly into your Documents folder (C:\Users\<username>\Documents\). The QEMU conversion step will run from there.
QEMU is an open-source disk image utility. We only need one tool from it: qemu-img.exe, which converts the .dmg to a .vmdk.
Go to qemu.weilnetz.de/w64/ and download the latest qemu-w64-setup-XXXXXXXX.exe installer. Ignore the year-named folders.
Run the installer. If Windows SmartScreen blocks it, click Run Anyway. If a file-write error appears during installation, click Retry.
QEMU installs to C:\Program Files\qemu\.
💡 You don't need to add QEMU to your PATH — we'll call it with its full path in the next step.
VMware cannot use a .dmg file directly. We need to convert BaseSystem.dmg to a .vmdk using QEMU.
Navigate to C:\Users\<username>\Documents\ in Explorer. Hold Shift and right-click the empty area of the window, then select "Open PowerShell window here".
& "C:\Program Files\qemu\qemu-img.exe" convert -O vmdk -o compat6 BaseSystem.dmg recovery.vmdkNote the exact syntax: This uses PowerShell's
&call operator to invoke the executable with its full path. The output file is namedrecovery.vmdk. The-o compat6flag ensures VMware compatibility.
The command produces no output while running. When it returns to the prompt with no error message, it succeeded.
Back in Explorer, your Documents folder should now show recovery.vmdk at approximately 1.72–1.8 GB.
By default, VMware Workstation does not allow macOS as a guest OS. Auto-Unlocker patches VMware's binaries to add macOS support.
⚠️ Fully close VMware before running Auto-Unlocker. Check Task Manager to make sure novmware.exeprocesses are running.
Download the latest release from GitHub: paolo-projects/auto-unlocker. Extract the zip — you'll see Unlocker.exe, a log file location, backup/, and tools/ folders.
Double-click Unlocker.exe. The GUI will open and auto-detect your VMware installation paths.
Verify the VMware install location and X64 location fields are populated, then click Patch. The tool will download required macOS tools and patch VMware's executables. When it finishes, close the window.
Open VMware Workstation. When creating a new VM, you should now see Apple Mac OS X as a guest OS option. If you don't see it, close VMware, re-run Unlocker as administrator, and try again.
With VMware patched, we can now create the virtual machine. The wizard has quite a few screens — follow each step exactly.
Open VMware. From the home screen, click Create a New Virtual Machine.
Select Custom (advanced) and click Next.
Select Workstation 17.5.x from the dropdown. Do not downgrade compatibility.
Select "I will install the operating system later." This skips the disc/ISO selection — we'll attach the recovery disk at the disk selection step below.
Select Apple Mac OS X as the guest OS, and choose macOS 12 from the Version dropdown.
If you don't see Apple Mac OS X in the list, Auto-Unlocker didn't patch successfully. Go back and re-run it.
Name the VM (e.g., macOS 12) and note the location. The .vmx file we'll edit later lives here.
- Number of processors:
1 - Number of cores per processor:
4
Don't assign too many cores. macOS VMs on AMD can be unstable with excessive vCPU counts. 4 is a stable, tested value.
Set to 8096 MB (8 GB). The minimum is 4 GB, but 8 GB gives a noticeably smoother experience.
Select Use network address translation (NAT).
Accept the defaults on the I/O Controller page. On the Select a Disk Type page, leave SATA selected (it's recommended — do not change to NVMe).
On the Select a Disk page, choose "Use an existing virtual disk".
Click Next, then Browse and navigate to C:\Users\<username>\Documents\recovery.vmdk.
VMware will ask if you want to convert the disk to a newer format. Click Keep Existing Format.
Review the summary. You should see:
- Hard Disk:
Existing disk C:\Users\...\Documents\recovery.vmdk - Memory: 8096 MB
- Network: NAT
- 4 CPU cores
Click Finish. Do not power on the VM yet.
The recovery VMDK is the installer/boot disk. macOS needs a separate disk to actually install onto. We'll add it now via VM Settings.
In VMware, right-click the new VM and select Settings. The Hardware tab shows the current devices.
Click Add... → Select Hard Disk → Click Next → Select SATA (recommended).
Select Create a new virtual disk.
Set the size to 80 GB (VMware's recommended size for macOS 12). Select Store virtual disk as a single file.
Accept the default filename and click Finish. The VM now has two SATA disks: the recovery.vmdk boot disk and a blank 80 GB install destination.
Still in VM Settings → Display → uncheck "Accelerate 3D graphics". This can cause instability on AMD during installation.
This section is what separates a successful AMD boot from hours of kernel panics. The .vmx is VMware's plain-text config file for the VM. We need to add entries that spoof the CPU identity and tune behavior for AMD.
Navigate to your VM's folder — for example:
C:\Users\Alex\Documents\Virtual Machines\macOS 12\macOS 12.vmx
Open it in a proper text editor. Use Notepad++ or VS Code. Do not use standard Notepad — it can corrupt line endings and mangle quotes into "smart quotes" that VMware cannot read.
⚠️ The VM must be powered off before editing. Save and close before powering on.
Add the following lines to the end of your .vmx file:
smc.version = "0"
cpuid.0.eax = "0000:0000:0000:0000:0000:0000:0000:1011"
cpuid.0.ebx = "0111:0101:0110:1110:0110:0101:0100:0111"
cpuid.0.ecx = "0110:1100:0110:0101:0111:0100:0110:1110"
cpuid.0.edx = "0100:1001:0110:0101:0110:1110:0110:1001"
cpuid.1.eax = "0000:0000:0000:0001:0000:0110:0111:0001"
cpuid.1.ebx = "0000:0010:0000:0001:0000:1000:0000:0000"
cpuid.1.ecx = "1000:0010:1001:1000:0010:0010:0000:0011"
cpuid.1.edx = "0000:0111:1000:1011:1111:1011:1111:1111"
mce.enable = "FALSE"
ulm.disableMitigations = "TRUE"You can verify the file looks right by checking the bottom section in your editor. Here's how the actual working .vmx looks, showing numvcpus, the CPUID block, and the final lines:
(note: Image is missing ulm.disableMitigations = "TRUE")
| Setting | Why it's needed |
|---|---|
smc.version = "0" |
Disables VMware's System Management Controller version check. Without this, macOS fails immediately at boot with no useful error. |
cpuid.0.* |
Encodes the string GenuineIntel in ASCII across the four 32-bit vendor registers. macOS checks for this exact string at boot and refuses to continue on AMD without it. |
cpuid.1.* |
Spoofs the CPU's family, model, stepping, and feature flags to match an Intel Ivy Bridge Core i7. macOS uses these to gate hardware feature usage. |
mce.enable = "FALSE" |
AMD's Machine Check Exception behavior differs from Intel's. Without this, macOS can trigger spurious kernel panics on AMD from MCE activity. |
ulm.disableMitigations = "TRUE" |
Disables Spectre/Meltdown CPU mitigations in the hypervisor layer. These interfere with macOS's Intel-specific CPU assumptions and cause instability on AMD. |
Make sure your .vmx config contains ulm.disableMitigations = "TRUE", VMware may show this warning on first boot otherwise:
VMware can overwrite your .vmx when you open VM Settings. To make edits permanent, add them through the UI instead:
VM → Settings → Options → Advanced → Configuration Parameters
Add each key-value pair there — these survive Settings saves.
Power on the VM. You'll see the VMware boot screen, then the Apple logo with a progress bar similar to the image below.
⏱️ The first boot from the recovery VMDK takes 3–5 minutes to reach the installer. Don't assume it's frozen unless nothing has changed for more than 10 minutes.
After the progress bar completes, the macOS installer will appear — Choose your language and click the arrow to continue.
Frst loading installation information, then showing the familiar Monterey logo.
Do not click "Install macOS Monterey" yet. The 80 GB disk you added is unformatted, and macOS cannot install to it without APFS formatting first.
From the menu bar, go to Utilities → Disk Utility (or it may appear as one of the options on the main screen).
In Disk Utility, select the VMware Virtual SATA Hard Drive Media — the 85+ GB uninitialized disk (not the 2.8 GB macOS Base System, which is the recovery VMDK).
Click Erase and configure:
- Name: anything you like (this guide used
osx) - Format:
APFS - Scheme:
GUID Partition Map
Click Erase. When done, you'll see the APFS container creation log and "Operation successful."
⚠️ APFS is required. macOS Monterey will not install to HFS+ and may fail silently if the disk format is wrong. Always use APFS + GUID Partition Map.
Close Disk Utility.
Click Install macOS Monterey and then Continue. Accept the license agreement.
On the disk selection screen, you'll see your freshly formatted disk alongside the macOS Base System. Select your formatted disk — the 85 GB one, not macOS Base System.
Click Continue. The installer copies files and the VM reboots automatically — this is normal.
⏱️ Total install time is typically 30–60 minutes including automatic reboots. The progress bar resets during phase transitions — this is normal and not a sign of failure.
After installation, the VM boots into the Setup Assistant — country/region, keyboard, Apple ID, and account creation.
You can skip Apple ID sign-in for a dev/test environment. Create a local account, finish setup, and you'll reach the desktop.
macOS Monterey is running on your AMD Windows machine. Take a snapshot before doing anything else.
Verify the install by clicking Apple menu → About This Mac:
This section documents the complete Ventura attempt — what we tried, in what order, and exactly why we stopped. If you're here at 2am Googling "macOS Ventura AMD VMware kernel panic", this is for you.
1. Downloaded Ventura and set up the VM using the same process.
The Ventura board ID (from the source guide, for reference):
py macrecovery.py -b Mac-27AD2F918AE68F61 -m 00000000000000000 downloadSetup went fine. The VM booted.
2. Ventura reached the language selection screen.
The first surprise: Ventura didn't immediately fail. It loaded the installer.
3. The installation ran and appeared to succeed.
Ventura installed onto the APFS-formatted disk. The progress bar completed. "About 12 minutes remaining" counted down. The file copy finished.
4. The VM rebooted for phase 2 of installation. Kernel panic.
After the first automatic reboot, the VM hit a kernel panic immediately — the multilingual dark screen reading "Your computer restarted because of a problem."
The VM looped: boot → kernel panic → boot → kernel panic. No error code. No useful output.
5. We tried Disk Utility First Aid.
Booted back into recovery and ran First Aid on the installed volume — maybe filesystem corruption from the panic?
First Aid reported no problems. The volume was fine. The kernel was the problem.
6. We tried the bless command to force the boot target.
From Terminal in recovery:
bless --mount /Volumes/OSX --setBoot
bless succeeded. Rebooted. Kernel panic. The issue was the kernel itself, not the boot target.
7. We added CPUID spoof values to the .vmx and tried again.
Following AMD VMware guides online, we added the full CPUID block to the .vmx file.
8. It got worse. The prohibited symbol appeared.
With CPUID spoofing in place, the kernel panic was replaced by the prohibited symbol — a black screen with 🚫 and support.apple.com/mac/startup.
This is a different and harder failure. The CPUID spoof passed the CPU vendor string check (GenuineIntel), but Ventura's kernel reached a deeper feature validation that AMD cannot satisfy — and failed earlier and harder than before.
9. VMware began generating additional errors.
The SATA error (sata0:1 can't connect) is a secondary symptom — VMware is trying to reconnect the CD-ROM device that was present in the original config. Click No and it goes away.
10. We pivoted to Monterey.
After exhausting the standard fixes, the diagnosis was clear: Ventura's XNU kernel performs CPU validation that CPUID spoofing cannot satisfy on AMD under VMware 17. This isn't a misconfiguration — it's a compatibility wall.
Why CPUID spoofing can't fix it — the actual root cause
After the fact, we found the technical explanation in the QuickEMU project wiki: macOS Ventura (13) and newer have stricter TSC (Time Stamp Counter) requirements than earlier versions. On affected AMD Ryzen mobile CPUs, the TSC is flagged as unstable during boot calibration, causing the kernel to panic with "Non-monotonic time" errors. CPUID spoofing tricks macOS about the CPU vendor, but it can't fix the TSC instability — that's a lower-level clock hardware issue that the kernel detects independently. Monterey predates the stricter TSC requirements, which is why the exact same CPUID config that fails on Ventura works perfectly on Monterey.
Affected CPUs: Ryzen 4000U (Renoir), 5000U (Cezanne/Lucienne), some Zen 4 mobile chips. Desktop AMD CPUs are generally not affected.
Monterey worked on the first try with the same config.
If you see the prohibited symbol on Monterey, check:
smc.version = "0"is in the.vmx- All CPUID lines are present and have no typos
- The
.vmxwasn't overwritten by VMware after you edited it — use Configuration Parameters in VM Settings to make edits permanent
Click No. This appears when VMware tries to connect the CD-ROM (sata0:1) that's no longer needed after installation. After a successful Monterey install, you can go to VM Settings and remove the CD/DVD device entirely.
Wait. macOS progress bar estimates are wildly inaccurate and the bar can appear frozen for many minutes during phase transitions. Give it at least 15 minutes before assuming it's actually stuck.
Boot from the recovery VMDK, open Terminal in recovery, and run:
# Check your volume name first
diskutil list
# Then bless it (replace "osx" with your volume name)
bless --mount /Volumes/osx --setBootBefore installing anything:
VM → Snapshot → Take Snapshot
Name it Fresh Install — Pre-Tools. This is your safe rollback point.
VMware Tools enables proper display scaling, clipboard sharing between host and guest, and better performance. The official VMware Tools installer is not bundled with VMware Workstation and Broadcom's support portal is notoriously painful to navigate, so we'll download the ISO directly from Broadcom's CDN.
On your Windows host, open a browser and go to:
https://packages-prod.broadcom.com/tools/frozen/darwin/
You'll see two ISO options. Download darwin.iso — not darwinPre15.iso. Despite what the name suggests, darwinPre15.iso is flagged as too old by the installer on Monterey. darwin.iso (updated November 2024) works correctly.
With the macOS VM powered on, go to VM → Settings → CD/DVD (SATA) in VMware:
- Select Use ISO image file
- Browse to the downloaded
darwin.iso - Check Connected
- Click OK
or
- Download the iso directy into OSX
- Mount the ISO by double clicking in downloads
- Click VMWare Tools on the Desktop to run the installer
The VMware Tools disk will mount on the macOS desktop.
On the macOS desktop, open the VMware Tools disk and double-click Install VMware Tools.
Click Continue through the installer steps.
macOS will block the VMware kernel extension and show this dialog:
Click Open Security Preferences. In the Security & Privacy panel you'll see:
"System software from developer 'VMware, Inc.' was blocked from loading."
Click on the Lock in the bottom left corner to allow changes then click on Allow.
Click Not Now. We'll restart after the installer has finished:
The installer will confirm success:
Now click on Restart to finish setting up VMWare Tools.
After this restart, display scaling and clipboard sharing between your Windows host and the macOS guest will work properly.
System Preferences → Displays — set 1920×1080 or 1440×900 depending on your host monitor.
macOS Monterey includes Python 3 via Xcode Command Line Tools:
xcode-select --installFor a Tkinter app, you'll also want Homebrew and the proper Python build:
# Install Homebrew
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
# Install Python with Tk support
brew install python-tkAfter setup you'll have a proper macOS login screen with your local account:
Fresh Install — Pre-Tools— right after first boot, before anythingVMware Tools Installed— after tools are working and display scales properlyDev Environment Ready— after Python, Homebrew, and dependencies are installedBefore Testing Session— before running your app tests each session
| Step | Key point |
|---|---|
| Use Monterey, not Ventura | Ventura's stricter TSC requirements cause kernel panics on AMD Ryzen mobile CPUs. Not fixable with CPUID spoofing. |
| QEMU command syntax matters | Use the full PowerShell path: & "C:\Program Files\qemu\qemu-img.exe" convert -O vmdk -o compat6 BaseSystem.dmg recovery.vmdk |
Output is recovery.vmdk |
Not BaseSystem.vmdk. The filename matters when you browse for it in the wizard. |
smc.version = "0" is non-negotiable |
Without it, the VM won't boot at all. |
| CPUID spoof is non-negotiable | Without it, macOS sees AMD and refuses to continue. |
mce.enable = "FALSE" matters on AMD |
Prevents spurious kernel panics from AMD MCE behavior mismatches. |
| Format the disk FIRST in Disk Utility | Do this before clicking Install. Use APFS + GUID Partition Map. |
| Adding CPUID to Ventura makes it worse | CPUID fixes the vendor string check but can't fix TSC instability. Changes the failure from kernel panic to prohibited symbol. Both are dead ends. |
| Take a snapshot before anything | Snapshots are cheap. Recovery from a bad install is not. |
- OpenCorePkg releases — source of
macrecovery.py - Auto-Unlocker — VMware macOS patcher
- QEMU for Windows — disk image conversion tool
- Original guide this was adapted from — bluebubbles-docs by BlueBubbles
- AMD OSX community — community knowledge for AMD macOS
- QuickEMU wiki — TSC instability on AMD Ryzen mobile CPUs — source of the TSC root cause explanation
Guide written based on a real installation attempt on Windows 11 Pro / AMD Ryzen / VMware Workstation Pro 17.5.2. All screenshots captured live during the process — including every failure. Adapted from the BlueBubbles deployment guide with AMD-specific fixes, a corrected QEMU command, and a documented Ventura troubleshooting sequence added.