This tutorial for installing macOS 13 Ventura has been adapted for Proxmox from Kholia’s OSX-KVM project and Leoyzen’s OpenCore configuration for KVM. You can get the full sourcecode of my OpenCore release on my GitHub here.
Requirements
I’ll assume you already have Proxmox 7.2 installed. You also need a real Mac available in order to fetch the OSK key.
Ventura now requires that your CPU has support for AVX2, so for Intel your CPU would have to be at least as new as Haswell. However, I have added the CryptexFixup kext to work around this restriction and allow Ventura to be used even on CPUs that don’t have AVX2 support (and merely support SSE 4.2 and AVX1). Note that the AMD graphics card drivers won’t work in this situation, and other apps that assume AVX2 is present could break too! Please see the CryptexFixup readme for details.
Modern AMD CPUs also support AVX2 and should work with this guide.
Since Monterey, your host must have a working TSC (timestamp counter), because otherwise if you give the VM more than one core, macOS will observe the skew between cores and panic when it sees time ticking backwards. To check this, on Proxmox run:
dmesg | grep -i -e tsc -e clocksource
On a working host you’ll see:
tsc: Refined TSC clocksource calibration: 3399.998 MHz clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x31024cfe468, max_idle_ns: 440795307017 ns clocksource: Switched to clocksource tsc
On a broken host you’ll see:
TSC synchronization [CPU#0 -> CPU#1]: Measured 3358870891203288 cycles TSC warp between CPUs, turning off TSC clock. tsc: Marking TSC unstable due to check_tsc_sync_source failed clocksource: Switched to clocksource hpet kvm: SMP vm created on host with unstable TSC; guest TSC will not be reliable
If you have a broken TSC, this is a possible workaround. Sometimes you can simply power-cycle the host to resync the TSCs (especially if your server has a high uptime).
First step: Create an installation ISO
Download my copy of the OSX-KVM repository using the download button, and unzip it:
https://github.com/thenickdude/OSX-KVM
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 --installIf 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/ventura make Ventura-recovery.img
This will download the Ventura installer from Apple’s software distribution servers and build a Ventura-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 Ventura files during installation, and so won’t require an Internet connection. Simply ask it to build Ventura-full.img instead:
cd scripts/ventura make Ventura-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 (you need v19 or newer), 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.
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 ./smc_read
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” (this is the default).
In the Hardware page for the VM, add a second DVD drive at IDE0, set it to use your Ventura-full.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 (e.g. 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 -global nec-usb-xhci.msi=off -global ICH9-LPC.acpi-pci-hotplug-with-bridge-support=off -cpu host,vendor=GenuineIntel,+invtsc,+hypervisor,kvm=on,vmware-cpuid-freq=on
A USB keyboard is added here because macOS doesn’t support QEMU’s default PS/2 keyboard. MSI has been disabled for the USB controller to fix QEMU panics when USB 3 devices are passed through. ACPI PCIe hotplug support has been disabled to fix VMs with passthrough devices.
Ensure the args are all on a single line!
You can remove the “+invtsc” feature from the -cpu list if your CPU doesn’t support it, or if you want to be able to migrate a running VM between Proxmox nodes.
On AMD you may find that the installer reboots while loading, or the loading bar doesn’t appear, if so replace “-cpu host” with “-cpu Haswell-noTSX” (I had to do this on AMD EPYC 7R13).
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:
agent: 1 args: -device isa-applesmc,osk="..." -smbios type=2 -device usb-kbd,bus=ehci.0,port=2 -global nec-usb-xhci.msi=off -global ICH9-LPC.acpi-pci-hotplug-with-bridge-support=off -cpu host,vendor=GenuineIntel,+invtsc,+hypervisor,kvm=on,vmware-cpuid-freq=on balloon: 0 bios: ovmf boot: order=ide2;virtio0 cores: 4 cpu: Haswell efidisk0: local-lvm:vm-100-disk-0,efitype=4m,size=4M ide0: local:iso/Ventura-full.img,cache=unsafe,size=14G ide2: local:iso/OpenCore-v18.iso,cache=unsafe,size=150M machine: q35 memory: 4096 meta: creation-qemu=6.2.0,ctime=1655001118 name: macos-ventura net0: virtio=...,bridge=vmbr0,firewall=1 numa: 0 ostype: other scsihw: virtio-scsi-single smbios1: uuid=... sockets: 1 vga: vmware virtio0: local-lvm:vm-100-disk-1,cache=unsafe,discard=on,iothread=1,size=64G vmgenid: ...
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 Ventura
Now start up your VM, it should boot to the OpenCore boot picker:
Press enter to boot the “Install macOS 13 Ventura” entry and the installer should appear. (If your keyboard isn’t working, leave the Proxmox Console page and re-enter it)
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 you can quit Disk Utility from the top menu (Disk Utility > Quit Disk Utility), and we’re ready to begin installation!
After the first stage of installation, the VM will reboot a couple of times in quick succession, and each time you must manually 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 nearly complete and the macOS Installer entry disappears, so pick the name of your main disk to boot instead (mine’s called Main).
It’ll reboot a couple more times, so just keep picking the “Main” entry until you finally boot into Ventura!
Answer the initial install questions, and you’ll be logged on! Note that you will want to hold off on logging into your Apple ID until you’ve configured your Mac’s serial number in OpenCore (because otherwise a Mac with the default shared serial number in my OpenCore image will be added to your Apple ID).
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 Ventura 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 Ventura:
Sleep management
I found that I was unable to wake Ventura from sleep using my mouse or keyboard. If you encounter the same problem, you can either disable system sleep in Ventura 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
system_wakeup
quit
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-v15.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 (AMD cards only). 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.
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.
Odd core counts
If your host CPU is AMD, you might have a core count which is divisible by 3, like 6 cores. macOS doesn’t like it if the core count isn’t a power of 2 (1, 2, 4, 8), but it doesn’t mind odd socket counts.
So in order to pass 6 total cores, configure the VM for 3 sockets and 2 cores per socket.
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 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:
https://dortania.github.io/OpenCore-Post-Install/universal/iservices.html#fixing-en0
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 --no-internal. 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 OpenCoreEFIFolder.zip file from my OpenCore release (you’ll probably need to empty the trash first 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 Monterey
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 v19 release before the upgrade, use the section above to do that. After updating that, reboot to make sure that you can still boot Monterey.
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.
If your CPU is AMD, replace the “-cpu” argument in your VM args line with the new one:
-cpu Haswell-noTSX,vendor=GenuineIntel,+invtsc,+hypervisor,kvm=on,vmware-cpuid-freq=on
Intel CPUs should work with -cpu host
Now if your CPU supports AVX2 you can upgrade to Ventura using Software Update or from the App Store like you would on a real Mac.
If the update fails to appear, your SIP mode might be set to “Apple Internal”. You can check this by running “csrutil status” in the Terminal.
To fix this, reboot your VM and at the OpenCore menu select Recovery. Open up the Terminal, and in there run “csrutil enable --no-internal” (“csrutil disable --no-internal” is fine too), then reboot back into macOS and try again.
Another way to upgrade is to build a Ventura full or recovery installer and use that to install Ventura (installing over the top of Monterey will upgrade Monterey while keeping your user data intact).
If your CPU doesn’t support AVX2, you’ll have to create a full/recovery installer since I didn’t enable the kernel patch for Monterey/Big Sur that would allow the Ventura App Store app to be run directly from within running macOS.
Yes, but you need to load custom firmware for it:
https://github.com/vivekmiyani/OSX_GVT-D
It needs to be a macOS compatible model to gain graphics acceleration
I have an I7 11700k CPU.
Hi guys, I have Asrock Z690M based system with Proxmox 8 and Ventura 13.6 with iMacPro1,1 smbios. I passed through my onboard USB 3.2 controller (0x8086, 0x7ae0) Everything works fine, however, the system doesn’t see usb3 devices attached. I tried to foolow Dorthania gude https://dortania.github.io/OpenCore-Post-Install/usb/intel-mapping/intel.html and Hackintool guide None helps. I can see attached usb 2.0 devices in system info thou hackintool shows nothing. I put ioregistry and some screenshots here: https://drive.google.com/drive/folders/1-Tk2zbk15mM1OrWsD2MIDhFRSICSp-9E?usp=sharing Any help would be very much appreciated
I followed your tutorial but I’m unable to boot the recovery drive at all. This is all I can see before it panics from what I can see:
Thread 0 crashed
Mac OS Version:
Not yet set
Panic dlegs file unavailable, panic occurred prior to initialisation
I’m trying this on a Dell R510 proxmox 8.0.3 build. MacOS installs for all previous versions before Ventura any advise would be appreciated 🙂
Hi.
Is it possible to change the serial number in the config.plist in OSX-KVM-master to the right one I have from my old iMacPro1,1 Hackintosh, before I create the installation ISO ? and if so is it possible to change other stuff like secure boot, Sip and and other things I need in the ACPI-folder? For the moment I have a fully working Sonoma-setup with Apple Secure boot and Vault. Is there any specific I need to have in the config.plist just to boot in ProxMox.
Sure, just copy and paste that serial number segment in config.plist from your previous config.
> Is there any specific I need to have in the config.plist just to boot in ProxMox.
Yes, there is a bunch.
Hi, I tried the procedure but without success.
I run proxmox on Celeron j4125. Any suggestion?
Very much appreciated
Hey Nick!!! Any chance you’ll do Sonoma on Proxmox 7/8?
I just did Sonoma on Proxmox 8.0. Followed this guide trying to get Ventura but ended up with Sonoma. It got stuck on installing for a long time. I got frustrated with it and shutdown my computer. Checked the next day and it was still stalled out. Checked back 4ish days later and it had gotten through the first step of the install and was waiting for a reboot.
anyway to update this to sonoma? i tried to update but the screen gets stuck on the apple logo
I just started this process, so I’m fairly new to this. But I generated the ventura ISO, however, when I boot up the VM, I’m seeing an option that says “Reinstall macOS Sonoma.” When I try that, after about 20 minutes I get a generic “Error preparing installation” popup and it stops then. I’m generating the ISO on a Mac with Sonoma on it. Thanks!
Sorry about that, I’ve pushed a new revision for the OSX-KVM repository that should fix that now
Having issues with v8.1, can’t get past 12mins remaining on macos installation. Tried Monterey, Ventura and Sonoma (Recovery and Full).
Also, please note the $make Ventura_full is downloading Sonoma (I think the script is using ‘latest’ to get the current OS build.
Same thing here.
Proxmox 8.1 and AMD Ryzen 7 5800H.
Catalina is the only version I had success installing.
I also try to upgrade from catalina -> sonoma…reboot loop
updated:
I finally succeed to upg from Catalina to Sonoma on Proxmox 8.1
** Note that I had a working Catalina 1st including the EFI mod so it booted automatically before attempting upgrade.
When I had the reboot loop, I changed my args and Voilà it worked !!
# Hackintosh VM – Catalina
agent: 1
args: -device isa-applesmc,osk=”yourOSKhere” -smbios type=2 -device usb-kbd,bus=ehci.0,port=2 -global ICH9-LPC.acpi-pci-hotplug-with-bridge-support=off -cpu Haswell-noTSX,vendor=GenuineIntel,+invtsc,+hypervisor,kvm=on,vmware-cpuid-freq=on
autostart: 0
balloon: 0
bios: ovmf
boot: order=ide1
cores: 4
efidisk0: local:106/vm-106-disk-0.qcow2,size=128K
ide1: local-lvm:vm-106-disk-0,size=64G
machine: q35
memory: 4096
meta: creation-qemu=8.1.2,ctime=1700795478
name: CATALINA
net0: vmxnet3=BC:24:11:9E:52:34,bridge=vmbr0
numa: 0
onboot: 0
ostype: other
scsihw: virtio-scsi-pci
smbios1: uuid=05e0faf5-3e4c-4f65-af37-906c6f99db1a
sockets: 1
spice_enhancements: videostreaming=filter
tablet: 1
vga: qxl
vmgenid: a79829ea-6bff-49ad-bac2-5ec9bae9fcbb
Hi Nick! Having a weird USB issue that I suspect you’ll have a simple answer for. I have had BigSur working for a while based on your tutorial. I jumped the gun a little and decided to go for Sonoma, tweaking your installer where needed.
Anyway, Sonoma is running fine but it won’t pick up most of my USB devices. Simple stuff, my keyboard, Bluetooth dongle and some other bits. It does recognise my USB-C Logitech Camera which I am using in USB-A via an adapter so not sure what is going on there!
I am running Proxmox 6.2-12 (I daren’t upgrade at the moment!) so perhaps that is a deal breaker given the requirement for 7.2 specified here?
The only thing I have had to omit from my args due to old Proxmox is:
ICH9-LPC.acpi-pci-hotplug-with-bridge-support=off – Is that anything related?
I am just passing them via Proxmox i.e. not passing through the full USB controller.
I’m hoping it’s something silly!
If it helps my CPU is an i9 9900k and I have a Gigabyte Designare Z390 board
Many thanks for your time
Great guide Nick! Appreciate the effort you’ve put into maintaining your own forks. I used this successfully on proxmox 8.1.3. I will note that when using the recovery image, ventura install would hang at 12% remaining with no obvious error cause in the installer logs. I was facing issues with one of my intel macs refusing to bless the full recovery image (even on a regular usb drive) but I dug up another mac and was able to build the full image. That worked perfectly.
Hi, I get stuck on 12% trying to install Ventura, I tried building an image with another mac but had the same issue. Just wondered if there was something else I might be doing wrong?
Hi Nick,
How would I go about the following (installing Ventura on top of a Monterey VM on a non-AVX2 host)?
“Another way to upgrade is to build a Ventura full or recovery installer and use that to install Ventura (installing over the top of Monterey will upgrade Monterey while keeping your user data intact).
If your CPU doesn’t support AVX2, you’ll have to create a full/recovery installer since I didn’t enable the kernel patch for Monterey/Big Sur that would allow the Ventura App Store app to be run directly from within running macOS.”
I have Ventura-full.img. I’m just not entirely sure what to do with it with my VM.
Thank you!
roc
Hi Nick,
I managed to install Ventura on proxmox 8.1, running on an Intel NUC i7, but get puzzled when working with the serial#.
Do I use the same serial# with different MLB or does the serial# have to be different as well?
And does the screen sharing only work when signed in with the apple ID?
Thanks,
Jaap
Hi,
Thank you for the tuto.
I can’t download the ‘Ventura-recovery.img’ from my Linux VM (error 127) :
“Permission non accordée”.
Could you help me ?
Best regards
Patrice
Hi Nick,
I have my macOS Ventura setup and working almost at 100% thanks to your post.
I am just not able to figure out how to pass my onboard audio to the VM. The 6 pin on board audio to the VM. I have passed through the HD controller but that did not work.
I have a detailed post on proxmox forums if you need more device information.
https://forum.proxmox.com/threads/unable-to-passthrough-on-board-audio-device-to-vm.140295/
Hi Nick. I’m looking to build a new rig and was hoping you could point me in the right direction. My desire is to use Promox for macOS, gaming, and video editing, plus some basic self hosted applications.
How do I go about picking the right hardware for all of this?
I’m intimidated about getting caught with a gotcha after buying everything so I’m reaching out to you!
Part of the beauty of Proxmox, is the obfuscation of the real hardware vs. the virtualized hardware. You really just need to focus on getting enough performance to do everything you want to do. If you intend to connect a “real” Mac Keyboard, Mouse, and a monitor/tv, then you’ll need a supported AMD graphics card. If you want to use your Mac KB and Mouse via Bluetooth, then you’ll need a PCI express adapter and a suitable card pulled from a compatible MacBook. That’s just for the Mac, of course. None of these are strictly required to get started. If you need any other stuff for your other home lab projects, you’ll also need to source those.
As for CPUs, an Intel will probably give you less issues, but many AMD CPUs and boards will work fine with slight settings tweaks.
Hello
I am running since a longer time several instances of MacOS 12 (Monterey) on Proxmox VE 8.1.4 with xeon L5640 CPUs without any device pass-throughs. With your actual OpenCore v20 image I tried to install over a fresh and running installation of MacOS «Monterey» a MacOS «Ventura» with the «Ventura» recovery image. Booting into the MacOS «Ventura» recovery as well the installation process were successful. Unfortunatly booting in to the upgraded Volume ended with a kernel panic (using OpenCore v20 image). I tried for test purposes also booting only with 1 core and the kernel panic occurs also but at an other booting stage. I made also several test with different CPU settings «Haswell» and «Haswell-noTSX» but with no success. Thus I tried on a new fresh apfs disk (detaching the previous disk with the upgraded installation) an new installation of «Ventura». But the results are after the successful installation of «Ventura» the very same.
My args are the following:
args: -device isa-applesmc,osk=”…” -smbios type=2 -device usb-kbd,bus=ehci.0,port=2 -global nec-usb-xhci.msi=off -global ICH9-LPC.acpi-pci-hotplug-with-bridge-support=off -cpu Haswell-noTSX,kvm=on,vendor=GenuineIntel,+kvm_pv_unhalt,+kvm_pv_eoi,+hypervisor,+invtsc,vmware-cpuid-freq=on
kernel panic with 1 core occurs at/after:
————————————————————-
@kex.corecrypto 12.0 … |IONetworking!F 3.4 (last entry before rebooting even debug=0x100 is present in OpenCore)
kernel panic with 4 cores occurs at/after:
————————————————————
apfs_graft:604: …
apfs_graft:675: …
libignition: 1: graft: os: grafted cryptex: dmg = /System/Volumes/Preboot/…
…
libignition: 1: graft: app: object spec not present: 4 (no reboot as debug=0x100 is present in OpenCore)
I am not able to verify on the Proxmox host the issue with TSC, as the above mentioned commands do report nothing.
I would appreciate any hint, but I guess the xeon L5640 CPUs are definitely to old (?).
many thanks in advance
Panics in kex.corecrypto are common if your CPU misses required instruction sets for this version of macOS, since it heavily uses acceleration for decryption.
Your processor misses support for AVX (1). I don’t recall exactly when macOS started requiring this (the AMD GPU driver started requiring it before macOS itself did, if you had a passthrough GPU).
You definitely can’t use Haswell-noTSX, as this advertises support for AVX which your CPU doesn’t have, which might be enticing corecrypto into trying to use it even though it doesn’t actually require it. Try “-cpu host” instead which will advertise only the features your CPU actually supports.
I’m stuck at the Apple logo after the first initial launch of the installer. I don’t even get to the installer.
I run a bare metal Hackintosh since 2019 on this machine (i9 10850k with a 6800 GPU) so I know it works. What could it be? I tried the Haswell CPU type as well as “Host”.
Thanks for the tutorial, if anyone else updates Ventura to Sonoma from inside the vm and mouse/kb – no longer works, read on:
I installed Ventura on Proxmox 8.1, then from inside it I updated to Sonoma, after reboot in the boot menu kb works to select Main disk, once it gets to loading screen neither kb nor mouse work. Found answer @ https://forum.proxmox.com/threads/console-does-not-work-with-macos-sonoma.143635/
tl;dr Change “-device usb-kbd,bus=ehci.0,port=2” to “-device qemu-xhci -device usb-kbd -device usb-tablet”
Thank you very much
I am having an issue installing Ventura & Sonoma on Proxmox 8.1. I have tried both versions, and run in to the same problem. I am able to format the drive, select it, and begin the install process. However, instead of rebooting during the installation, the VM just shuts down. Manually turning it back on just starts over from the beginning of the process. Any pointers would be much appreciated!
Solved my own problem. Looks like the installer may have an issue with a VM that has a lot of RAM allocated. I reduced the VM RAM from 32 GB to 4 GB and it installed without an issue!
I am getting “pkgdmg checksum does not match” error while installation.
Bad RAM or you need to rebuild the installer.
I have 3 VMs, each with different macOS version and all three started reseting on boot with recent Proxmox update. Anyone having same issue or saw some reports of that elsewhere?
Most likely cause is a change in the TSC handling in the kernel, try running “dmesg | grep -i -e tsc -e clocksource” and see if it’s complaining “kvm: SMP vm created on host with unstable TSC; guest TSC will not be reliable”
A hard power cycle is worth a go too especially if you have a multi-socket system.
It’s a single socket system. Indeed I see it complaining like you say, yet current_clocksource is HPET:
[ 8.335722] kvm_amd: TSC scaling supported
[ 14.073907] kvm: SMP vm created on host with unstable TSC; guest TSC will not be reliable
root@proxmox:~# cat /sys/devices/system/clocksource/clocksource0/current_clocksource
hpet
(I should maybe mention it’s an AMD system to which I recently moved to from Intel. That having said, after updating the cpu in the VMs, it worked just fine for quite a while)
OK, I read a bit more on the subject and see it set clock source to HPET because the TSC instability. I’ll look into why there’s TSC issue.
Do you have any outlined steps on how to passthrough an Intel HD630 (NOT UHD) iGPU? I have a 7600k and the machine runs slow without the graphics acceleration
Also how can I pass through an audio driver so I can use garageband? It won’t recognise any audio devices
Error disabling SPI in recovery mode.
Hey there, Nick!
Been tinkering with proxmox and Ventura VM for a while.
I was even able to get my GT730 to work with a previous ventura installation, and now, with the new 1.5 OCLP i wanted to give it a try.
The problem is, after i install the Ventura VM, i have it running and works just fine via proxmox VNC console. I want to use opencore to install the NVIDIA kext to the system. But it says the SIP is enabled and the root patch button is grayed out.
So i did as you said, entered recovery mode and tried the csrutil disable –no-internal but an error pops out:
Assertion Failed: (range.location + range.lenght <= datalenght), function __CFDataValidateRange, file CFData.c, line 235.
Abort trap: 6
Is there any workaround that i can do to disable SPI protection?
Thanks!
Hey, where you ever able to fix this ? Facing the same issue
After the install I am having the issue “your computer restarted because of a problem” before the configuration.
What’s your host’s CPU?
NVMe m.2 is not seen if cpu is not a host.
System config:
– CPU: Core i7-6700K (Skylake, SMBIOS: iMacPro1,1)
– NVMe: Samsung MZ-V8P500BW (980 pro m2) as additional drive (not the system drive)
– Proxmox 8.0.4
– MacOS Ventura
– OpenCore v21
NVMe configured as a passthrough PCI: hostpci0: 0000:04:00.0,pcie=1
When cpu=host, the NVMe is seen fine inside the MacOS as NVMExpress, but the Unity3D/XCode build times degrades.
When i set cpu=Skylake, the build time reduces BUT i loose NVME drive, i mean the MacOS does not see it.
If i configure NVMe as sata device: sata2: /dev/disk/by-id/nvme-Samsung_SSD_980_PRO_500GB_S5GYNF0R723274F,backup=0,discard=on,size=500107608K,ssd=1
It is seen Ok, but TRIM does not run.
So the main question is how can i make NVMe seen when cpu=SkyLake/Haswell/ whatever ?
Hi Nick,
I am having trouble attaching a BCM43602 card to macOS. This card has two components, a Wi-Fi component via PCI-e (which works) and a Bluetooth component via an internal cable connected to the motherboard (USB 1.1 or 2). I used OpenCore Legacy Patcher to install the USB 1.1 dependency, but it still does not work. In System Information, the Bluetooth controller has the following props:
Bluetooth Controller:
Address: NULL
State: Off
Chipset: BCM_4350C2
Discoverable: Off
Firmware Version: v0 c0
Supported services: 0x382039
Transport: USB
Vendor ID: 0x004C (Apple)
I pass through the host bus to macOS completely, so it has access to all the USB ports on the computer. However, macOS has a USB port limit of 15, and as a result, the following occurs:
$ log show –last boot | grep “ports limit reached”
2024-06-20 12:40:53.690936+0200 0x154 Default 0x0 0 0 kernel: (AppleUSBXHCI) 000000.690936 AppleUSBXHCIPCI@00000000: AppleUSBXHCI::createPorts: ports limit reached. Not creating the remaining 8 ports
So I must either disable the port limit with a kext I do not know of, or create a custom DSDT. In case of the latter, I’m afraid I will mess up some important config you specified for Proxmox.
What is the best solution?
I’m no expert here, but why not try to pass through the PCI and USB components of the BCM card separately. That’s what I do, and it works fine. I have no need to pass the entire USB controller.
Were you able to resolve this issue?
I am having a similar issue, wifi and bluetooth not working in my macOS VM running Sonoma 4.6.1 with Broadcom card bcm43602.
I have found a few interesting notes online, one saying “Apple has dropped support for Broadcom Wi-Fi chipset used in pre-2017 Macs”. (https://github.com/perez987/Broadcom-wifi-back-on-macOS-Sonoma-with-OCLP)
I have other notes here…
https://forum.proxmox.com/threads/anyone-can-make-bluetooth-work-on-sonoma.153301/#post-696913
Hopefully a solution can be found soon.
It’s been a while, but I’m back!
I’m trying to recall where the MacOS GPU compatibility list is found?
I have a Radeon 7770 in one Proxmox host and an R5 230 in the other. Is either one compatible with Ventura.
Also, is either compatible with Sonoma?
I take it back, my first card is an R7 250E, not a 7770.
Please have a closer look here:
https://dortania.github.io/GPU-Buyers-Guide/modern-gpus/amd-gpu.html#native-amd-gpus
Highest Supported OS: Monterey (12)
Anyone having a problem with the APFS snapshot on the main volume getting corrupt somehow and then getting a constant nag about Volume Hash Mismatch? I tried booting into Recovery and deleting the snapshots as I read somewhere that the mismatch is between the system volume and the snapshot. I JUST did a fresh install to try and cure some other problems I had and did NOT restore from TM. I’m starting to think recent updates to Ventura are making Proxmox Ventura VMs ill behaved.
First of all, great guide!
I have two questions:
1. what would I need to do to get intel wifi / BT working with this setup? As in what Kexts that are currently configured would I need to remove, and what kexts should I add?
2. Does anyone have an issue with USB harddrives not being recognized? I have the root usb hub passed through, and the ports are working for all other functions including USB thumbdrives. But External HDD’s / SSD’s are not recognized. Confirmed with multiple working drives.
Thanks!
Hi Nick,
Installing either Ventura or Sonoma, I have an interest connection is required to install macOS. I am using latest .21 OpenCore
If I install Montery I dont have this issue only Ventura or Sonoma.
Please can you point me to how to fix this issue?
This is a question purely out of curiosity, not an indictment. I’m just wondering, why don’t you include Apple’s OSK in this write-up and insist upon retrieving it on real Apple hardware? It’s freely available and, as far as I can tell and kholia’s repo, legally unprotected. Is it a moral thing or CYA?
Regardless, this write-up is excellent and thank you for sharing your resources.
Check out the text of DMCA §1201(a)(1) and tell me again if it’s “legally unprotected”.
There’s a reason why QEMU ships with an emulation of the SMC with everything except for this one unlock code.
Docker-OSX got a takedown notice under DMCA just yesterday (not related to the OSK though).
As for moral judgement, no, I’m running it on non-Mac hardware myself.
Update to macOS 15.0 Sequoia works without any problems, great job nick
🙂
Hi Nick,
Thanks for the guide, worked flawlessly.
I do have some big performance issues though. I do not need GUI because I’m running just scripts for iMessage and FindMy in the background but host CPU load is at least 20% (frequently 50%) due to the macOS VM.
On Activity Monitor side (macOS), WindowServer is taking a constant 20% and com.apple.AppleHIDUserDrivers another 5-10%.
The additional load in the CPU increases power consumption by about 3-5W which is huge (measured average via KillAWatt).
Are there any tips and tricks to improve idle performance without GUI?