OS X-KVM: Running Mac OS X El Capitan on KVM and QEMU | Hacker News Reader

OS X-KVM: Running Mac OS X El Capitan on KVM and QEMU

github.com

185 pointstambourine_man89 comments

I tried doing this the other day, hoping that I would finally be able to get a working OSX setup on my desktop (have made several attempts with no success at getting it working bare-metal on my Z600). Sadly it just ended with more kernel panics, something I was hoping would be avoided as I got the impression from some sources that QEMU was a more straightforward solution than trying to run it on bare-metal.

Having said that, I've been getting more and more frustrated with OSX (had a great experience with Leopard on a PowerBook G4, and my 2013 MacBook Air is easily the best laptop I've owned, however personally I don't care for the direction that they are taking OSX these days), and ended up using it as an excuse to update to the latest version of elementary OS, which certainly isn't without its teething problems.

   Z600

That's a bit old. Modern Hackentoshes are actually pretty solid on consumer hardware. Z79/Z79, Z170 are pretty much fully supported. Some forum posters claim they've gotten dual 4th Xeon boards to work.

I set one up on my Z79+i7-4790k. It was a breeze. Took about 90minutes following tutorials. My biggest problems were:

-I set up the wrong sound driver

-Nvidia won't detect/modify hot plugging displays you have to manually edit OSX's version of xorg.conf

-Apple's Nvidia driver didn't support GSync or 144Hz. So I had to dealing with image tearing :\

-Non Apple keyboards had weird character mismatching. Had to purchase an Apple USB keyboard.

I ended up reverting because I like my IBM Model M, and losing hardware level vsync was a no-go.

> Apple's Nvidia driver didn't support GSync or 144Hz. So I had to dealing with image tearing :\

The Mac drivers Nvidia released yesterday finally support G-Sync.

> Non Apple keyboards had weird character mismatching. Had to purchase an Apple USB keyboard.

You can fix this by not skipping the keyboard setup wizard that pops up when you plug in an unknown keyboard.

I actually never got the popup. IBM Model M is PS/2 not USB so it has to be plugged in on boot as the UEFI/Bios won't let you hot plug.

You probably could have used a PS/2 -> USB adapter.

Actually no IBM M has a >500mA inrush draw so

-Not all converters support it

-Some converters that support it, are disabled by the motherboard as the converter is exceeding spec.

    but valarauca why don't you use an externally powered hub?

I've actually tired 4 different models, none have worked. I've just accepted that using a PS/2 plug on the motherboard is less of a head ache.

I do have a PS/2 -> USB converter that works, but only with 1 of my motherboards (a VIA). Except it knocks out the other USB port stacked above/below it. I don't plug anything into that port for the PS/2 -> USB converter, just that port will never recognize something is plugged into it. I think it is a power draw issue.

-Non Apple keyboards had weird character mismatching. Had to purchase an Apple USB keyboard.

Karabiner is useful for this - for pretty much every keyboard layout you have a tick that remaps it to PC keyboard.

Unfortunately Karabiner is broken on Sierra; they are working on workarounds though. -- macOS Sierra support status

Karabiner does not work on macOS Sierra at the moment.

We are developing Karabiner-Elements which provides simple key modification for macOS Sierra at first. (Karabiner-Elements works on macOS Sierra except prefernces GUI.) --- https://pqrs.org/osx/karabiner/

I clean installed macOS Sierra on my 2013 Macbook Air this week it seems just fine to me. So far, I only have a couple of issues with it:

1) more bloat (but almost every OS has this problem).

2) cuts off support for some older Macs for no good reason.

One thing I really like the new default terminal font: San Francisco Mono. I don't know if that font is new to the OS entirely but I really like it.

I also really like that you can have the Finder sort folders before files. This should have been added a long time ago, but better late than never.

A clean install of Sierra is actually smaller than El Capitan, so it depends how you define bloat.

SF Mono is indeed new. Thank you for pointing that out. I missed it. Very nice.

The reason they cut off older macs was due to them not having AES accel in the CPU, so there was a small reason for it.

From the ARS review: "It’s not related to AES encryption acceleration, since there are Core 2 Duo and Core i3 CPUs in supported Macs that don’t support Intel’s AES-NI acceleration."

http://arstechnica.com/apple/2016/09/macos-10-12-sierra-the-...

This little line, copyrighted by Apple, is what I understand to be the legal protection they have against people running OS X on non-Apple hardware:

https://github.com/kholia/OSX-KVM/blob/476ae8b082088049f2f8c...

I would not be surprised if a DMCA takedown will be filed against this repository soon.

More information here: http://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/#sec_3_2_1

I doubt that line ("ourhardworkbythesewordsguardedpleasedontsteal") is creative enough to meet the threshold of originality required for something to be protected by copyright.

Even if it actually were copyrightable/trademarked it wouldn't be a valid legal strategy to prevent fair-use:

https://en.wikipedia.org/wiki/Sega_v._Accolade

I wouldn't be so sure. That case predates the DMCA - see also the AACS encryption key controversy.

They could take it out of the repo and imply heavily that people should Google it. It's pretty easy to find on other websites and forum posts.

"A secret value goes here. Google 'isa-applesmc' and maybe you'll find it."

The OSX license agreement severely limits the practicality of this: http://images.apple.com/legal/sla/docs/macOS1012.pdf

It only allows you:

Section 2B(iii): "to install, use and run up to two (2) additional copies or instances of the Apple Software within virtual operating system environments on each Mac Computer you own or control that is already running the Apple Software, for purposes of: (a) software development; (b) testing during software development; (c) using macOS Server; or (d) personal, non-commercial use.

The grant set forth in Section 2B(iii) above does not permit you to use the virtualized copies or instances of the Apple Software in connection with service bureau, time-sharing, terminal sharing or other similar types of services."

So...? Don't do this at work.

Who actually takes software licenses seriously in their own home?

I do. I mean... seems pretty hypocritical for a coder who's made most of their income from software NOT to.

I'm sure there are plenty of us who've only written open source and/or bespoke software.

I write software for free and as a living, so I surely take it seriously. How can a software developer justify stealing software, unless they're trapped in a poor or technologically restricted situation (Cuba)?

EDIT: There's some confusion as to what I replied to:

My reply is to this

    Who actually takes software licenses seriously in their own home?

If this doesn't imply one's okay with stealing, then I take my comment back.

> How can a software developer justify stealing software

Oh come on. Running a legally obtained OSX installation on hardware you own is hardly stealing.

I don't see why OSX "fanboys" constantly bring up this tiresome meme about OSX being this near "holy" OS which cannot run on anything but this similarly holy Apple hardware.

It's a generic consumer OS designed to work on what is mostly run of the mill X86 hardware. Get with the times.

My reply is to this

    Who actually takes software licenses seriously in their own home?

If this doesn't imply one's okay with stealing, then I take my comment back.

Because you seem to assume I use a mac, I must confess to not owning one and therefore not using macos.

I read it as "who cares about obscure constraints which if violated will severely limit my ability to get support should I need it", not as a blanket licence to pirate software.

Obviously in a professional context, you will care about things like support. But probably not for your lets have fun hackety hack project at home.

Think you're reading too much into it. Most software license agreements have silly rules and restrictions that nobody takes any notice of - at home. Businesses have to be more careful.

It's not "stealing" if you paid for a license. By your logic, jailbreaking an iPhone would constitute theft.

It's more akin to installing iOS on a Nexus phone.

Which, in turn, would be a pretty impressive achievement, and certainly worthy of an HN story.

Agreed.

I am surprised at how many people on HN show negative attitude toward compliancy with the EULA. I thought HNers had a respect for software license.

I would hope that most people on HN are knowledgeable enough to agree with the EFF's take on EULAs -- they are of questionable legality, and "dangerous for consumers and innovators alike"[1].

[1]: https://www.eff.org/wp/dangerous-terms-users-guide-eulas

When a tool dictates how and where its human owner is allowed to use it, that's too dystopian for me to support.

Is this EULA enforceable in every legislation or is it only an US issue?

Any specific information about the Apple EULA in the EU, for instance?

Look, from a legal perspective this is a matter of civil procedure. For Apple to enforce this agreement it has to first discover your usage and then prove its damages in a court. The damages would likely be the cost of Mac hardware of equivalent power to the VMs plus legal fees.

What this means is that no one should spin up a server farm of OS X VMs and then blog about it. For everyone else, Apple is not going to discover you and if they do they are not going to pursue damages against you for the cost of a Mac Mini. Apple is just not out there doing that type of lawsuit

You know, after spending sooooo many thousands of dollars on iPads, MacBooks, iPhones, iTunes, iTunes Match, and the developer program, I just can't bring myself to feel bad about running an instance or two of OSX in a VM.

The part of that EULA section that really gives me trouble is "...that is already running the Apple Software...".

I want to run OSX in a VM on my MacBook Pro with Windows as the host OS. I used to do it the other way around, boot into OSX and run Windows in a Parallels VM. These days most of my work is in Windows, especially VR work, so it's more practical to boot into Windows. (And I like Windows better than OSX anyway.)

But I still do need to test on OSX occasionally. In an ideal world, since I have VMware installed on Windows, I could just boot up an OSX VM.

But because of that one EULA phrase, OSX will never be supported by a commercial vendor like VMware or a large open source product like VirtualBox - even on Mac hardware!

This leaves booting back to OSX as the only way to run it, and rebooting back and forth is a real pain.

All I want to do is run my legally licensed Windows and legally licensed OSX, and have it be my own choice which one to run as the host OS.

It's pretty easy to solve that issue by applying a community made fix: http://www.insanelymac.com/forum/files/file/339-unlocker/

Thank you very much! That looks like a perfect solution for me.

I especially like the fact that it's Python source code, so I can look at the code and get some sense of comfort that it doesn't have anything sketchy in it.

he'll still be in violation of the EULA though...

I'm not too worried about that. I doubt if Apple will get on my case for running OSX on my MacBook Pro!

There is a "VMware Unlocker" tool of extremely questionable legality that can enable running OS X as a guest of VMware Player / Workstation on Windows.

The unlocker tool sits in the usual legal gray area of software mods, of course running macOS on non-Apple hardware is against the EULA.

That is pretty impressive. I spent hours upon hours getting OS X to run on a Linux host in KVM and QEMU. Eventually I did get it to work, but things like Messages.app had no chance of working. That was actually my goal - to create my own little Messages API so that I could send automated messages to myself. I ended up just scripting Messages.app on a real Mac and that works really well, even 2 years after. I remote control my house that way.

> I ended up just scripting Messages.app on a real Mac and that works really well, even 2 years after. I remote control my house that way.

That sounds pretty neat, do you have more details written down anywhere?

Pretty neat indeed.

It's sad though that one has to virtualize an entire OS just because a messaging system doesn't offer an open API.

The world is getting more proprietary ... sadly.

In some ways, yes. On the other hand, free software is also everywhere. Linux, Webkit/Blink/Firefox, Apache/nginx, LLVM/GCC, Emacs/Vim… it's a pretty big list.

Instant messaging and Pro Photo/Video apps are a particularly sore point.

I've installed an AppleScript handler from within Messages.app. The script below is called ReceiveMessage.script and is located in ~/Library/Application Scripts/com.apple.iChat and basically accepts messages. That's how I handle inbound messages, and for outbound I basically also have a separate script for sending out messages. I do the actual work in separate python scripts called by the shell scripts though.

-- snip snip --

using terms from application "Messages" on message received theText from theBuddy for theChat set quoted_message to quoted form of theText set quoted_id to quoted form of (id of theBuddy as text) do shell script "echo " & quoted_message & " | ~/bin/MessageReceive.sh " & quoted_id & " > /dev/null 2>&1 &"

        # make messages happy
        return true
    end message received

    on message sent theMessage for theChat

    end message sent

    on active chat message received

    end active chat message received

    on chat room message received theMessage from theBuddy for theChat

    end chat room message received

    on addressed chat room message received theMessage from theBuddy for theChat

    end addressed chat room message received

    on addressed message received theMessage from theBuddy for theChat

    end addressed message received

    on av chat started

    end av chat started

    on av chat ended

    end av chat ended

    on login finished for theService

    end login finished

    on logout finished for theService

    end logout finished

    on buddy became available theBuddy

    end buddy became available

    on buddy became unavailable theBuddy

    end buddy became unavailable

    on completed file transfer

    end completed file transfer

end using terms from

I like the project, but I really don't like applescript. In programming languages, it seems there is a tension between easy-to-write and easy-to-read. And I suppose a fork in the continuum with easy-to-read-for-novices and easy-to-read-for-programmers.

applescript went overboard on the easy-to-read-for-novices at severe cost to easy-to-write.

What's hard to read about it? Obviously (to me), those are all event handlers. Not sure why (or if?) you have to define the ones that don't actually do anything, though.

I'm pretty sure he's saying that they made it too easy to read, at the expense of being easy to write (with the premise that these are opposite ends of a spectrum stated above)

FWIW you can use JavaScript now instead of AppleScript.

The formatting got borked, but this is very cool. Could I contact you to get additional details?

Edit: my email is in my profile

Thanks for following up with details! I wasn't aware you could do this with Messages, that's a nice interface to know about.

Since there was a bit of interest, I wrote this up in a short blog article: https://news.ycombinator.com/item?id=12563526

El Capitan runs perfectly in Virtualbox on Arch for me.

Now that's interesting. Does it work in headless mode? (Accessible via VNC).

Keep in mind that if you're using the boot.sh method, the NIC's MAC seems to be hardcoded in the script [1]. You might want to change that.

[1] https://github.com/kholia/OSX-KVM/blob/476ae8b082088049f2f8c...

I compiled a document the other day with a lot of links on the subject of macOS virtualization, for anyone interested:

https://docs.google.com/document/d/1VwLJqgc2VkD-EZnMzSFmZRq0...

This is really cool. Someone fork this locally before Apple sends their takedown notice.

There's nothing illegal about this if you're running KVM on Mac hardware and virtualizing OS X (er, macOS).

You don't really need to do anything besides a normal `git clone`; any clone is as good as any other, really.

If the project disappears from Github someone would need to find a different place to host collaborative development, though. Maybe there needs to be some sort of Github-alternative in a friendly jurisdiction for projects that are too controversial to host on a mainstream provider in the US? E.g. for DMCA-violating projects, video codecs, DRM removal tools, etc.? I'm not that familiar with the alternatives but it wouldn't surprise me if there are better options in terms of resistance to US court orders.

Does this support 3D hardware acceleration? That seems to be a common problem for these types of setups.

Hardware acceleration can be done using PCI passthrough to pass your graphics card on to the guest OS. IOMMU and VFIO are two terms I commonly see associated with this, but having never done it myself I am not sure what the difference between them is - perhaps someone can chime in?

VT-d = Virtualization Technology for Directed I/O which basically means the CPU has an IOMMU, the IOMMU is a piece of hardware for doing PCIe DMA re-mapping to provide VM isolation. VFIO is the linux driver for passing through IOMMU devices.

AFAIK the only way to achieve this is to pass-through a GPU via VT-d. This config does not appear to support this though. If you search github for this line, you will find other configs that support doing this- https://github.com/kholia/OSX-KVM/blob/master/macOS-libvirt....

Edit: It's relatively easy- blacklist (or uninstall) GPU drivers from host machine, and pass the PCI address to qemu. Performance is not perceptibly different from native. Other things you probably want to do are enable hugepages, pin virtual cpus to physical cores, and use vfio for network- https://github.com/pmj/virtio-net-osx.

It's also possible to run boot OSX using UEFI mode, which removes the need for the binary blobs in this repo.

The script seems to use qemu's default VGA graphics chip. I'm not sure whether you can get anything faster to work, given Apple's limited graphics driver support.

Is it possible to run several OS' on a single machine with fast switching between them, access to all hardware, and at full or almost full speed?

Using Vmware, and passthrough for the videocard you can achieve this with Linux as the host and Windows as the guest.

Not sure if it's possible with OSX.

What we really need are video drivers for OSX, for virtualbox and/or other virtualisation solutons, so OSX as a guest can work really well.

And you can't easily switch between several virtualized machines like that. Windows will bluescreen if you remove a graphics card while in use, and I'm not sure OSX/Linux guests will fare better.

Passthrough only really works reliably if you only have one guest active at a time and never try to use the graphics card from the host.

OS X has official Nvidia drivers.

VGA passthrough is also possible with KVM. I wonder if Oracle has any plans to add it to VirtualBox? It seems they have made room for KVM support, so in theory they could.

I have seen all OSX versions from Leopard to El Capitan successfully running as a VB guest, but the graphics support has always been bad, since there are no Guest Additions for OSX (BTW this also means no bidirectional clipboard, drag & drop of files, etc..)

There's some support:

https://www.virtualbox.org/manual/ch09.html#pcipassthrough

Suprisingly OS X actually has decent support for a wide array of video cards out of the box, all of the AMD GCN 1.0 (7000 series and the R7/R9 2XXX rebrands of them) work out of the box as does the R9 290X/390X, along with a bunch of the older HD4000-HD6000 cards. NVidia provides native drivers for all their cards online, and if you're using an Intel GPU that was ever in a Mac it has support as well.

Of course, it's in violation of the macOS EULA to run it on non-Apple hardware in the first place, but you'd be surprised just how much hardware it supports.

VMware only has passthrough support for ESXi/vSphere. Not for VMware workstation or VMware Player. So unfortunately not with Linux as a host.

For the record, VMware Fusion also does not support PCIe passthrough.

Up to a point. There's Hardware Partitioning in which the hardware allows you to specify which processors or memory are dedicated to which OS but there's little dynamic sharing. The only real way to do dynamic resource sharing is with software virtualization (which does still require hardware features, but many platforms support this nowadays) where either the OSes run under a Hypervisor layer, or one OS runs in a virtual machine running as an application within another. Arguably the latter is just a variation on the former. Or vice versa depending who you ask.

https://en.wikipedia.org/wiki/Logical_partition http://www.computerworld.com/article/2593387/server-partitio...

So, what would be the best solution to run three (Fedora, Windows 8 or 10 and OSX or more) OS' under a common hypervisor and achieve (almost) full speed? Or alternatively, Fedora as main and the other ones as VMs, but also with (almost) full speed and graphics acceleration.

A KVM Hypervisor would be ideal, in my experience and opinion. Using the virtio drivers will give you great performance for virtualized devices like disks and NICs, and you can also directly attach devices and use PCI passthrough to achieve full-native performance for a device in the guest OS.

You're not going to get full speed, but it depends on what you want to be fast. Graphics intensive activities are going to be constrained by the specifics of the design you go for. Apart from that the biggest constraint is memory since every GB allocated to one OS will by definition not be available to the others. However CPU support for virtualization is pretty good these days. Most of the i7 and i5 CPUs have built in instructions to make it pretty efficient for processor tasks.

Personally I have a 2014 5K iMac i7 with a fusion drive. I have a Fedora VM on it I run occasionally. I run it using Virtualbox which is a free virtualization system. I've allocated 4 GB of memory and it's very performant. It's a great way to try out virtualization at home and you can run Virtualbox on Linux, OSX or Windows as the host OS.

Crap situation for me then since I need CPU, GPU, and RAM to the max for Video and 3D DCC apps.

Somehow, I thought there was this magical hypervisor that would give all to one OS that I could use and then, out of nowhere, I could switch to another OS in a way that first one would go to sleep and its memory put on hard drive and the other one would wake up its memory from hard drive and show up. I wouldn't need them running concurrently, but I would like to have them switch fast.

In a way I would like to consolidate three machines into one without having to run three machines or wait for shutdown/boot sequences (with multi boot).

Bonus would be to share disks (non boot ones) and copy and paste. That would be really great.

Of course. I run ESXi (bare metal hypervisor) with various Windows and Linux VMs running on it. One of the Windows VMs even has my GPU passed through to it and gets near-native gaming performance.

I'm assuming you are using an AMD GPU?

The last time I looked, there were significant challenges with getting a Nvidia or iGPU to work.

Yes, AMD. I would prefer Nvidia, but it is what it is.

The issues I know of with GPU passthrough are:

Non-Quadro NVIDIA cards don't want to work in a VM so you need to disguise KVM to get them to work. NVIDIA says this is a bug but I think they just want you to buy quadro cards. [1]

AMD Bonaire and Hawaii architecture cards have issues with resetting in a VM, so you can't let the VM go to sleep or shutdown. Newer (R9 480) or older AMD cards don't have this issue. [2]

[1]: http://vfio.blogspot.com/2014/08/vfiovga-faq.html?m=1 [2]: http://vfio.blogspot.com/2015/04/progress-on-amd-front.html?...

(not my blog)

Do you have a source that confirms that the 480 doesn't have this issue? I currently have a set of scripts that disable/enable my 380X automatically when my VM stops/starts and I would love to get rid of them (and get a new card as well).

They don't want to work, but they do. I have no issue with my GTX1070 after a few minutes after playing with some KVM settings.

Does anyone know how to get the ISO image, or the installer via the recovery boot (cmd+r)?

I'm having a really hard time running the Apple App Store BEFORE I install the OS. There's kind of a circular dependency there.

Very cool; currently the bash script assumes the old "OS X" naming convention of the installation app. To make it work with "macOS" Sierra, some simple changes are required.

This will probably be taken down soom, mainly because of the link to the El Capitan ISO

Reply on news.ycombinator.com