Lian Li EX-H35 HDD Hot Swap Module (to add 3 x 3.5″ drive bays into 3 of the 4 x 5.25″ drive mounts), with Lian Li BZ-503B filter door, and Lian Li BP3SATA hot swap backplane. Note that because of the sideways-mounted 5.25″ design on this case, the door will fit flush with the left side of the case, while the unfiltered exhaust fan sits some 5-10mm proud of the right side of the case.
2 x Noctua NH-U14S coolers
EVGA SuperNOVA 750 G2 750W
My Proxmox machine is my desktop computer, so I pass most of this hardware straight through to the macOS Monterey VM that I use as my daily-driver machine. I pass through both USB 2 controllers, the USB 3 controller, an NVMe SSD, and one of the gigabit network ports, plus the RX 580 graphics card.
I’ll assume you already have Proxmox 5.4 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).
Apparently modern AMD CPUs also support SSE 4.2 and can be used with this guide without any modification (maybe Bulldozer and certainly Ryzen), but I haven’t tested this myself.
Proxmox 5 and 6’s version of the OVMF firmware includes two commits (2ac1730 and 147fd35) that are intended to mark the pagetables as read-only during startup. This was first seen in Proxmox 5.1. This conflicts with the OsxAptioFixDrv drivers in Clover, which expect to be able to modify the pagetables to remap memory:
I’ve patched OVMF to revert the effect of these two commits, which allows macOS to boot again (I also tested it by booting Windows 10, which worked fine). If you just want to download the fixed .deb, skip to the end of the article, otherwise if you want to build it yourself, follow along with the instructions in the next section:
I’ll assume you already have Proxmox 5.1 installed. You also need a real Mac available in order to download High Sierra from the App Store and build the installation ISO. Your Proxmox host computer must have an Intel CPU at least as new as Penryn (I believe you would need a a custom Mac kernel in order to use an AMD CPU). Continue reading Installing macOS High Sierra on Proxmox 5
When emulating macOS on Proxmox, it seems that we are forced to set the guest’s CPU type to “Penryn”. This is a very old architecture, and is missing some features that could unlock higher CPU performance. In particular, I wanted to use AVX (for accelerated stream processing) and AES-NI (for encryption), but macOS panics on boot if I set the CPU to Sandy Bridge, which would match my CPU which includes those features.
Luckily, kholia over at the OSX-KVM project has discovered that we can keep using Penryn, but enable the passthrough of individual advanced CPU features and have Sierra use them, even though Penryn never supported these features.
After reinstalling Mac OS Sierra, I found that Chrome could no longer use my HTTPS client certificates. Instead, after choosing my certificate from Chrome’s pop-up certificate picking menu, I just got a fatal “ERR_SSL_CLIENT_AUTH_SIGNATURE_FAILED” error. The HTTPS client certificates worked fine in Safari, so it seemed to be a Chrome-specific problem.
I was able to fix this by opening the Keychain Access program, right-clicking my HTTPS private key and selecting Get Info, then on the Access Control tab I changed it from “allow all applications to use this item” to “confirm before allowing access”. The next time I tried to view the website in Chrome, Mac OS popped up to confirm that I wanted to allow it to use the key, and it worked perfectly after clicking Allow! I guess the Keychain’s application permissions got messed up at some point, and this reset it.
In Sierra 10.12.4, macOS added some extra copy protection which is able to tell that the SMC emulation that QEMU provides is not a real Mac. This causes a fatal error during boot on Proxmox 4 and earlier. Proxmox 5.1 now includes the fix for this problem in its regular QEMU package so a patch for 5.1 is no longer necessary.
One way of fixing this would be to remove the SMC device from the virtual machine’s arguments, and use FakeSMC.kext instead, like a regular Hackintosh, but this is inelegant.
Recently I migrated my MacBook Pro into a Proxmox virtual machine to use as my daily-driver. This made for a rather large stepdown in IO performance, since my MacBook used an SSD, and Proxmox was using a RAIDZ1 array of spinning disks. On top of the IOPS penalty for spinning disks, there are currently no macOS drivers for the virtio SCSI paravirtual device, so we have to use IDE/SATA emulation instead, which is very slow (although this may change in the near future).
One way to improve things would be to use PCIe passthrough to pass through a whole physical SATA controller to the guest. This would eliminate almost all of the performance penalty of the virtualised SATA controller. But there’s a new option for drive passthrough: NVMe SSDs.
NVMe is a new standard for operating systems to communicate with a disk controller, which has been specifically designed to extract the most speed possible from SSDs. NVMe SSDs are PCIe devices (typically x4), so we can pass them straight through to macOS. I’m using the Samsung 950 Pro. You might also consider the faster 960 Pro.
The only missing piece of the puzzle is NVMe support in macOS Sierra. Thankfully, modern macs have begun shipping with NVMe SSDs inside, so we have an official Apple driver we can use. It just needs to be patched to accept our SSDs.
My previous Proxmox post described how to install Sierra into Proxmox using the Enoch bootloader (SeaBIOS boot). Since then, I’ve been using it as my daily-use desktop, and it has generally been working out great for me. However, I had some real struggles getting the graphics card passthrough to work reliably. I managed to fix these by updating to UEFI boot with Clover.
One of the problems with legacy BIOS boot and GPU passthrough is VGA arbitration. From what I understand, the video cards in the host and guest can end up both contending to own the VGA resources, which can cause a deadlock on boot. When a Sierra guest loads its video driver during boot, my Proxmox host hangs, and the screen fills with black and white bars.
UEFI boot doesn’t suffer from this problem, since it does away with the legacy VGA interface. So if your video card’s firmware supports UEFI/EFI boot (my R9 280X already does), you can switch the guest to boot using OVMF instead. This requires us to use a macOS bootloader that supports UEFI. I chose Clover. Continue reading Using Clover UEFI boot with Sierra on Proxmox