Installing macOS 11 “Big Sur” on Proxmox 6

This tutorial for installing macOS Big Sur Final using OpenCore has been adapted for Proxmox from Kholia’s OSX-KVM project and Leoyzen’s OpenCore configuration for KVM. You can get the full sourcecode on my GitHub here.


I’ll assume you already have Proxmox 6 installed. You also need a real Mac available in order to fetch the OSK key.

Your Proxmox host computer’s CPU must support SSE 4.2, so for Intel your CPU must be at least as new as Nehalem, which was the first CPU generation to bear the “Core” i5/i7 branding. Older CPUs will cause the finder to repeatedly crash after installation completes (with an Illegal Instruction exception in the graphics code).

Modern AMD CPUs also support SSE 4.2 and will work with this guide.

First step: Create an installation ISO

Download my copy of the OSX-KVM repository using the download button, and unzip it:

First we need to install some build requirements. If you will be building the installer ISO on macOS, open up the Terminal and run this command to install the commandline tools:

xcode-select --install

If you’re building the ISO on Linux, you instead need to run this command (these are the package names for Ubuntu or similar distributions, they may need adjustment on other distributions):

sudo apt install qemu-utils make

Now in the Terminal, from the root of OSX-KVM, run:

cd scripts/bigsur
make BigSur-recovery.img

This will download the Big Sur installer from Apple’s software distribution servers and build a BigSur-recovery.img file for you. Upload this file to your Proxmox’s ISO store directory (typically /var/lib/vz/template/iso). Although we’re putting it in the ISO directory so that we can use it with Proxmox’s ISO picker later, this a raw disk image rather than a true ISO.

If you’re building the installer on macOS, you can build a full installer instead of just a recovery, which will mean that macOS won’t have to download Big Sur files during installation, and so won’t require an Internet connection. Simply ask it to build BigSur-full.img instead:

cd scripts/bigsur
make BigSur-full.img

This option is not available when building the installer on Linux.

Prepare an OpenCore image

Download the OpenCore.iso.gz file from the newest release in my repository (that says it’s Big Sur compatible), double click it to unpack it, and upload it to Proxmox’s ISO store at /var/lib/vz/template/iso. Although it has a .iso file extension, this is actually a hard disk image. (You need v12 or newer for Big Sur 11.3 or newer)

Fetch the OSK authentication key

macOS checks that it is running on real Mac hardware, and refuses to boot on third-party hardware. You can get around this by reading an authentication key out of your real Mac hardware (the OSK key). Save the first block of C code from this page as smc_read.c. In a command prompt, change into the same directory as that file and run:

xcode-select --install # If you don't already have gcc
gcc -o smc_read smc_read.c -framework IOKit

It’ll print out the 64 character OSK for you. Make a note of it.

Every Mac uses the same OSK, so don’t be surprised that it doesn’t look like a random string!

Create the VM

From the Proxmox web UI, create a new virtual machine as shown below.

In the Options page for the VM, ensure that “use tablet for pointer” is set to “Yes”.

In the Hardware page for the VM, add a second DVD drive at IDE0, set it to use your BigSur-full.img or BigSur-recovery.img.

Don’t try to start the VM just yet. First, SSH into your Proxmox server so we can make some edits to the configuration files.

Edit /etc/pve/qemu-server/YOUR-VM-ID-HERE.conf (with nano or vim). Add this line, being sure to substitute the OSK you extracted earlier into the right place:

args: -device isa-applesmc,osk="THE-OSK-YOU-EXTRACTED-GOES-HERE" -smbios type=2 -device usb-kbd,bus=ehci.0,port=2

A USB keyboard is added here because macOS doesn’t support QEMU’s default PS/2 keyboard. Ensure the args are all on a single line!

We also need to add a -cpu argument. If your host CPU is Intel, add this to the end of the “args” line:

-cpu host,kvm=on,vendor=GenuineIntel,+kvm_pv_unhalt,+kvm_pv_eoi,+hypervisor,+invtsc

This will pass through all of the features that your CPU supports. OpenCore’s config will pretend to macOS that the CPU’s model name is Penryn for compatibility.

If your host CPU is AMD, or the above argument doesn’t work for you, use this more-compatible alternative:

-cpu Penryn,kvm=on,vendor=GenuineIntel,+kvm_pv_unhalt,+kvm_pv_eoi,+hypervisor,+invtsc,+pcid,+ssse3,+sse4.2,+popcnt,+avx,+avx2,+aes,+fma,+fma4,+bmi1,+bmi2,+xsave,+xsaveopt,check

This pretends that your CPU is Penryn, which will keep macOS happy even if your host CPU is AMD, and adds a bunch of newer required and optional CPU features on top. Features that your host CPU doesn’t support will be ignored (a warning will be printed to the console during launch with qm start 1xx), but note that macOS won’t work without SSE4.2 support.

Now find the lines that define the two “ISOs” (ide0 and ide2), and remove the “,media=cdrom” part from them. Add “,cache=unsafe” in its place. This will treat these as hard disks rather than DVD drives.

Save your changes, return to the Options tab, and change the boot order to put IDE2 (the OpenCore image) first. Your final VM configuration file should resemble this:

args: -device isa-applesmc,osk="..." -smbios type=2 -device usb-kbd,bus=ehci.0,port=2 -cpu host,kvm=on,vendor=GenuineIntel,+kvm_pv_unhalt,+kvm_pv_eoi,+hypervisor,+invtsc
balloon: 0
bios: ovmf
bootdisk: ide2
cores: 4
cpu: Penryn
efidisk0: vms:vm-100-disk-1,size=1M
ide0: isos:iso/BigSur-full.img,cache=unsafe,size=2094688K
ide2: isos:iso/OpenCore-v10.img,cache=unsafe,size=150M
machine: q35
memory: 4096
name: bigsur
net0: vmxnet3=...,bridge=vmbr0,firewall=1
numa: 1
ostype: other
virtio0: vms:vm-100-disk-0,cache=unsafe,discard=on,size=64G
scsihw: virtio-scsi-pci
smbios1: uuid=...
sockets: 1
vga: vmware

Configure Proxmox

On Proxmox, run “echo 1 > /sys/module/kvm/parameters/ignore_msrs” to avoid a bootloop during macOS boot. To make this change persist across Proxmox reboots, run:

echo "options kvm ignore_msrs=Y" >> /etc/modprobe.d/kvm.conf && update-initramfs -k all -u

Install Big Sur

Now start up your VM, it should boot to the OpenCore boot picker:

Press enter to boot the “Install macOS Beta” entry and the installer should appear.

OpenCore’s “OpenCanopy” boot picker

If you built a recovery installer, the icon will instead be an image of a hard disk and be labelled “MacOS Base System”.

Our virtual hard drive needs to be erased/formatted before we can install to it, so select the Disk Utility option. Follow the steps below to format the disk:

Now we’re ready to begin installation!

After the first stage of installation, the VM will reboot 3 or 4 times in quick succession, and each time you must pick the “macOS Installer” entry (the second one here, with the hard disk icon) to continue installation. It will not be selected for you automatically:

If your keyboard isn’t responding on this screen, exit the Console tab in Proxmox and re-enter it. If you get a “prohibited” sign like this appearing, hit the Reset button on the VM to try again:

Now the installation is complete and the macOS Installer entry disappears, so pick the name of your main disk to boot (mine’s called Main).

Answer the initial install questions, and you’ll be logged on! Note that you might want to hold off on logging into your Apple ID until you’ve configured your Mac’s serial number in OpenCore.

It works!

Note that it will be really sluggish for a few minutes after the first boot while the system performs housekeeping tasks.

Make the OpenCore install permanent

We’re currently booting using OpenCore from the attached OpenCore ISO. Let’s install that to the hard drive instead. Pop open Terminal and run “diskutil list” to see what drives we have available.

Use “sudo dd if=<source> of=<dest>” to copy the “EFI” partition from the OpenCore CD and overwrite the EFI partition on the hard disk. The OpenCore CD is the small disk (~150MB) that only has an EFI partition on it, and the main hard disk is the one with the large (>30GB) Apple_APFS “Container” partition on it.

In my case these EFI partitions ended up being called disk2s1 and disk0s1 respectively, so I ran “sudo dd if=/dev/disk2s1 of=/dev/disk0s1” (note that if you get these names wrong, you will overwrite the wrong disk and you’ll have to start the installation over again!).

Now shut down the VM, and remove both the OpenCore and the Big Sur installer drives from the Hardware tab. On the Options tab, edit the boot order to place your virtio0 disk as the first disk. Boot up. If everything went well, you should see the OpenCore boot menu, and you can select your “Main” disk to boot Big Sur:

Sleep management

I found that I was unable to wake Big Sur from sleep using my mouse or keyboard. If you encounter the same problem, you can either disable system sleep in Big Sur’s Energy Saver settings to avoid the issue, or you can manually wake the VM up from sleep from Proxmox by running:

qm monitor YOUR-VM-ID-HERE 

Editing your OpenCore/EFI settings

The Configuration.pdf that explains the OpenCore config.plist file can be found along with the OpenCore release on my GitHub.

To mount your EFI partition in macOS so you can edit your config.plist, first check the “identifier” of your EFI partition in the terminal:

~$ diskutil list
/dev/disk0 (external, physical):
   #:                   TYPE NAME              SIZE       IDENTIFIER
   0:  GUID_partition_scheme                  *512.1 GB   disk0
   1:                    EFI EFI               209.7 MB   disk0s1
   2:             Apple_APFS Container disk1   511.9 GB   disk0s2

Then you can mount it like so:

sudo mkdir /Volumes/EFI
sudo mount -t msdos /dev/disk0s1 /Volumes/EFI

Now you can edit /Volumes/EFI/OC/config.plist with your favourite text editor to make your changes. (TextEdit is not a great choice because it likes to insert curly quotes into the file and otherwise break things, there are some dedicated plist editors available such as XCode).

If you’re unable to boot macOS, you can edit the config.plist using the “UEFI Shell” option in the OpenCore boot menu instead.

Enter “FS0:” and press enter to open up the first available filesystem, then run “edit EFI\OC\config.plist” (if the file isn’t found, try switching to another filesystem like fs1:). When you’re done editing, press control+Q to exit, “Y” to save, then run “exit” to return to the OpenCore menu. You need to reboot for your changes to take effect.

If you prefer, you can edit config.plist from the comfort of your Proxmox host instead. If you’re booting from an attached OpenCore.img file, you can mount that file as a disk on the host. If you’re booting from the VM’s disk instead, it must be in raw format in order to be mounted (e.g. typical LVM or ZFS usage) rather than qcow2.

# Mount an OpenCore image:
losetup --partscan /dev/loop0 /var/lib/vz/template/iso/OpenCore-v11.img
# or a VM boot disk:
losetup --partscan /dev/loop0 /dev/zvol/tank/vms/vm-100-disk-1

mount /dev/loop0p1 /mnt

Now the contents of that first partition are available in /mnt, so you can edit /mnt/EFI/OC/config.plist in your favourite editor. When you’re done, do this to unmount the disk:

umount /mnt
losetup --detach /dev/loop0

Automatic boot

In config.plist, you can set Misc/Boot/Timeout to a non-zero value to allow the default boot option be chosen automatically after that delay in seconds. I’ve disabled this by default because it causes the installer ISO to re-enter its main menu instead of continuing the second stage of installation.

You can set the default boot option by pressing control+enter on it.

Verbose boot

To boot macOS in Verbose mode to diagnose boot problems, at the OpenCore boot menu press Cmd+V before pressing enter to boot macOS (you don’t need to hold it down).

If there is a kernel panic during boot and it reboots too quickly to be read, edit config.plist to add “debug=0x100” to the kernel arguments.

Changing screen resolution

To change macOS’ screen resolution, you need to edit the UEFI/Output/Resolution setting in config.plist, the default is 1920×1080@32.

You should be able to change this to any of the modes that the system OVMF menu offers (hit F2 at the start of guest boot and choose “Device Manager/OVMF Platform Configuration” to see which resolutions are available).

Video performance

Because there is no guest video acceleration available for macOS, video performance is poor.

In Google Chrome in the guest you will need to toggle off the setting to “use hardware acceleration when available” to improve issues with elements not being drawn or flickering (especially video). Safari may be a better choice.

macOS’s built in “Screen Sharing” feature offers dramatically better framerates and latency than Proxmox’s browser-based VNC console, so if you have a real Mac to act as a viewing console, you can enable that in the VM’s “Sharing” settings and connect to the VM using the Screen Sharing app from your Mac instead:

Apparently Screen Sharing is also compatible with VNC clients like RealVNC, so you should be able to connect to it from Linux or Windows consoles using RealVNC.

The real magic bullet for video performance is to pass through a compatible video card using PCIe passthrough (though note that Big Sur, like Catalina, does not support most NVidia cards). This offers near-native performance. You can read more about how I’m using PCIe passthrough on my own installation here.

USB passthrough

Since I want to use this as my primary computer, I want to use a USB keyboard and mouse plugged directly into Proxmox, rather than sending my input through the web VNC console.

Proxmox has good documentation for USB passthrough. Basically, run “qm monitor YOUR-VM-ID-HERE”, then “info usbhost” to get a list of the USB devices connected to Proxmox:

qm> info usbhost
Bus 3, Addr 12, Port 6, Speed 480 Mb/s
Class 00: USB device 8564:1000, Mass Storage Device
Bus 3, Addr 11, Port 5.4, Speed 12 Mb/s
Class 00: USB device 04d9:0141, USB Keyboard
Bus 3, Addr 10, Port 5.1.2, Speed 12 Mb/s
Class 00: USB device 046d:c52b, USB Receiver
Bus 3, Addr 9, Port 14.4, Speed 12 Mb/s
Class 00: USB device 046d:c227, G15 GamePanel LCD
Bus 3, Addr 8, Port 14.1, Speed 1.5 Mb/s
Class 00: USB device 046d:c226, G15 Gaming Keyboard

In this case I can add my keyboard and mouse to USB passthrough by quitting qm, then running:

qm set YOUR-VM-ID-HERE -usb1 host=04d9:0141
qm set YOUR-VM-ID-HERE -usb2 host=046d:c52b

This saves the devices to the VM configuration for you. You need to reboot to have the new settings apply. Note that the emulated USB3 device doesn’t work with macOS, so don’t set “usb3=1”.

You can also pass through USB devices by passing through an entire USB controller using Proxmox’s PCIe passthrough feature, which gives much better compatibility.


FileVault login prompt at boot

FileVault now works with OpenCore, so you can encrypt your boot disk by using the option in macOS’ system security preferences. But be certain to keep a copy of your recovery key and keep your backups up to date.

Fixing “guest boots to UEFI shell”

If your guest ends up booting to the UEFI shell instead of showing the OpenCore boot menu, especially if you’ve just updated OpenCore to a new version, you’ll need to edit the guest’s UEFI boot entries to fix this.

At the very start of guest boot, hit F2 to enter guest UEFI settings.

First we’ll remove the old entries. Choose the Boot Maintenance option, then Boot Options -> Delete Boot Option. Use the spacebar to tick any old Clover or OpenCore entries (avoid ticking the EFI Internal Shell option, you want to keep that!). Select “Commit Changes and Exit”.

Now we’ll add the correct entry for OpenCore back in. Select Add Boot Option. Navigate through the device tree to EFI/OC/OpenCore.efi (use EFI/BOOT/BOOTx64.efi instead on my “OpenCore v10” and older) and select it, name this new option “OpenCore” or similar. Again Commit Changes and Exit.

Go to the Change Boot Order and move OpenCore to the top. Commit Changes and Exit.

Now back out to the main menu and choose Reset, and you should successfully boot into OpenCore this time.

Fixing iMessage

iCloud and the App Store should already be working for you, but for iMessage support you must follow these steps to mark your network adapter as built-in:

Disabling SIP (System Integrity Protection)

You can disable SIP by selecting the Recovery option from the OpenCore boot menu, then use the top menu to open the Terminal and run “csrutil disable”. Then reboot.

This may be needed to run unsigned kexts or perform other hacks.

Upgrading OpenCore

Sometimes you need to update OpenCore to a new release in order to support a new macOS update. I’ll assume you don’t have any customisations to config.plist you want to save.

First take a snapshot! It’s great to be able to roll back if something goes wrong.

If you’re still able to boot macOS, you can update it from within the guest. Follow the instructions in the “Editing your OpenCore/EFI settings” section to mount your EFI partition. Then you can delete the EFI folder in there and replace it with the one from the file from my OpenCore release (you’ll probably need to empty the trash to make room for the new folder). You’re done!

If you aren’t able to boot macOS, unpack and upload the new OpenCore ISO to Proxmox’s ISO store instead. Add a new CD drive to the VM that uses that ISO. Then in Proxmox’s terminal edit the VM’s config (in /etc/pve/qemu-server) to replace “media=cdrom” with “cache=unsafe” for the OpenCore drive. Now on the “Options” tab, change the boot order to put the new OpenCore drive first.

Start the VM and boot into macOS using the new OpenCore drive. From within macOS you can now follow the instructions from the “Make the OpenCore install permanent” section to install the new OpenCore image to your main macOS disk, after which the OpenCore drive can be detached from the VM.

Upgrading from macOS Catalina

First make a backup or snapshot of your system! Being able to roll back when the upgrade goes wrong is a real lifesaver.

You’ll need to update OpenCore to my v10 release before the upgrade. You can follow the instructions in the “Editing your OpenCore settings” section above to mount your EFI disk. Then you can replace the OpenCore files in the mounted “EFI” disk with the ones from the file in my newest OpenCore release.

Reboot to make sure that you can still boot Catalina.

If you’re using any PCIe passthrough devices (particularly video cards) you’ll want to disable those and set “vga: vmware” instead, so you can install using Proxmox’s web console from a different machine during the upgrade. This avoids installer problems triggered by flaky video card passthrough, especially host lockups caused by the AMD Reset Bug.

Now you can upgrade to Big Sur using the App Store like you would on a real Mac.

342 thoughts on “Installing macOS 11 “Big Sur” on Proxmox 6”

  1. Hi, I’m getting “Cannot connect to server” when trying to sign in to iCloud. Whats the fix? Thanks.

  2. Hi Nicholas,
    Thanks again for your guides. I’ve used them several times before and have been on my Mojave build for a while, and finally got going with Big Sur. Things are working great as long as I don’t attach my GPU (Radeon Pro WX 4100). The GPU works fine with my Mojave VM, but not Big Sur. If I keep the vmware vga set and passthrough the GPU, the vnc instance shows it loading to about 30% and hanging, but my monitor will light up with my background so I know that’s working. In verbose, I’m not seeing anything that really tells me what the problem could be. I’ve also installed the reset bug fix, but that didn’t help.

    Here’s my qemu config:
    agent: 1
    args: -device isa-applesmc,osk=”” -smbios type=2 -device usb-kbd,bus=ehci.0,port=2 -cpu host,kvm=on,vendor=GenuineIntel,+kvm_pv_unhalt,+kvm_pv_eoi,+hypervisor,+invtsc
    balloon: 0
    bios: ovmf
    boot: order=virtio0
    cores: 8
    cpu: Penryn
    efidisk0: local-qemu:1016/vm-1016-disk-1.raw,size=128K
    hostpci0: 0000:01:00,pcie=1,x-vga=1
    hostpci1: 0000:00:14,pcie=1
    machine: q35
    memory: 24576
    name: derek-osx-bigsur
    net0: vmxnet3=BA:4E:F8:92:BA:E4,bridge=vmbr0
    numa: 1
    ostype: other
    scsihw: virtio-scsi-pci
    smbios1: uuid=4d9220ae-a60d-422e-bade-1bbab0d9428b
    sockets: 1
    vga: vmware
    virtio0: local-qemu:1016/vm-1016-disk-0.raw,cache=unsafe,size=150G
    vmgenid: 52258d4c-9920-4b58-a72d-6bb7671cb570

    Here is dmesg from my PVE host:
    [ 1367.939388] vfio-pci 0000:01:00.0: AMD_POLARIS11: version 1.1
    [ 1367.939389] vfio-pci 0000:01:00.0: AMD_POLARIS11: performing pre-reset
    [ 1367.959376] vfio-pci 0000:01:00.0: AMD_POLARIS11: performing reset
    [ 1367.959381] vfio-pci 0000:01:00.0: AMD_POLARIS11: CLOCK_CNTL: 0x0, PC: 0x2994
    [ 1367.959382] vfio-pci 0000:01:00.0: AMD_POLARIS11: performing post-reset
    [ 1367.999306] vfio-pci 0000:01:00.0: AMD_POLARIS11: reset result = 0
    [ 1368.383247] device tap1016i0 entered promiscuous mode
    [ 1368.389247] vmbr0: port 2(tap1016i0) entered blocking state
    [ 1368.389248] vmbr0: port 2(tap1016i0) entered disabled state
    [ 1368.389323] vmbr0: port 2(tap1016i0) entered blocking state
    [ 1368.389323] vmbr0: port 2(tap1016i0) entered forwarding state
    [ 1370.743261] vfio-pci 0000:01:00.0: enabling device (0400 -> 0403)
    [ 1370.743411] vfio-pci 0000:01:00.0: AMD_POLARIS11: version 1.1
    [ 1370.743412] vfio-pci 0000:01:00.0: AMD_POLARIS11: performing pre-reset
    [ 1370.763285] vfio-pci 0000:01:00.0: AMD_POLARIS11: performing reset
    [ 1370.763290] vfio-pci 0000:01:00.0: AMD_POLARIS11: CLOCK_CNTL: 0x0, PC: 0x2880
    [ 1370.763291] vfio-pci 0000:01:00.0: AMD_POLARIS11: performing post-reset
    [ 1370.803237] vfio-pci 0000:01:00.0: AMD_POLARIS11: reset result = 0
    [ 1370.803359] vfio-pci 0000:01:00.0: vfio_ecap_init: hiding ecap 0x19@0x270
    [ 1370.803366] vfio-pci 0000:01:00.0: vfio_ecap_init: hiding ecap 0x1b@0x2d0
    [ 1370.803372] vfio-pci 0000:01:00.0: vfio_ecap_init: hiding ecap 0x1e@0x370
    [ 1371.007316] vfio-pci 0000:01:00.0: AMD_POLARIS11: version 1.1
    [ 1371.007317] vfio-pci 0000:01:00.0: AMD_POLARIS11: performing pre-reset
    [ 1371.007427] vfio-pci 0000:01:00.0: AMD_POLARIS11: performing reset
    [ 1371.007431] vfio-pci 0000:01:00.0: AMD_POLARIS11: CLOCK_CNTL: 0x0, PC: 0x2880
    [ 1371.007432] vfio-pci 0000:01:00.0: AMD_POLARIS11: performing post-reset
    [ 1371.047232] vfio-pci 0000:01:00.0: AMD_POLARIS11: reset result = 0
    [ 1371.363026] vfio-pci 0000:01:00.0: No more image in the PCI ROM
    [ 1371.363050] vfio-pci 0000:01:00.0: No more image in the PCI ROM
    [ 1390.183894] kvm_get_msr_common: 46 callbacks suppressed
    [ 1390.183895] kvm [5335]: vcpu0, guest rIP: 0xffffff800d031d75 ignored rdmsr: 0x60d
    [ 1390.183902] kvm [5335]: vcpu0, guest rIP: 0xffffff800d031d75 ignored rdmsr: 0x3f8
    [ 1390.183906] kvm [5335]: vcpu0, guest rIP: 0xffffff800d031d75 ignored rdmsr: 0x3f9
    [ 1390.183909] kvm [5335]: vcpu0, guest rIP: 0xffffff800d031d75 ignored rdmsr: 0x3fa
    [ 1390.183912] kvm [5335]: vcpu0, guest rIP: 0xffffff800d031d92 ignored rdmsr: 0x630
    [ 1390.183915] kvm [5335]: vcpu0, guest rIP: 0xffffff800d031d92 ignored rdmsr: 0x631
    [ 1390.183918] kvm [5335]: vcpu0, guest rIP: 0xffffff800d031d92 ignored rdmsr: 0x632
    [ 1390.183921] kvm [5335]: vcpu0, guest rIP: 0xffffff800d031d92 ignored rdmsr: 0x619
    [ 1390.183924] kvm [5335]: vcpu0, guest rIP: 0xffffff800d031d92 ignored rdmsr: 0x61d
    [ 1390.183927] kvm [5335]: vcpu0, guest rIP: 0xffffff800d031d92 ignored rdmsr: 0x621
    [ 1397.273420] kvm_get_msr_common: 146 callbacks suppressed
    [ 1397.273422] kvm [5335]: vcpu7, guest rIP: 0xffffff800d031d75 ignored rdmsr: 0x60d
    [ 1397.273428] kvm [5335]: vcpu7, guest rIP: 0xffffff800d031d75 ignored rdmsr: 0x3f8
    [ 1397.273431] kvm [5335]: vcpu7, guest rIP: 0xffffff800d031d75 ignored rdmsr: 0x3f9
    [ 1397.273434] kvm [5335]: vcpu7, guest rIP: 0xffffff800d031d75 ignored rdmsr: 0x3fa
    [ 1397.273437] kvm [5335]: vcpu7, guest rIP: 0xffffff800d031d92 ignored rdmsr: 0x630
    [ 1397.273439] kvm [5335]: vcpu7, guest rIP: 0xffffff800d031d92 ignored rdmsr: 0x631
    [ 1397.273441] kvm [5335]: vcpu7, guest rIP: 0xffffff800d031d92 ignored rdmsr: 0x632
    [ 1397.273444] kvm [5335]: vcpu7, guest rIP: 0xffffff800d031d92 ignored rdmsr: 0x619
    [ 1397.273446] kvm [5335]: vcpu7, guest rIP: 0xffffff800d031d92 ignored rdmsr: 0x61d
    [ 1397.273449] kvm [5335]: vcpu7, guest rIP: 0xffffff800d031d92 ignored rdmsr: 0x621

    And lastly, here a screenshot of verbose OpenCore output during boot. The boot process is halted from here, but I can see my Big Sur background image showing on the monitor attached to the GPU (WX 4100).

    Only change I’ve made to my config.plist is setting an autoboot of 3 seconds, otherwise it’s untouched. I’m running PVE 6.4-8, fully updated. If I remove “hostpci0: 0000:01:00,pcie=1,x-vga=1” from my qemu config, Big Sur will boot up just fine in the PVE console session.

    Any ideas?? Thanks!!!!

    1. Do you know if your Mojave config.plist has any extra kernel args added? I’m wondering if you had added a Whatevergreen flag that is missing in your new Big Sur config

      1. Thanks for your quick response. It’s been so long since I setup this Mojave build (it’s really been rock solid) that I don’t recall. But I fired up Clover and took a look, and not really seeing anything special. Took screenshots, threw in an imgur album:

        Here’s the config.plist from my Mojave build EFI volume:

        I don’t see any kexts, at all, on my EFI volume but I feel like I had to load a few kexts using kextbeast. Looking in /Library/Extensions, all I’m really seeing that stands out is Lilu, which is on my Big Sur EFI volume already (along with Whatevergreen), but Whatevergreen is NOT on my Mojave build (best I can tell).


        1. I have tried so many things (re-registering kexts, updated boot args, etc) and am unable to get any change in my experience. I’m on the verge of giving up and sticking with Mojave until my hardware dies…

          1. You could keep the vmware vga attached as a workaround. The GPU display currently only shows your background because it’s your secondary display, you should be able to drag windows over to it from the virtual display.

            In macOS system display settings, on the Arrangement tab you can drag the white dock over to the GPU monitor to designate it as your primary display instead.

            1. Unfortunately, when I connect the GPU via pass through and use the vga console, it won’t boot fully. I have a screenshot linked in my original comment that shows verbose boot output. Where it’s hanging at is where I can see the gpu showing the background, but the primary screen (virtual vga) doesn’t make it to the login screen. 🙁

  3. Nice guide except I’m having a problem following it you say to use penryn for the cpu however that’s not an option for me.

    1. You can actually pick any option here for the CPU setting, because it’ll be overwritten later by the “args” option.

  4. Hi Nick,

    Been trying to get this to work for the past few hours. I have a ryzen 5950x and an nvme drive running proxmox 6.4 (latest). I was trying to virtualize big sur 11.4, i created the iso file on my mac. I can get opencore to boot but I never see the OSX install icon when the VM boots. The only thing i could not do while following your tutorial is for hard disk, I could not put “vms”, I had to use local-lvm (only option given).

    Any idea where I went wrong?

    args: -device isa-applesmc,osk=”o…c” -smbios type=2 -device usb-kbd,bus=ehci.0,port=2 -cpu Penryn,kvm=on,vendor=GenuineIntel,+kvm_pv_unhalt,$
    balloon: 0
    bios: ovmf
    boot: order=ide2;ide0;virtio0;net0
    cores: 8
    cpu: Penryn
    efidisk0: local-lvm:vm-103-disk-1,size=4M
    ide0: local:iso/BigSur.iso,cache=unsafe,size=15000M
    ide2: local:iso/OpenCore-v13.iso,cache=unsafe,size=150M
    machine: q35
    memory: 8192
    name: bs004
    net0: vmxnet3=02:AC:FA:C1:91:70,bridge=vmbr0,firewall=1
    numa: 1
    ostype: other
    scsihw: virtio-scsi-pci
    smbios1: uuid=d…
    sockets: 1
    vga: vmware
    virtio0: local-lvm:vm-103-disk-0,cache=unsafe,size=64G
    vmgenid: d…

    1. > I could not put “vms”,

      That’s just the name I gave to my Proxmox storage, it’s fine for it not to match.

      Did you use my script to create your install image? If not, it probably isn’t formatted correctly, and that’s why it doesn’t appear in the OpenCore menu. The image needs to be formatted GPT to work.

  5. Hi,

    Thanks for your guide and github repo.

    I tried to use the VirtIO network card… and it’s working ! On Proxmox, I setup the multiqueue parameter to 8 for the VM’s network card. On other VM this increase greatly the performance, I didn’t test to much on MacOS for now.

    The last stuff missing are the audio and the QXL driver. For the audio, maybe the hackingtosh people could have a driver for one of the 3 audio card emulated by Qemu.

    I also activated the balooning option on the RAM and I didn’t got any problem or alert, but i’m not sure the thing is used/working.


    The last

  6. Hi nick!

    I followed all your steps and everything seemed okay until the step:
    – “In the Hardware page for the VM, add a second DVD drive at IDE0, set it to use your BigSur-full.img or BigSur-recovery.img.”

    I can see the BigSur-recovery.img in /var/lib/vz/template/iso/, but I’m not seeing it on proxmox UI when I’m trying create a DVD drive and to set it to use for that .img. I can see all other isos I have, but not BigSur-recovery.img

    Can you please help me?
    Thanks in advance!

    1. Check that your uploaded file didn’t end up with weird rights like not being world-readable.

      You can “chmod 0644 /var/lib/vz/template/iso/BigSur-recovery.img” to clean that up for example.

      Also, reload the page, your browser caches the list of ISOs when the dropdown box is first rendered.

  7. How do I change the serial number for my device? It’s still showing the one from your Opencore.

  8. wow Nicholas,

    Many thanks for this 100% working, and also great looking manual:
    a 100% percent working manual to virtualize the latest version of MacOS on a AMD host is a rarity, but you succeeded!

    I set my BigSur up in about 2 hours, and added video and USB pass through (a OSX natively supported Radeon 570 ). Also working !

    (cheap, but exellent) proxmox hardware:
    MoBo: AsRock X470 master sli
    Cpu: AMD Ryzen 7 2700 (8c,16thd)
    Mem: 2x16GB, Corsair Vengeance LPX , DDR4, 3200MHz
    Vid: Radeon RX570

    Thanks again!!

  9. Hiya, I got this up and running on a proxmox cloud install no problem. I was wondering: I want to install proxmox 6.4 on my MacBook Pro (15-inch, 2018), and set this exact same thing up but on the mac.

    Sounds stupid, but bear with me:

    I have this machine as a backup, not my main rig. So I want to run windows 10 pro on it (good specs, i7 6 core, 16gb ddr4 RAM), and run osx on it as well. Even on a vanilla brand new install, Big Sur runs a lot slower with an external monitor than my Macbook Air 2017, ironically!

    Main questions are:

    a. Can I PCI Passthrough the USB-C/Thunderbolt/DisplayPort to plug in my 4K monitor, you think? as well as my USB trackpad and USB Magic Keyboard

    b. can I GPU Passthrough the AMD Radeon 555x built in?

    c. (a stretch), use the built in retina display for a VM?

    1. >a. Can I PCI Passthrough the USB-C/Thunderbolt/DisplayPort to plug in my 4K monitor, you think?

      I haven’t tried the DisplayPort part of this functionality so I’m not sure on that one. For the PCIe attachment functionality of Thunderbolt, you can’t actually pass through the port itself, you instead PCIe passthrough the device that is connected to the port. Use “boltctl” on the host to allow the device to appear in lspci, and then you can PCIe passthrough the attached device as if it was a normal PCIe device.

      It’s possible that your GPU has its own USB controller in its IOMMU group which corresponds to the USB-C functionality of this port. If that’s the case, the USB-C and DisplayPort functionality would work fine since the passed-through GPU will handle all the features of the port.

      >as well as my USB trackpad and USB Magic Keyboard

      Do you mean external devices or the ones integrated into the MacBook? Both are possible. You’ll be able to PCIe passthrough the USB controller that these are attached to if you are lucky with IOMMU groups, or you activate the ACS Override Patch. Otherwise you can use regular USB device passthrough (but note that for USB device passthrough, I’ve never seen it support hot-attach and hot-detach, i.e. devices must be present at VM start time, which is a huge pain in the ass).

      >can I GPU Passthrough the AMD Radeon 555x / use the built in retina display for a VM?

      For Nvidia Optimus setups this is difficult, because the discrete GPU has to cooperate with the integrated GPU in order to get its output onto the integrated display (and there are further complications with loading the firmware for the dGPU even if you don’t want to use the integrated display), this architecture is known as “muxless”. I haven’t heard anything at all about the equivalent technology for AMD and I’m not sure if it is possible or not.

      Most likely you’ll have to install a windowing environment on Proxmox so you have a display on your iGPU (, then add an HDMI dummy plug to convince the dGPU that there is a monitor attached (GPUs tend to disable acceleration otherwise), and then view the output of the dGPU on your iGPU using network streaming software like Steam Remote Play or Parsec. For Windows guests you can use Looking Glass instead.

  10. Thanks again for your efforts with these valuable installation tutorials and files.

    I carefully followed your steps and this dummie got a functioning Big Sur install in Proxmox running.

    Except… Is there anything in the settings or setup that would prevent NoMachine from installing? The 7.6.2 installer ends with a “failed to install” dialog. The same DMG installer does work on a real Mac 10.14.6.

    1. Open the “Console” app while you run the install and see if any complaints get logged to the system log.

      1. Thanks for the quick response.

        I think this has something to do with sandboxing. These are a few lines extracted from the install.log…

        2021-08-02 12:59:13-04 VMMacOS Installer[85909]: Package Authoring Error: has an unsupported MIME type: image/data

        2021-08-02 12:59:27-04 VMMacOS installd[703]: PackageKit: Set reponsibility for install to 85909
        2021-08-02 12:59:28-04 VMMacOS installd[703]: PackageKit: Extracting file:///Volumes/NoMachine/NoMachine.pkg#nxclient.pkg (destination=/Library/InstallerSandboxes/.PKInstallSandboxManager/F057B5EE-FA45-460D-8B6B-56FECD08844B.activeSandbox/Root, uid=0)

        2021-08-02 12:59:30-04 VMMacOS installd[703]: PackageKit: Cleared responsibility for install from 85909.
        2021-08-02 12:59:30-04 VMMacOS installd[703]: PackageKit: Cleared permissions on
        2021-08-02 12:59:30-04 VMMacOS installd[703]: PackageKit: Install Failed: Error Domain=NSPOSIXErrorDomain Code=2 “No such file or directory” UserInfo={NSFilePath=/private/tmp/PKInstallSandbox.XXXXXX} {
            NSFilePath = “/private/tmp/PKInstallSandbox.XXXXXX”;

        The entire log is at (I didn’t want to take up a lot of space in the post.)

        1. That is curious, can you check the output of “ls -l /private”? For me the tmp directory within /private has these rights set:

          drwxrwxrwt 28 root wheel 896 Aug 3 15:49 tmp

          You could try booting into recovery mode, then open the Terminal from the top menu, then in there run “csrutil disable”, and then reboot and try the installer again. Actually, before running “disable”, run “csrutil status” and check what it is currently set to.

  11. Hi Nick,

    You mentioned on the Proxmox subreddit a couple of years ago that a proxmox guest is not good for audio production due to latency issues…

    One problem is that (by default) the guest doesn’t have exclusive access to the core it’s running on. Unbeknownst to the guest OS, a host thread can pre-empt it. This means that unless you carefully isolate the guest using the host scheduler, any attempt of the guest to make real-time guarantees (for instance, to deliver an audio buffer on time) is guaranteed to fail.

    Can you give any advice about isolating the guest using the host scheduler please? Thanks so much

    1. There are a lot of guides for doing this on non-Proxmox hosts, but I haven’t seen any for Proxmox specifically yet. Probably something that uses raw QEMU commandline options (instead of libvirt) can be adapted using the “args” VM option in Proxmox.

      Sorry, I haven’t attempted this myself and don’t have any advice to add here.

      1. OK Nick sounds like a step too far for me. I’ll stick with my Hackintosh. 🙂

        Thanks for the quick reply!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.