Installing macOS High Sierra on Proxmox 5

This tutorial for installing macOS Sierra has been adapted for Proxmox 5 from Kholia’s GitHub project for installing into vanilla KVM. There is more documentation there which will help out with enabling extra features and diagnosing problems!


I’ll assume you already have Proxmox 5 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).

First step: Create an installation ISO

On a Mac machine, download the macOS High Sierra installer from the App Store (this will download it into your Applications folder).

Check the size of the completed download. Some people will end up with a 16MB installer, and some will receive the full 5GB installer (nobody knows why yet). If you received the 16MB version, follow the instructions here to get the full 5GB version instead.

Now run this script in order to create HighSierra.iso from the installer. The ISO should get saved to your desktop. Upload the ISO to your Proxmox server’s ISO store (typically /var/lib/vz/template/iso).

Prepare a Clover image

We’ll be using Clover as a bootloader for High Sierra.

Download this Clover disk image (that I built using kholia’s build script from Clover r4243), 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. (I do it this way because Proxmox has nicer tools for storing and picking .iso files for us)

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). Run the first bit of C code from this page (you’ll need XCode installed) and 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 if 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, change “Use tablet for pointer” to “No”. Change “BIOS” to “OVMF (UEFI)”.

In the Hardware page for the VM, change the the Display to Standard VGA (std). Add a second DVD drive at IDE0, set it to use your HighSierra.iso. Add an “EFI Disk” too.

Return to the Options tab and change the boot order to put IDE2 (the Clover image) first.

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 these two lines, being sure to subtitute the OSK you extracted earlier into the right place:

machine: pc-q35-2.9
args: -device isa-applesmc,osk="THE-OSK-YOU-EXTRACTED-GOES-HERE" -smbios type=2 -cpu Penryn,kvm=on,vendor=GenuineIntel,+invtsc,vmware-cpuid-freq=on

Find the two lines that define the CDROM drives (ide0 and ide2), and remove the “,media=cdrom” part from both lines. Add “,cache=unsafe” in its place.

On the net0 line, change “e1000” to “e1000-82545em”. This variant is supported by OS X.

macOS doesn’t support the PS2 keyboard and mouse that QEMU will emulate, nor does it support the tablet, so edit /usr/share/qemu-server/pve-q35.cfg and add these USB input devices to the bottom of the file instead:

[device "mouse1"]
 driver = "usb-mouse"
 bus = "ehci.0"
 port = "1"

[device "keyboard1"]
 driver = "usb-kbd"
 bus = "ehci.0"
 port = "2"

We’ve added those to the config file instead of to the VM’s args directly. If we were to add them to the VM’s args, then when Proxmox constructs its call to KVM to launch the VM, those device definitions would appear before the pve-q35.cfg file is included, which defines the USB busses. However, the device definitions must appear after the definitions of the USB bus that they refer to.

Note that this file is whitespace-sensitive, make you you don’t add any blank lines that have extraneous spaces on them.

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

You must now install a patched version of Proxmox’s QEMU in order to be able to boot High Sierra, until this patch is merged by the upstream.

Install High Sierra

Now start up your VM.

Go to the Console tab, quickly hit Escape at the Proxmox logo to enter the OVMF configuration. If your keyboard doesn’t work, leave the Console tab, stop the VM, start the VM, then re-enter the console tab.

Follow the steps above to set the screen resolution to 1024×768 and reset. It should now boot into Clover.

Clover boot screen

Press enter to boot the “Boot OS X Install from Install macOS High Sierra” entry and the installer should appear. Choose your language.

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 should reboot itself and continue installation by booting from the hard drive. Answer the initial install questions, and you’ll be logged on! (Note that you’ll probably want to hold off on logging into your iCloud account until you’ve configured your SMBIOS to your liking in Clover Configurator)

Make the Clover install permanent

We’re currently booting using Clover from the attached CD image. 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 Clover CD and overwrite the EFI partition on the hard disk. The Clover CD is the one with the “linux filesystem” on it, and the main hard disk is the one with the large Apple_APFS container partition on it.

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

Now shut down the VM, and remove both the Clover and the Sierra CDROM drives from the Hardware tab. On the Options tab, edit the boot order to place SATA0 as the first disk. Boot up. If everything went well, you should see a Clover boot menu, and you can select “boot macOS from *disk*” to boot High Sierra.

Sleep management

I found that I was unable to wake High Sierra from sleep using my mouse or keyboard. You can either disable system sleep in High Sierra’s Energy Saver settings to avoid this, or you can manually wake the VM up from sleep from Proxmox by running:

qm monitor YOUR-VM-ID-HERE

Editing your Clover/EFI settings

You can use the Clover Configurator tool to edit your Clover configuration, which is stored in the hard drive’s EFI partition. This tool should mount the EFI partition for you. If you want to mount it without using Clover Configurator, first check the device name of the EFI partition in the terminal:

~$ diskutil list
/dev/disk0 (external):
   #:             TYPE   NAME           SIZE       IDENTIFIER
   0: GUID_partition_scheme             512.1 GB   disk0
   1:              EFI   EFI            209.7 MB   disk0s1
   2:        Apple_HFS   Main           511.8 GB   disk0s2

Then you can mount it like so:

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

Passing through advanced CPU features

You can pass through CPU features like AVX and AES-NI for increased guest performance, see here for details.

USB passthrough

Using noVNC gets pretty annoying due to the Mac’s absence of tablet support for absolute cursor positioning. You can solve this by turning on the Mac’s screen sharing feature and using that instead. You might also be able to solve this by installing this third-party driver and re-enabling the tablet feature on the Options tab. However, 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
 Bus 3, Addr 6, Port 11, Speed 12 Mb/s
 Class e0: USB device 0b05:17d0,
 Bus 3, Addr 2, Port 1, Speed 1.5 Mb/s
 Class 00: USB device 068e:00f2, CH PRO PEDALS USB

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. It’s possible to hot-add USB devices, but I just rebooted my VM 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.

PCIe GPU passthrough

For near-native graphics performance you can pass through a video card. There are details in the Proxmox manual. You should also check out Hackintosh tutorials for more details on installing the drivers correctly (and configuring Clover correctly) for the card you want to install.

If you don’t want to pass through a video card, but want to bump the screen resolution up to 1920×1080, use Clover Configurator to set Clover’s screen resolution to match that, then enter the OVMF settings at boot time by pressing escape, and set the new resolution there as well.

Passthrough of advanced CPU features for macOS [High] Sierra guests

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.

Continue reading Passthrough of advanced CPU features for macOS [High] Sierra guests

Upgrading a Proxmox 5 macOS Sierra guest to High Sierra

macOS 10.13 High Sierra has finally been released, and the good news is that it works with Proxmox 5!

Here’s how I upgraded my Proxmox 5 Sierra installation, which has been previously updated to use Clover/UEFI boot and is stored on a passthrough NVMe SSD. Your setup may differ and your upgrade steps may need to change. I doubt these instructions would work for enoch/chameleon boot.

Take a snapshot of Sierra

I cannot stress this enough! If your filesystem gets completely trashed by the installer, you really need to be able to roll it back to a snapshot!

Continue reading Upgrading a Proxmox 5 macOS Sierra guest to High Sierra


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.

Emulating MIPS guests in Proxmox 5

I wanted to emulate MIPS guests on my Proxmox hypervisor so that I could do some security research on router firmware. Unfortunately, Proxmox has customised some of the QEMU packages and their dependencies, which makes it difficult to install the standard Debian qemu-system-mips package. In particular, Proxmox provides its own pve-libspice-server1 package which conflicts with the libspice-server1 package that vanilla QEMU depends on, so attempting to install it will complain:

Some packages could not be installed.

The following packages have unmet dependencies:
 qemu-system-mips : Depends: libspice-server1 (>= 0.12.5)

To solve this, we need to build a modified version of the package from source.

Continue reading Emulating MIPS guests in Proxmox 5

Login bypass in Ubiquiti airMAX/airOS before 8.0.2, 7.2.5, 6.0.2, 5.6.15 if airControl web-UI was used

After seeing this arbitrary command execution vulnerability in Ubiquiti equipment, discovered by SEC Consult, I was intrigued. In that bug, code that would have been secure on a more recent version of PHP was rendered vulnerable because of the ancient PHP version used (2.0.1, which is nearly 20 years old). I wanted to see what other bugs might be caused by PHP that works in unexpected ways.

My friend owns a “NanoBeam AC” running firmware WA_v8.0.1, so I downloaded that firmware from Ubiquiti’s website and unpacked it with binwalk. I found a bunch of PHP scripts, a custom patched PHP 2.0.1 binary, and a custom patched Lighttpd server which handles session management and serves the files.

Continue reading Login bypass in Ubiquiti airMAX/airOS before 8.0.2, 7.2.5, 6.0.2, 5.6.15 if airControl web-UI was used

Passthrough more than 4 PCIe devices to Proxmox 4.4 and 5 guests

By default in Proxmox 4.4 and 5.0, you are unable to pass through more than 4 PCIe devices to the guest. If you try, you’ll get an error when attempting to start the VM which reads:

vm 100 - unable to parse value of 'hostpci4' - unknown setting 'hostpci4'

Passed-through PCIe devices are attached to the four ports called “ich9-pcie-port-{1,2,3,4}” which are defined in /usr/share/qemu-server/pve-q35.cfg. These ports occupy PCIe function numbers 0-3, leaving function numbers 4-7 unused.

It’s a simple matter to add definitions for an extra 4 ports to use up those spare function numbers in /usr/share/qemu-server/pve-q35.cfg: Continue reading Passthrough more than 4 PCIe devices to Proxmox 4.4 and 5 guests

Fix for macOS [High] Sierra 10.12.4+ “don’t steal mac OS” error on boot on Proxmox 4 and 5

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 5 and earlier.

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.

Instead, we can patch QEMU to fix the SMC support, using the fixes from here: Continue reading Fix for macOS [High] Sierra 10.12.4+ “don’t steal mac OS” error on boot on Proxmox 4 and 5

Accelerate IO for macOS Sierra Proxmox guests by passing through an NVMe SSD

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.

Note that in High Sierra, the built-in NVMe driver already supports most SSDs, and we don’t have to mess with it any more! Continue reading Accelerate IO for macOS Sierra Proxmox guests by passing through an NVMe SSD

Using Clover UEFI boot with Sierra on Proxmox

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.

However, there’s an issue at the moment with Clover and QEMU which causes macOS’s detected CPU speed to be wrong. This makes window animations, the system clock, movie players, typematic repeat, etc., run much too fast or too slow.

On Proxmox 4.4, we have to patch Clover to fix this, follow the instructions in the next section.

Proxmox 5 has support for telling macOS exactly what the CPU’s frequency is, by exposing a VMWare-style interface that macOS knows how to read. This fixes the CPU speed problem. So on Proxmox 5,  we can just edit the VM configuration to enable this feature, and afterwards we can install an unmodified official Clover release (I’m using r4097) using the install instructions further down this page.

Building your own copy of Clover with the QEMU CPU speed patch for Proxmox 4.4

You can either just download my prebuilt patched Clover r4061 / EDK2 r24132 installer, or follow the instructions in this section to patch and build Clover yourself.

We’ll be following the official Clover building instructions, but we’ll be modifying those slightly.

Install XCode from the App Store before you start. Run “sudo xcodebuild -license” to accept the license agreement. Run “sudo xcode-select –install” to ensure the command-line tools are installed.

Note that when the instructions say to make a directory called “src” in your home directory, you should listen! There are hardcoded paths that will look for built tools in that directory, so it’s much easier to just go with the flow here.

Fetching Clover source

Follow steps 1-3 from the section “compiling from source“, with some changes:

On the line that fetches EDK2:

svn co -r 18198 svn:// edk2

Fetch EDK2 revision 24132 instead:

svn co -r 24132 svn:// edk2

When it checks out the latest Clover source:

svn co svn:// Clover

Check out revision 4061 instead:

svn co -r 4061 svn:// Clover

You can skip the line that runs “./”, since we’ll be using XCode instead.

Apply the patch

User “arne ziegert” over on the Clover issue tracker came up with a patch to fix the CPU speed issue on QEMU, which we’ll apply before we build Clover.

Download this patch to “edk2/Clover”. Change into that directory and run:

svn patch clover-r4061-qemu-cpu-speed-patch.diff

Build Clover

Change into the “edk2/Clover” directory, and run:


The default options, which use XCode to build an X64 bootloader, are perfect for us.

After that completes, run “cd CloverPackage; ./makepkg”. This will produce an installable package for us in “edk2/Clover/CloverPackage/sym/Clover_v2.4k_r4061.pkg.”.

Proxmox 5: Enabling vmware-cpuid-freq support

In Proxmox 5, we don’t need to patch Clover, we just need to enable the vmware-cpuid-freq feature on the CPU in our VM’s configuration.

You should currently have an “args:” option in your VM configuration that contains:

-cpu Penryn,kvm=off,vendor=GenuineIntel

We need to edit that to add +invtsc to enable invariant timestamp counter support, add the vmware-cpuid-freq option, and turn kvm back on (exposing the fact that this is a virtual machine to macOS):

-cpu Penryn,kvm=on,vendor=GenuineIntel,+invtsc,vmware-cpuid-freq=on

Install Clover to the EFI partition

At this point you might want to take a snapshot of your Sierra install, so you can roll things back if it goes wrong. Though note that we will still be able to boot with Enoch/SeaBIOS even after we’re done, so if you mess up Clover/OVMF, you should be able to switch right back to SeaBIOS in your VM options to fix things.

Run the Clover.pkg installer in your Sierra guest:

The Clover installer should leave the EFI partition mounted for us. Open that up in Finder.

Replace the EFI/CLOVER/config.plist file with this one, which I got from Spaceinvader One’s unRAID tutorial.

Put this q35-acpi-dsdt.aml file from QEMU into “EFI/CLOVER/ACPI/origin”. (This file is no longer part of the latest QEMU revision, however the last revision which contained it can be browsed here.)

Configure Proxmox to use OVMF/UEFI

We’re nearly done! Just switch over to OVMF in your VM’s settings:

Now fire it up!

Editing your Clover/EFI settings in the future

You can use the Clover Configurator tool to edit your Clover configuration. This tool should mount the EFI partition for you. If you want to mount it manually, first check the device name of the EFI partition in the terminal:

~$ diskutil list
/dev/disk0 (external):
   #:             TYPE   NAME           SIZE       IDENTIFIER
   0: GUID_partition_scheme             512.1 GB   disk0
   1:              EFI   EFI            209.7 MB   disk0s1
   2:        Apple_HFS   Main           511.8 GB   disk0s2

Then you can mount it like so:

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

Alternative process: Dedicated Clover boot device

Rather than installing Clover by executing the .pkg on the guest, you can attach a dedicated Clover disk to your VM and just fill it with a Clover disk image that I’ve prepared.

On the hardware tab, add a new disk of size 1GB to hold Clover (if you’re already using IDE0 then add to IDE2). On the options tab, change the boot order to boot from this drive.

If you haven’t already switched your VM settings from SeaBIOS to OVMF, change the BIOS type to OVMF on the options tab, and add an EFI disk to store UEFI settings on the hardware tab.

If you have the Sierra install DVD mounted, make sure the line for that in your VM’s config contains the “media=cdrom” flag (unlike Enoch which needed that to be removed). For example:

sata0: local:iso/Install_macOS_Sierra.iso,media=cdrom,size=6074010K

Download this Clover disk image (5MB, uncompresses to 1GB), upload it to Proxmox and unpack it there with “gunzip clover-r4061-1gb.img.gz”. Now write that image onto the 1GB disk you added. For my ZFS-backed volume, that was accomplished with:

dd if=clover-r4061-1gb.img of=/dev/zvol/tank/vms/vm-104-disk-2 bs=1M

Be sure to get the device name correct so you don’t overwrite the wrong drive! Now you should be able to use this Clover boot disk to boot the Sierra installer, or an already-installed copy of Sierra.