Installing macOS 11 “Big Sur” Beta on Proxmox 6

Are you not a member of the Apple Developer Beta? If so, you can install a macOS Catalina VM instead!

This tutorial for installing macOS Big Sur Developer Beta 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.1 or 6.2 installed. Because Big Sur is currently in closed developer beta, you need to be part of Apple’s developer program, and so you will have a real Mac available to download Big Sur and 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

Opt in to the Big Sur beta seed on Apple’s website, then you can use Software Update to download Big Sur:

Download this script, mark it as executable with “chmod u+x” and execute it with “./”:

This will build a file called BigSurBeta.dmg on your desktop. Rename this file to “BigSurBeta.iso” so that we’ll be able to use Proxmox’s ISO picker to select it later, then upload this to your Proxmox’s ISO store directory (typically /var/lib/vz/template/iso).

Prepare an OpenCore image

Download the OpenCore.iso.gz from the newest release (that says it’s Big Sur compatible) from my repository, 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.

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 BigSurBeta.iso.

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/BigSurBeta.iso,cache=unsafe,size=2094688K
ide2: isos:iso/OpenCore.iso,cache=unsafe,size=150M
machine: q35
memory: 4096
name: bigsur3
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:

OpenCore “OpenCanopy” boot menu

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

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. Pick the “macOS Installer” entry (the second one here, with the hard disk icon) to continue installation:

The VM will reboot itself a couple more times, choose “macOS Installer” each time until it doesn’t reappear. Now the installation is complete, so choose the name of your main disk to boot (mine’s called Main).

Answer the initial install questions, and you’ll be logged on!

It works!

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 disk1s1 and disk0s1 respectively, so I ran “sudo dd if=/dev/disk1s1 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 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.

Automatic boot

In config.plist, 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.

Verbose boot

To boot macOS in Verbose mode to diagnose boot problems, edit config.plist to change the “bootargs” in the NVRam section from “keepsyms=1” to “keepsyms=1 -v”.

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

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/BOOT/BOOTx64.efi 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.

73 thoughts on “Installing macOS 11 “Big Sur” Beta on Proxmox 6”

  1. Great article. Thank you so much for posting this.
    I will try it today and I hope it works on my Proxmox as well.

    Greetings from Indonesia.

  2. Excellent article. Thanks. I cloned a Catalina VM and changed Clover to Opencore Boot, I used and I have successful installed.

  3. Hi, Nick
    I am passing through my Radeon VII; when booting up, I can see the Apple logo and the progress bar for a while, then I get a little screen corruption and no signal afterwards. The system boots up fine, as I can remote into it through VNC, albeit the resolution is different than the regular VNC screen I get without the Radeon VII.

    This did not happen in previous Catalina installs.

    Should I try setting the resolution in OpenCore?


    1. It might be outputting the image on a different port, try switching plugs on the back of the card. A visual glitch at this point in the boot is common, as the video card is initialised, but it shouldn’t turn off the screen afterwards…

      I’m assuming you’ve already set vga: none? The emulated video can mess things up if it is left enabled.

      1. I’m having what I think is the same error;

        VGA:none, Proxmox UEFI and OpenCore both show up on the monitor, bar loads at least half way then the screens go black.

        If I switch back to VMWare vGPU and remove my passthrough it works again.

        Tried with a GTX 780 and my 5700XT, both work in my Catalina VM

        1. The OpenCore image you’re using doesn’t support kext injection and so WhateverGreen is not available, which’ll be why your card isn’t working properly.

          I’m not even sure if that whole kext chain has been updated for Big Sur support yet.

  4. I don’t see how you got Big Sur booting with the OpenCore config.plist you have provided. The require NVRAM settings are not in the config at all.

      1. The booter-fileset-kernel setting in NVRAM > Add section. This NVRAM setting is required in order boot Big Sur with prelinkedkernel support. Without this variable being set, Big Sur boots with KernelCollections.kc which is unable to be booted by OpenCore yet. I tried your Big Sur script and your OpenCore.iso with the exact same settings of your VM.conf settings and only got the same result of the SIGABRT loop with the installer.

        1. There must be something wrong with that info, because otherwise it could never have installed and been happily running for me (twice, as one VM I upgraded from Catalina and the other VM was a clean install). I’ve never had the setting you mention in any of my configs.

          I redownloaded my OpenCore image just now and used it to create a fresh new Big Sur VM, and it installed and ran fine.

          Post your VM config, and what’s your host CPU model?

          1. Host CPU is a AMD 3970x Threadripper, I have BigSur booting fine but it I had to use a real MacBook Pro with a NVMe to USB adapter and installed it to an external drive and then moved it to my Proxmox system. But I can boot the installer in any fashion.
            Here is my VM config
            args: -device isa-applesmc,osk=”…” -cpu Penryn,kvm=on,vendor=GenuineIntel,+kvm_pv_unhalt,+kvm_pv_eoi,+invtsc,vmware-cpuid-freq=on,+pcid,+ssse3,+sse4.2,+popcnt,+avx,+aes,+xsave,+xsaveopt
            balloon: 0
            bios: ovmf
            bootdisk: ide0
            cores: 32
            cpu: Penryn
            efidisk0: local-lvm:vm-100-disk-1,size=4M
            hostpci0: 23:00,pcie=1,x-vga=1
            hostpci1: 01:00.0,pcie=1
            hostpci10: 48:00.3,pcie=1
            hostpci2: 02:00.0,pcie=1
            hostpci3: 43:00.0,pcie=1
            hostpci4: 44:00.0,pcie=1
            hostpci5: 46:00.0,pcie=1
            hostpci6: 47:00.0,pcie=1
            hostpci7: 48:00.1,pcie=1
            hostpci8: 4b:00.0,pcie=1
            hostpci9: 04:00.3,pcie=1
            localtime: 1
            machine: q35
            memory: 98304
            name: BigSur
            numa: 1
            ostype: other
            scsihw: virtio-scsi-pci
            smbios1: uuid=6623598a-7a98-4b99-8229-e44ed0d3568c
            sockets: 1
            tablet: 0
            vcpus: 32
            vga: none
            vmgenid: d3eb685a-544e-4936-b26a-89f3e0fec696

              1. There’s no point in trying to diagnose a VM with so many passthrough devices enabled because an incompatibility with any one of them could trigger a fault.

                Also I’d try reducing cores to 8 or 16 since it could be unhappy about the topology.

  5. Nevermind I just got the installer to boot, I recreated a new VM with the settings and it is working now, thanks for the settings.

  6. Hi Nick, I don’t have dev account, so I went for the BigSur ISO from the internet. But, I cannot see the BigSur logo/icon in the boot picker. I only see UEFI shell, Shutdown and Reset NVRAM.

    Do you think this is because of the ISO that I have? It is 10 GB size and it was used by someone to install it on VMware, and they said successful.

    Thank you again. I got my Catalina running. Now want to try this Big Sur

    1. OpenCore only supports disks formatted GUID/GPT, not MBR. There are a lot of images floating around that are formatted MBR and will be invisible in the OpenCore boot menu.

      If your image is a true ISO (rather than a harddisk image) then make sure you have retained media=cdrom in the config line for that drive. This isn’t going to be the case if the extension of your image is .dmg.

      From inside a Catalina VM you could run the Big Sur installer app from the image you have currently, which bypasses any boot problems since you never need to boot from the installer.

      1. Hi Nick, Finally I can get the BigSur from my Hackintosh. So I created the DMG and convert to ISO as your instruction.
        But upon boot, I still unable to see the BigSur in the boot picker.
        Which settings I should play with? I use your OpenCore for Big Sur.

        Thanks again

        1. Did you remove media=cdrom from the Big Sur ISO and add cache=unsafe in its place? It’s required.

          If you didn’t follow my instructions to create the DMG then it’s probably partitioned MBR instead of the GPT/GUID that OpenCore requires for the boot icon to become visible.

          1. Hi Hello,

            I got errors when building the dmg. I think this is why my ISO is not visible on picker.

            In the .sh command: I saw this line: in_path=/Applications/Install\ macOS\

            And my actual .app name is: Install macOS Big Sur Beta, not Install macOS Beta.

            Is this mismatch command that causes the error during dmg creation using the

            Thank you

  7. Sorry to bother again, just want to inform you about my error:

    sudo: /Applications/Install macOS command not found

    And then I try to manually execute that command with the correct path, I got this:

    dhani@iMac-Pro-2 Desktop % sudo /Applications/Install\ macOS\ Big\ Sur\ –volume /Volumes/install_build –nointeraction
    dyld: Library not loaded: @executable_path/../Frameworks/IAESD.framework/Versions/A/IAESD
    Referenced from: /Applications/Install macOS Big Sur
    Reason: no suitable image found. Did find:
    /Applications/Install macOS Big Sur stat() failed with errno=20
    /Applications/Install macOS Big Sur stat() failed with errno=20
    zsh: abort sudo –volume /Volumes/install_build –nointeraction

    Any idea about this error?

    Thank you

    1. I would delete the app and redownload it.

      Which system are you running this on, a Catalina VM or like a really old Mac?

    2. It looks to be the spaces in the file name. I renamed the app to `` and changed the in_path in the script accordingly and it works.

      1. I met another problem and the solution is to increase the disk size from 12g to 14g in the script. The new beta app must have increased in size, 13g might be ok but I just give it more than needed.

  8. Amazing! Spent a lot of time to make it work bare metal with Catalina+opencore with no success, but with your approach it worked flawlesly the first time! Thanks a lot!!!

  9. Thanks for great article clearly showing how would the new Big sur like. Always good to know before a light user step in.

    It’s a bit sad to know SSE2 is a must for Big sur, my macbook pro 2009 with core 2 due could not be working with Big Sur.

  10. hey nick, great work. i have a 3960x 24/48c i can get it to boot with 8/16 core how czn i change the topology to utilize all 24/48c ive been busting my head with this one if you can help out.


  11. Hi Nick, finally I can install BigSur with your new script.
    I am using 2K monitor. Before, I use 1080 monitor and I can enable the mirroring display in macOS. I can use the 2K monitor as 2nd display but that is not convenient. The mirroring is my only preferred way I guess.
    But now since I have 2K monitor, and I enable the mirroring, I cannot get a good resolution for my Monitor. It uses the default Display max resolution (1080).
    Is there any way to fix this?

    1. I’m using an app called RDM to set custom monitor resolutions with my RX 580:

      This allows you to pick HiDPI options even if macOS doesn’t offer them for some reason.

      I think if you mirror, then both monitors will have to be the same resolution though.

  12. Hi Nick, first thank you for all the work you do. It helped me get into Proxmox in a big way.
    I am now rocking 2 servers with several VMs each, Windows 10, 8, Linux and couple MacOS, HS, Catalina and Big Sur Beta 3.
    I wanted to let you know that now that Beta 4 is out I managed to do a clean install no problem following your guide after you made the update to the script.
    I though maybe it was good to have confirmation that the guide still works even after the new Beta.
    Thanks again.

  13. This is a great tutorial! I was able to create an ISO using the Public Beta and everything seemed to run smoothly through the installation.

    However, when I use Screen Sharing from my MacBook Pro, the image shown on the screen is blank. Using the Proxmox console, I can see that, while the screen is blank through Screen Sharing, it is indeed moving the mouse.

    So, for some reason no video is getting passed when using Screen Sharing. Any ideas?

  14. I’m very happy about this guide! The only issue I’m facing is the BiErrorDomain Error 12 I got while selecting the installation Disk…someone suggest Disk Type, SATA + SSD Emulation rather than Virtio …I’m stuck here. Any help will be appreciated!!! THANKS

        1. No, the guest can’t tell what kind of storage backs the host’s virtual disks, M2 is fine. Can you share the contents of your VM config file?

    1. You’re using a third-party built macOS install image… it’s really hard to guess what they might have messed up with this one so it isn’t really worth debugging it.

      I didn’t spot any other problems in your VM config.

      1. I just followed “your way”, but when I try the boot now I got the EFI/startup.nsh message…stuck here 🙁
        thank you

        1. root@mithril:/var/lib/vz/template/iso# file Big_Sur_Beta.iso
          Big_Sur_Beta.iso: DOS/MBR boot sector; partition 1 : ID=0xee, start-CHS (0x3ff,254,63), end-CHS (0x3ff,254,63), startsector 1, 29360127 sectors, extended partition table (last)

        2. What error message is that exactly? When does it appear?

          Are you using my correct OpenCore image for Big Sur, and not my earlier Catalina one?

            1. Make sure your boot order is actually set to the OpenCore image and the OpenCore image file isn’t missing from the filesystem.

              If it’s all configured correctly then delete the EFI disk from the hardware tab and re-add it to reset your boot order properly.

              1. well, I probably did some mistake while editing the .cfg file.

                I’ve done a new machine from scratch, re-uploading everything and now it’s installing! 🙂

                I also noticed the Disk I selected in my previous install was the QEMU HARDDISK rather than the VirtIo Block Media!!

                So, finger crossed and thank you again for this PERFECT guide…I recently moved from ESXi to Proxmox only for that ehehe

                keep you posted. ciao

  15. Oh that’s what happened, you accidentally installed on top of the OpenCore image or the installer ISO and it never worked again, lol

    1. I finally got my Big Sur installation working but the disk is still called “preboot”…any idea on how to fix it? Thanks

      1. GPU passthrough is not going to work on Big Sur right now because my OpenCore image doesn’t support loading WhateverGreen.

        Which GPU is that BTW?

          1. You’re passing through the onboard Aspeed GPU then? That’s not going to work in a useful way because macOS doesn’t have a driver for it.

  16. Hey Nick,

    Thanks for this article, and the whole series really. I used the Catalina article to spin up both High Sierra and Catalina VMs.

    Question – I’m primarily just using my Mac VM as a local repo for my iCloud Photo Library but I want to passthrough a GPU. Any Catalina recommendations that aren’t as expensive – or should I just run an older GPU into the High Sierra VM? I was looking at the linked website but wasn’t clear which models were best still.

    Thanks for any insight.

    1. Sorry, I can only confirm that R9 280X no longer seems to work on Catalina and the RX 580 mentioned by Passthrough Post works nicely but shows the reset bug for me, so I have to power cycle the host between guest boots. I don’t have experience with any of the other cards and I’m really hesitant to recommend one since the success rate is so variable.

      If you can go back to High Sierra you’ll have a lot more choice.

  17. Hello! I tried this today, and am stuck in a boot loop during the install, after the first restart and to boot into the second macOS Installer it gets 1/10th done, and a spinner happens underneath the loading bar, then it restarts into the loop.
    Running Proxmox 6.1-8 (32 x Intel(R) Xeon(R) CPU E5-2667 v2 @ 3.30GHz)
    here is the config:
    args: -device isa-applesmc,osk=”…” -smbios type=2 -device usb-kbd,bus=ehci.0,port=2 -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
    balloon: 0
    bios: ovmf
    boot: cdn
    bootdisk: ide2
    cores: 4
    cpu: Penryn
    efidisk0: TwoTB:vm-111-disk-1,size=4M
    ide0: local:iso/BigSurBeta.iso,cache=unsafe,size=14G
    ide2: local:iso/OpenCore.iso,cache=unsafe
    machine: q35
    memory: 8192
    name: BigSur
    net0: vmxnet3=82:CA:B1:02:2E:ED,bridge=vmbr0,firewall=1
    numa: 1
    ostype: other
    scsihw: virtio-scsi-pci
    smbios1: uuid=06b55e5a-6b03-40b8-8b7d-e6b23de0354d
    sockets: 1
    vga: vmware
    virtio0: TwoTB:vm-111-disk-0,cache=unsafe,discard=on,size=64G
    vmgenid: 2fb46f8b-134d-4dbb-9484-438fa45f6055

    any help would be wonderful!

    1. Typically this would be due to a bad OSK, double check that your text editor didn’t mangle it by inserting a copyright symbol or curly quotes. If you copied it from a blog you also need to look out for invisible Unicode linebreaking characters.

      Make sure you’re using my OpenCore image for Big Sur and not the one for Catalina, too.

  18. I’ve now updated my OpenCore release, and the new image supports booting both Catalina and Big Sur, and both support “-cpu host”.

  19. not convert to dmg worked just rename the file to iso
    You have the best tech support of anyone.
    The Full installer is installing now
    Thanks so much

  20. Hi Nick, thanks so much for the great guides!

    I have an off topic question, apologies for adding it here but I really didn’t know how else to reach you.

    I have an unusual project, I’m trying to get an ancient Snow Leopard Server install migrated over to VM. Yes, believe it or not it’s an install that’s still in use. I managed to get a functional Fusion VM running with it first. Converted to OVA, imported the VMDK file into Proxmox as qcow2 format. Otherwise I’m following your guide. OpenCore sees the disk I imported, and it loads up with an Apple Logo but goes to the prohibited symbol right after. I feel like I’m very close here, so I was really hoping for some advice – if you have the time. Thank you

    1. For Snow Leopard I would try to use a much more contemporary bootloader, Clover for sure instead of OpenCore. Few developers are testing new bootloaders with these older releases now. Note that Clover required a patched version of pve-edk2-firmware last time I tried it, which my Clover-based macOS tutorials provide.

      You can edit your config.plist to add “-v” (for verbose mode) next to keepsyms=1 here:

      To edit config.plist from your Proxmox host, follow these directions:

      If you want to continue trying OpenCore, be sure to use -cpu penryn, because I don’t think the kernel patches in config.plist that fake a Penryn CPU will be functional on these old macOS versions.

      1. I had a hunch you would refer me to Clover. 🙂 I was hoping to avoid it and stick with OpenCore, mostly because I feel like future updates may overwrite your patched pve-edk2-firmware and break things. Correct me if I’m wrong? I completely understand that I’m working with an older abandoned OS here that nobody really uses anymore, so it is what it is. In any case, thanks for the advice – I really appreciate it! I’ll do some more tinkering here and see if I can get anywhere with this.

        1. You can pin my pve-edk2-firmware package to prevent Proxmox from upgrading it automatically, but it will eventually need to be updated in order to be compatible with Proxmox changes (probably needs to be updated once every couple of years).

          1. Makes sense.

            By the way, thanks for the info on setting up verbose mode. This is where it’s getting stuck (while still using OpenCore):

            Loading System\Library\Caches\\Startup\Extensions.mkext….
            Error allocating 0xdb3 pages at 0x00000000773000 alloc type 2………………………………
            Could not allocate driver module memory

            I’ll try Clover next as well.

            Not expecting you to diagnose this, but if something stands out let me know. Otherwise I’ll stop filling this thread for Big Sur on this unrelated issue as I don’t want to cause any confusion for others.


Leave a Reply to Nicholas Sherlock Cancel 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.