03 Create macOS virtual machines

Automatically create macOS guests

Installing macOS in a VM can be a bit finicky, if you encounter problems, check the Discussions for solutions or ask for help there 🛟

quickget automatically downloads a macOS recovery image and creates a virtual machine configuration.

Note: Some VPN users may need to turn off their VPN in order to download a recovery image. Some other users may find using a VPN necessary in order to download a recover image.

quickget macos big-sur
quickemu --vm macos-big-sur.conf

macOS mojave, catalina, big-sur, monterey, ventura, sonoma, sequoia and tahoe are supported.

• Use cursor keys and enter key to select the macOS Base System
• From macOS Utilities
  • Click Disk Utility and Continue
    • Select QEMU HARDDISK Media (~103.08GB) from the list (on Big Sur and above use Apple Inc. VirtIO Block Device) and click Erase.
    • Enter a Name: for the disk
    • If you are installing macOS Mojave or later (Catalina, Big Sur, Monterey, Ventura and Sonoma), choose any of the APFS options as the filesystem. MacOS Extended may not work.
  • Click Erase.
  • Click Done.
  • Close Disk Utility
• From macOS Utilities
  • Click Reinstall macOS and Continue
• Complete the installation as you normally would.
  • On the first reboot use cursor keys and enter key to select macOS Installer
  • On the subsequent reboots use cursor keys and enter key to select the disk you named
• Once you have finished installing macOS you will be presented with an the out-of-the-box first-start wizard to configure various options and set up your username and password
• OPTIONAL: After you have concluded the out-of-the-box wizard, you may want to enable the TRIM feature that the computer industry created for SSD disks. This feature in our macOS installation will allow QuickEmu to compact (shrink) your macOS disk image whenever you delete files inside the Virtual Machine. Without this step your macOS disk image will only ever get larger and will not shrink even when you delete lots of data inside macOS.
  • To enable TRIM, open the Terminal application and type the following command followed by pressing enter to tell macos to use the TRIM command on the hard disk when files are deleted:

sudo trimforce enable

You will be prompted to enter your account's password to gain the privilege needed. Once you've entered your password and pressed enter the command will request confirmation in the form of two questions that require you to type y (for a "yes" response) followed by enter to confirm.

If you press enter without first typing y the system will consider that a negative response as though you said "no":

IMPORTANT NOTICE: This tool force-enables TRIM for all relevant attached devices, even though such devices may not have been validated for data integrity while using TRIM. Use of this tool to enable TRIM may result in unintended data loss or data corruption. It should not be used in a commercial operating environment or with important data. Before using this tool, you should back up all of your data and regularly back up data while TRIM is enabled. This tool is provided on an "as is" basis. APPLE MAKES NO WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, REGARDING THIS TOOL OR ITS USE ALONE OR IN COMBINATION WITH YOUR DEVICES, SYSTEMS, OR SERVICES. BY USING THIS TOOL TO ENABLE TRIM, YOU AGREE THAT, TO THE EXTENT PERMITTED BY APPLICABLE LAW, USE OF THE TOOL IS AT YOUR SOLE RISK AND THAT THE ENTIRE RISK AS TO SATISFACTORY QUALITY, PERFORMANCE, ACCURACY AND EFFORT IS WITH YOU.
Are you sure you with to proceed (y/N)?

And a second confirmation once you've confirmed the previous one:

Your system will immediately reboot when this is complete.
Is this OK (y/N)?

As the last message states, your system will automatically reboot as soon as the command completes.

The default macOS configuration looks like this:

guest_os="macos"
img="macos-big-sur/RecoveryImage.img"
disk_img="macos-big-sur/disk.qcow2"
macos_release="big-sur"

• guest_os="macos" instructs Quickemu to optimise for macOS.
• macos_release="big-sur" instructs Quickemu to optimise for a particular macOS release.
  • For example VirtIO Network and Memory Ballooning are available in Big Sur and newer, but not previous releases.
  • And VirtIO Block Media (disks) are supported/stable in Catalina and newer.

macOS compatibility

There are some considerations when running macOS via Quickemu.

• Supported macOS releases:
  • Mojave
  • Catalina
  • Big Sur
  • Monterey
  • Ventura
  • Sonoma
  • Sequoia
  • Tahoe
• quickemu will automatically download the required OpenCore bootloader and OVMF firmware from OSX-KVM.
  • Optimised by default, but no GPU acceleration is available.
  • Host CPU vendor is detected, and the guest CPU is optimised accordingly.
  • VirtIO Block Media is used for the system disk, where supported.
  • VirtIO usb-tablet is used for the mouse.
  • VirtIO Network (virtio-net) is supported and enabled on macOS Big Sur and newer, but earlier releases use vmxnet3.
  • VirtIO Memory Ballooning is supported and enabled on macOS Big Sur and newer, but disabled for other supported macOS releases.
• USB host and SPICE pass-through is:
  • UHCI (USB 2.0) on macOS Catalina and earlier.
  • XHCI (USB 3.0) on macOS Big Sur and newer.
• Display resolution can be changed via quickemu using --width and --height command line arguments.
• File sharing between guest and host is available via virtio-9p and SPICE webdavd.
• Copy/paste via SPICE agent is not available on macOS.

Audio support

Quickemu automatically selects the correct sound card based on macOS version:

macOS Version	Sound Card	Notes
Monterey, Ventura, Sonoma, Sequoia, Tahoe	virtio-sound-pci	Native VirtIO driver, works out-of-the-box
Big Sur	ich9-intel-hda	Requires VoodooHDA kext; unreliable from 11.3+
Catalina and earlier	intel-hda	Requires VoodooHDA kext

Key points:

• macOS 12 (Monterey) and later include a native VirtIO sound driver, so audio works without additional software.
• VoodooHDA stopped working reliably from macOS 11.3 onwards when injected via OpenCore.
• Big Sur audio remains problematic as a transitional version between the old HDA approach and native VirtIO support.
• For Big Sur and earlier, install VoodooHDA OC for audio support. Note that Gatekeeper and System Integrity Protection (SIP) must be disabled to install it.
• Alternatively, pass through a USB audio device to the macOS guest VM for reliable audio on any version.

TSC instability on AMD Ryzen mobile CPUs

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)

Older macOS versions (Big Sur and earlier) are more tolerant and typically work without issues.

Check if you're affected

Check your current clocksource:

cat /sys/devices/system/clocksource/clocksource0/current_clocksource

If it shows hpet or acpi_pm instead of tsc, your TSC has been marked unstable and you may experience issues with newer macOS versions.

You can also check dmesg for TSC warnings:

dmesg | grep -i tsc

Look for messages like "Marking TSC unstable" or "clocksource: timekeeping watchdog on CPU: Marking clocksource 'tsc' as unstable".

Workaround: tsc=reliable kernel parameter

If your TSC is marked unstable but actually stabilises after boot (common on affected CPUs), you can tell Linux to trust it by adding tsc=reliable to your kernel boot parameters.

For GRUB:

1. Edit /etc/default/grub
2. Add tsc=reliable to the GRUB_CMDLINE_LINUX_DEFAULT line
3. Run sudo update-grub (Debian/Ubuntu) or sudo grub-mkconfig -o /boot/grub/grub.cfg (Arch/Fedora)
4. Reboot

For systemd-boot:

1. Edit your loader entry in /boot/loader/entries/
2. Add tsc=reliable to the options line
3. Reboot

Verify it worked:

cat /proc/cmdline | grep tsc=reliable
cat /sys/devices/system/clocksource/clocksource0/current_clocksource  # Should now show 'tsc'

Alternative: use an older macOS version

If you prefer not to modify kernel parameters, macOS Big Sur (11) and earlier versions are more tolerant of TSC instability and should work without issues on affected hardware.

Important notes

• The tsc=reliable parameter is system-wide and affects all VMs, not just macOS
• Only use this workaround if your TSC stabilises after boot. If you experience ongoing time-related issues, this workaround may not be appropriate for your system
• BIOS updates sometimes improve TSC calibration - check if your manufacturer has updates available

For more technical details and discussion, see GitHub Issue #1273.

Apple ID Login

macOS VMs will usually be blocked from logging in with Apple IDs by default, due to the Serial, MAC Address, and other information being shared between multiple VMs.

To fix this, you can use the qe_mac_apid tool to replace or randomize these values in the bootloader.

macOS App Store

If you see "Your device or computer could not be verified" when you try to login to the App Store, make sure that your wired ethernet device is en0. Use ifconfig in a terminal to verify this.

If the wired ethernet device is not en0, then then go to System Preferences -> Network, delete all the network devices and apply the changes. Next, open a terminal and run the following:

sudo rm /Library/Preferences/SystemConfiguration/NetworkInterfaces.plist

Now reboot, and the App Store should work.

iPhone USB passthrough (Experimental)

Connecting an iPhone to a macOS VM for Xcode development is possible but requires additional configuration. This is an experimental feature with varying success rates depending on your hardware and host Linux distribution.

Important: This process is complex and may not work reliably. Consider it experimental and unsupported. For production iOS development, a physical Mac is recommended.

Prerequisites

• A Linux host (not macOS host)
• iPhone (iPads have lower success rates)
• USB cable (direct connection, not through a hub)
• Desktop computer (laptops report more issues)

Host configuration

1. Create udev rules for iPhone access

Create a udev rule to allow access to iPhone USB devices:

sudo nano /etc/udev/rules.d/97-iphone.rules

Add this line (replace your-group with your user's primary group):

SUBSYSTEMS=="usb", ATTRS{idVendor}=="05ac", ATTRS{idProduct}=="*", GROUP="your-group", MODE="0660"

Reload the udev rules:

sudo udevadm control --reload-rules

2. Stop conflicting services

The host's usbmuxd service will compete for the iPhone. Stop and disable it:

sudo systemctl stop usbmuxd
sudo systemctl mask usbmuxd

On some distributions, also stop:

sudo killall gvfs-afc-volume-monitor 2>/dev/null

VM configuration

Add the iPhone to your macOS VM configuration:

guest_os="macos"
disk_img="macos-sonoma/disk.qcow2"
img="macos-sonoma/RecoveryImage.img"
macos_release="sonoma"
display="gtk"
usb_devices=("05ac:12a8")

Note: The product ID 12a8 is common for iPhones, but yours may differ. Find your iPhone's ID with:

lsusb | grep -i apple

Limitations

• Disconnect/reconnect loops: The iPhone may repeatedly disconnect and reconnect. Enabling flight mode on the iPhone sometimes helps
• Trust dialog timing: You may need to quickly tap "Trust" on the iPhone when the dialog appears
• Xcode detection: Even when connected, Xcode may not detect the device reliably
• iPads: Generally have lower success rates than iPhones

Alternative: Wireless debugging

For a more reliable workflow, consider using Xcode's wireless debugging feature instead of USB passthrough. After pairing the device once on a physical Mac, you can use wireless debugging from the VM.

Troubleshooting

If you see LIBUSB_ERROR_NOT_FOUND or "Device is in use by another application":

1. Verify usbmuxd is stopped: systemctl status usbmuxd
2. Check no other process has claimed the device: lsof /dev/bus/usb/*/*
3. Try a different USB port (USB 2.0 ports sometimes work better)
4. Reboot the host and try again

For detailed troubleshooting and community solutions, see issue #468.