The ability to tinker with cool projects without worrying about breaking anything is what I adore about virtualization platforms. In fact, I’ve spent a long time experimenting with virtual guests on Proxmox, and have ended up with VMs that run well despite their weird premise. A remote Windows 11 daily driver VM is one such project, and the same holds for Arch-based Dev environments.

Unfortunately, I’ve always had trouble getting the newer versions of macOS running on my Proxmox nodes. Certain repositories like OSX-Proxmox can deploy functional macOS instances on the virtualization platform, though I’ve never been able to run anything newer than Sonoma on Proxmox, even with different hardware permutations and combinations. But as it turns out, LongQT-sea’s OpenCore-ISO repo can even run macOS Tahoe on Proxmox with minimal compatibility issues.

The macOS VM needed some fine-tuning

But nothing too complex

Aside from OSX-Proxmox and a handful of other scripts, deploying a macOS VM typically involves numerous shell commands, kernel modifications, and config tweaks. The OpenCore-ISO project is quite different, as the only options that need fine-tuning are available on the good ol’ Proxmox VM creation wizard.

But before I go into the intricacies of the process, let me go over my testing rig real quick. Since I wanted to see how macOS would work on a server system, I used my dual-CPU Xeon E5-2650 v4 alongside 64GB of DDR4 memory for this project. Yes, it’s pretty slow by today’s standards, but it works well for the majority of my PVE workloads, and should allow me to go ham when allocating resources to the VM.

First, I downloaded the OpenCore and macOS Tahoe recovery images from their respective GitHub pages and uploaded them to the PVE node’s local disk. When creating the virtual machine, I chose q35 as the Machine Type, switched to OVMF (UEFI) BIOS from Seafile, selected the OpenCore ISO as the ISO Image, added an EFI Disk on the local disk, and disabled Secure Boot by unchecking the Pre-Enroll Keys option. Since I wanted to test macOS Tahoe, I enabled the QEMU Guest Agent.

For the Storage settings, I opted to create a SATA drive with 100GB of Disk Space, and enabled SSD Emulation as well as Discard. In hindsight, I should’ve gone for VirtIO, as it offers better performance – which is something I’d realize my server CPU was lacking later on. Anyway, I wanted to make up for the lack of single-core performance on my system by shoving 12 vcores into the virtual machine, which requires setting the Cores to 4 and Sockets to 3 per the documentation. I also set the CPU Type to Skylake-Server-v4, while assigning 16GB of Memory to the VM.

After leaving the Network settings at their default values, I created the VM. But my work was far from done. Since I was rocking a Broadwell server CPU, I had to override the model for the VM by running the qm set vm_id --args "-cpu Broadwell-noTSX,vendor=GenuineIntel,model=158" command within the Shell tab of my PVE node, where vm_id was the virtual machine identifier (143, in my case).

Finally, I headed to the Hardware section within the VM’s options and added the recovery ISO from earlier as a CD/ROM Drive (IDE).

Installing macOS Tahoe was fairly simple

I didn't encounter too many issues, either

With the VM all configured in Proxmox, it was time to boot it up and install macOS. Once the virtual machine loaded the recovery environment, I opened the Disk Utility and flashed the SATA drive I’d created for the macOS installation. Then, I chose the Reinstall macOS Tahoe option, and the setup process was underway after I accepted a couple of options.

Truth be told, I low-key expected it to get stuck in a boot loop, which is what happened with other scripts whenever I tried installing the newer macOS versions. But to my surprise, the VM finished downloading the macOS files in less than an hour and began installing the operating system. Unfortunately, this is when I encountered my first error, as the VM kept throwing a chain of terminal errors.

But before I could don my troubleshooting hat, I restarted the virtual machine… which miraculously fixed the issue, and I was able to enter the initial configuration screen. That’s where the slow single-core speeds of my Xeon system became a bottleneck, as the menus moved at a snail’s pace. I also ran into an issue where the background wouldn’t load, though a white screen in place of a wallpaper was no big deal. However, there was a random freeze when setting my location, but a restart was all I needed to fix this problem as well. Soon, macOS was fully configured, and it was time to test how well Tahoe would run inside a Proxmox virtual machine.

The macOS virtual machine worked surprisingly well

And it was even able to run popular macOS apps

Just like the configuration wizard, the default macOS desktop displayed a white background, though the app icons and menu bar loaded fine. It was probably an issue with live wallpapers – something I’d encountered in macOS VMs spun from different projects as well. Setting the background to a static image solved this problem, and navigating the Settings app felt significantly more responsive than the setup process.

I also opened the LongQT-OpenCore folder and installed Python 3. Then, I went about testing the other apps. Safari worked really well out of the box, which is surprising since it was broken inside other Proxmox-based macOS VMs. Raycast ran just as well, and the same holds for Ulysses, Xcode, TickTick, Freeform, and Obsidian – provided I ran everything one-at-a-time. Of course, they weren’t as responsive as the apps on my heavily-tweaked Windows 11 and Arch Linux VMs, but they were still decently usable.

Considering that I was running the VM on an old Xeon system that’s infamous for slow single-core performance, I’m honestly surprised by how well everything turned out. I plan to grab a Ryzen 7 9700X this Christmas, and I can’t wait to repeat this experiment on such a fast processor. If all goes well, I might just end up turning it into a Proxmox-based Hackintosh.