Hacker News new | past | comments | ask | show | jobs | submit login
Documentation to set up a simple macOS VM in QEMU, accelerated by KVM (github.com)
298 points by paulcarroty 32 days ago | hide | past | web | favorite | 111 comments



I know it's bad security, but I'd be more interested in this if it supported old releases, like Snow Leopard or at least Mavericks (the latter being the final release with the Acqua UI).

I have a fantasy that I'll go back to Snow Leopard some day and live the rest of my life there, but then I remember hardware support is basically nonexistent. A very lightweight VM with GPU passthrough could work around that problem.


I have a Epson Perfection 4490 with no 64bit drivers. I will need to either run Windows or a older version of Mac OS / OS X. I'm sure there are other use cases where one will need a older system. I was actually going to go down the route or building a new Hackintosh but have opted o build a Linux desktop with Mac OS VM using GPU pass through. Using this I could have the latest Mac OS and a older version when needed.


Some info on getting the 4490 to work with Linux is here:

https://www.patrickmin.com/linux/tip.php?name=epson4490

The iscan-plugin-gt-x750 package referenced there was all I needed to get vuescan (https://www.hamrick.com/) to use the scanner on 64-bit Linux.


I run an old windows VM just for printer drivers too. Some reason CUPS just doesn't want to work with it.

Guess that's what I get for buying a weird $10 canon laser printer from Goodwill.


Have you checked whether Vuescan or Silverfast supports your scanner model? They are quite amazing with supporting old hardware.


Is this printer special in some way?


It'd also be useful for testing software on old releases. I work on scientific software. We are currently.... considering... dropping snow leopard support, but partners keep insisting that they use ancient systems. (We had a fight to drop CentOS 5 this year).


> I have a fantasy that I'll go back to Snow Leopard some day and live the rest of my life there

Why is that? Do you prefer the older macOSes? (I'm sympathetic to that viewpoint, but would like to know what about Snow Leopard specifically is what you like.)


Snow Leopard has the perfect metaphors for everything. This extends to many different areas, so I'll focus on apps as an example:

A Mac OS X app is just a particular type of file. You don't "install" apps any more than you'd install a photo or a PDF. Sure, standard practice is to copy apps to your /Applications folder, but in Snow Leopard, this directory didn't have any unique behavior. A Stack for the /Applications folder was placed on your Dock by default, but users were expected to modify the Dock's contents. I was free to organize my apps as I would would any type of file, and the OS felt built to encourage this. If I dragged an app from /Applications to my Desktop, the app got moved. If I dragged iTunes to the trash, iTunes got deleted.

You can certainly do this in later releases, but the OS will fight you! Dragging apps out of /Applications creates an alias, unless you remember to hold down the ⌘ key. Whereas I used to "install" most apps by dragging them to the same Stack I used to launch apps, doing the same with Launchpad just creates a shortcut, which will break if the original is removed.

Lion is when Apple began trying to make macOS more consistent with iOS, regardless of whether the changes were also consistent with the Mac's original UI paradigm. I realize I'm nitpicking, and to be clear, I'm mostly okay with everything through Mavericks, before they switched to an ugly and low-contrast visual style.

Snow Leopard was also my first experience with Mac OS X, so I don't know how much that affects my opinion. But my god, the first day I booted up Snow Leopard and settled into using it over the next few hours... as dumb as it sounds, I just recall a feeling of pure ecstasy.


> Snow Leopard was also my first experience with macOS, so I don't know how much that factors into things.

It's not just rose coloured glasses... I've used all of the classic Mac OS version and OS X from about 10.3 up to snow leopard, there were good, bad and ok versions, none terrible, all the way through there. But 10.6 was the best of the OS X in terms of stability and simplicity, from that point on it really felt like the whole system was being taken in a different direction, no more tick-tock feature-stability release schedule, and no more refinements, just more pseudo features to flash at prospective buyers, more bugs, more cruft, more unforgivable security mistakes, more bloat and far, far less control - basically turning into a bad iPhone as far as I was concerned.

I retreated to 10.6 for as long as I safely could then moved to a Linux desktop when they officially ended support for my machine deeming it obsolete.


Spaces on Leopard (pre-Mission Control) fit my brain like a glove. I'd love to get them back. I have 9 "spaces" in a horizontal row in Mission Control, but in the original Spaces they were in a 2D grid. The 2D gave me a sense of spacial reasoning about where things were.


Interesting! For me it wasn't until High Sierra that Spaces worked well. I have multiple monitors in a row, and want multiple spaces on each. I found unplugging screens (eg to take a laptop to a cafe) lost the apps attached to each screen. That no longer happens, and plugging it back in, each app / window returns to where it used to be.

I really like that. Feels intuitive and "sticky".


I have the opposite problem, apps/windows don't consistently return to where they used to be - in particular Slack never does (probably something with electron) but more frustratingly Messages never does either - it always goes to the same location on my primary display.


I don't know what boot environment this is emulating exactly, but it looks like a straightforward OVMF, presumably hacked up with HFS+ support and a bunch of Apple extensions to make macOS boot. In that case, running Mavericks should be no problem. I'd have thought Snow Leopard should also run, at least in K64 mode (64-bit kernel), but I've not tried it in a long time and don't recall if there were any gotchas.

Note also that software support is now pretty weak for these old releases - you struggle to find any modern web browsers that still run, for example.


> Note also that software support is now pretty weak for these old releases - you struggle to find any modern web browsers that still run, for example.

In my fantasy land, I would browse the web with Firefox ESR 45.9.0, which as of this moment is recent enough to be mostly usable.

Other than that, I feel like software support would be a mixed bag. Newer apps wouldn't work, but I'd gain compatibility with older apps that are broken on modern macOS. And since it looks like more and more future apps are just going to be bizarre iOS ports with alien UIs...


If you are running a PowerPC you can use this pretty up-to-date Firefox fork: https://www.floodgap.com/software/tenfourfox/


Thanks, I would love it if something like this existed for Intel processors.


Oh, Intel builds exist! https://sourceforge.net/projects/tenfourfox/files/unstable/c...

They're "unsupported", but, uh, so is Snow Leopard in 2019.


And yet another option: Arctic-Fox https://github.com/wicknix/Arctic-Fox

Massive kudos to the developers maintaining this stuff, it's all lovely!


Is there a reason why this method would not support Snow Leopard?


According to the readme, jumpstart.sh has just three options: --high-sierra, --mojave, or --catalina. Looking over it again now, I'm realizing those might just be what is available on Apple's servers... is there a way to pass in my own bootable installer image?

I imagine the underlying tech would (hopefully?) work, but I find the automatic script very appealing.


You can create an image from the Snow Leopard disc and pass it inside basic.sh (replacing BaseSystem.img).


That's great, thank you!


I too would do this.


I recently went the KVM MacOS/Hackintosh route (but not using this exact script) and while it functionally worked great— GPU Passthrough (Used RX580 and Vega 56), PCI Passthrough (USB Controller/Bluetooth/Wifi/Ethernet Card/SATA Controller/NVME Drive), iMessage, Handoff, AirDrop, etc. etc. I found it to be hassle on my consumer AMD motherboard with an AMD GPU.

With the AMD GPU, I had trouble resetting the GPU between VM starts/stops without restarting the whole computer. This appears to be a problem with a consumer AMD cards.

It could be specific to AMD Ryzen IOMMU Groups, but it was also pretty annoying to passthrough the PCI devices and still leave the appropriate hardware for the host machine. There aren't any native virtio drivers in OSX so you really need to pass through your sata controller/ethernet card for full performance. Might have been easier with a server motherboard with cleaner IOMMU groups, though.

I ended up just building a bare-metal Intel Hackintosh which was less of a hassle.


> I ended up just building a bare-metal Intel Hackintosh which was less of a hassle.

I think we need a new word to describe VM-hosted MacOS to distinguish from hardware hosted: QEMU + hack + Macintosh = Quackintosh ?


> There aren't any native virtio drivers in OSX

I could have sworn that macOS is supported as a guest under VMWare Fusion and/or ESXi hosts (when on Mac hardware), using some virtio drivers.


VMWare Fusion and ESXi support paravirtualized IO, but virtio is a specific KVM technology. Xen paravirtualized IO is similarly the same idea but not compatible.


VMWare doesn't use virtio as far as I'm aware.


This falls on deaf years but I say it every chance I get.

I would pay a significant premium to install MacOS on a machine without violating their ToS.


Since Apple isn't opposed to releasing new OS flavors, I think they should release "serverOS", a variant of macOS but licensed to run anywhere, even (or especially) on non-Apple hardware and in VMs.

It's very frustrating to a lot of people that macOS VMs aren't easy (licensing/ToS-wise) to spin up on non-Apple hardware, especially since Apple doesn't sell high-end servers any longer. Yes, that calculus will be different when the new Mac Pro begins to sell, but a lot of IT departments would rather add Apple VMs for testing/build/dev to their on existing on-premise compute clouds (vSphere/etc.) than spin up brand new ones on Apple hardware.

Additionally, there's a lot of demand for local Apple VMs on Windows machines. Microsoft makes a lot of money from software that's running on my Mac - especially Office and Windows (via Parallels Desktop or Boot Camp). Why shouldn't Apple make money from VMs running on Windows and Linux machines?


I would be very surprised if they didn't already have something like this internally for hosting iCloud and various other services. I agree it would be great for them to make it more widely available as a product.


Someone mentioned on HN a few months ago that they definitely do have large banks of both Apple-branded and non-Apple machines running a special in-house flavor of macOS. In fact, the last manufacturing run of XServe hardware had a more souped-up configuration than they ever offered to customers and was reserved for internal use at Apple.

It would be ... well, kind of them to offer IT solutions they use internally to other IT departments tasked to support work on Apple platforms. At the very minimum, they could license a version of macOS (or "serverOS") tuned for server workloads, VM deployments, and Apple Remote Desktop sessions.


It's a quip among colleagues that "macOS is not a server OS".

I have to run a bunch of VMs for builds, and I really wish I could be running Linux instead.


That doesn't mean the XNU kernel and core libraries couldn't be tuned to support compute- and network-bound workloads.


I don't know that it'd be worth the investment at this point. We already have our widely-supported Unixy system for that, Linux.

Furthermore, there's a longstanding (3 year) bug where the kernel would (very rarely) fail to execute a process. This would manifest as "/bin/sh: fail to execute binary file", because the posix_spawn() call returns an error (this is the actual bug), the libc interprets this as trying to execute a script, and falls back to running it through /bin/sh (this is standard Unix behavior), which can't execute it either because it's not a script.

That such a bug would persist for so long doesn't inspire confidence in the quality of the kernel.


> That such a bug would persist for so long doesn't inspire confidence in the quality of the kernel.

That says more about Apple's current priorities than anything else. Sure, Linux is more mature, but if Apple were to release serverOS for specific types of workloads that are needed, you can bet any bugs that would interfere significantly would be prioritized up.


Perhaps better yet they can build Apple-branded server hardware and compete with Azure and AWS on a Mac OS version of the cloud


It was called XServe. It died due to a bunch of reasons, mostly (I believe) having to do with price/power/performance of Intel chips.

https://en.m.wikipedia.org/wiki/Xserve


Server hardware is low-margin. Apple doesn't do low-margin.


Cloud hosting is high-margin, though


I would pay a premium to be able to install macOS on a cloud VM that I can scale arbitrarily large (and to arbitrarily many instances, presumably with premium for each). I'd like to do scalable CI and builds for macOS.

(Also, if someone can find a maintainable method for it, I'd love to support someone who maintains a cross-compiler toolchain that targets macOS, making it possible to build Rust and C apps for macOS without having macOS installed. But that's not a complete substitute for having an actual macOS cloud build server, on which the compiled applications can run as part of the build process.)


This toolchain can build C, C++ and Rust programs for macOS on Linux and FreeBSD. You'd need an Apple developer account to download the SDK.

https://github.com/tpoechtrager/osxcross


Handy!

How hard would it be to integrate something like that into rustup, to make it easy to install a capable cross-compiler backend?



No kidding. I would pay their entire iMac hardware margin for an OSX desktop license.


I'm afraid the markup would have to be a lot more than that. They're banking on you buying multiple pieces of hardware over the years, not just one iMac... Hardware lock-in is their whole business model...


We're talking about people like me who build their own desktops and wouldn't buy an Apple desktop otherwise. They could even make it a subscription.


Right, but how would they prevent eroding sales to people _not_ like you? That's exactly why the hardware lock-in model is so insidious.

> They could even make it a subscription.

Yes, my only point is that it would have to cost a lot more than the margin of a single iMac.


I see your point now. Oh well.


it falls on deaf ears because there are only dozens of us.


It always baffled me that Apple refuses to sell MacOS, they could capture a significant part of the OS market.


I don't fault them for it, they're a hardware company. Releasing the OS as a consumer product would probably destroy their hardware sales, since users (like me) wouldn't buy Apple hardware anymore.

But like I said, I would pay an outrageous fee to use MacOS on a non-Apple machine without violating the EULA. And I only want it for professional use, where I can justify certain expenses (like a $500 software license + yearly renewal for updates), but can't justify spending $2-5k on an Apple machine that won't give me the performance, maintenance, or upgrade path available from off the shelf components.

It's such a weird business calculus to develop for MacOS. I genuinely love their products and software, but it constantly feels like developers get screwed every generation (especially smaller shops that do heavy lifting on MacOS).


They probably wouldn't. Apple have very limited driver support, and they get away with that because of their tight hardware configurations.

The slickness of Mac OS X is partially because it's only deployed on high-end, well known hardware.


It would be a maintenance nightmare for Apple. MS puts a lot of resources towards making Windows run on everything. Apple controls the hardware with an iron fist so they don't have to do that.


But then how would Apple sell you a Mac Mini?


I'd buy a stack of Mac Mini's and leave them unplugged if it allowed me to provision dozens of Mac VMs on real server hardware.


I mean they're not selling me one now, I don't need a hot plate on my desk. But I would pay a (comparatively) obscene amount of money for just the operating system license to install on a midtower.


I wonder if anyone had success in running macOS VM on macOS via hvf acceleration. Would be a great free alternative to VMWare Fusion and Parallels.


Very recent versions of Qemu have "experimental" support for HVF, so in theory it should work. I haven't had a chance to try it yet, however, and it's possible that there are some MSRs or similar that aren't sufficiently supported yet. If this is something you(r employer/company) care about, feel free to get in touch as I suspect it's not too difficult to fix if it doesn't currently work.


I believe it did work 2 years ago, Veertu Desktop seemed to be based on the Qemu with HVF.


Yep, but back then I think it was just commercial -- I believe everything got upstreamed.

(The nice thing about Veertu using HVF was that it could ship a virtualization product in the App Store.)


Does anyone understand why this works on AMD processors without a custom Darwin kernel, as would be needed in a native AMD Hackintosh setup? The core x86 code is still getting executed natively, right? So, what magic does the VM perform?


Doesn't this violate Apple's licenses? AFAIR, MacOS is illegal to run on non-Apple hardware.


You may violate Apple's EULA by running macOS on non-Apple hardware, but it's not illegal (it's not a criminal offence).


most people don't understand the difference between a civil offence and a criminal offence (which is what i would use the term "illegal" to describe).

Violating a contract is not "illegal", but is a civil offense, and requires the other party to sue you to recover damages. Copyright infringement is also not "illegal", but is a civil offense (however, i do believe that a lot of copyright lobbies want to change copyright violations to be a criminal offence, so they won't need to sue, but instead use public prosecution to recover their damages).


This is terrible legal advice. Criminal penalties for copyright infringement offenses have existed since at least 1897 in the United States, and at least 1921 in Canada.


While I understand the point you were trying to convey WRT the differences between civil and criminal offenses, copyright infringement is not a particularly good example of this.

> The unauthorized reproduction or distribution of a copyrighted work is illegal. Criminal copyright infringement, including infringement without monetary gain, is investigated by the FBI and is punishable by fines and federal imprisonment. [0]

[0]: https://www.fbi.gov/investigate/white-collar-crime/piracy-ip...


It may be a violation of the DMCA, which makes it a criminal offence.


The only way this would violate the DMCA is if you pirated the operating system.


That depends pretty much on the jurisdiction.


I believe the MacOS license requires to run on Mac hardware, so in order to be compliant with the license you'd need to launch a big VM Linux on top of a beefy Mac Server then inside the big Linux VM provision all the MacOS VM instances you want using the utility mentioned in the post.


Unfortunately, you would fall afoul of their license doing this as well. They only allow you to virtualize two instances of macOS per host machine.

(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.


Or just install Linux on the Mac normally, though that's only really possible on the older pre-T2 models.


Sorry but this misconception needs to die. You can still boot linux perfectly fine on a Mac with a T2. All that's needed is a setting change.


You could also be running this on Linux that happens to be running on Apple hardware.


Linux does not run on modern Macs. You can boot it but there are virtually no drivers for even the basics like Wifi.


At least on older models, the drivers (e.g. Broadcom wifi) exist but aren't distributed with the OS installer due to licensing restrictions.


Unfortunately, this is no longer the case. Linux support for WiFi, audio, and suspend/hibernate has been completely broken on 15” MacBook Pros since the 2016 models hit (WiFi still works on the 13” MBPs, afaik).


Wow! I didn't know that. I "switched back" when there was no pro/NVidia option available to me about 7 years ago.


I don’t think informing people about ways to do things that go against software licenses violates the license.

Also, following these instructions doesn’t necessarily violate Apple’s license. You can run Linux on Apple hardware, and install Mac OS X on top of it, can’t you?

Finally, IANAL, but software licenses likely aren’t enforceable to consumers in large parts of the world (a shrink-wrap “take it or leave it” probably wouldn’t be considered an agreement between parties in many courts, and that’s what you need to call something a license)


One more thing (not mentioned in the docs) post-install is to use QemuUSBTablet-1.2.pkg, for nicer mouse interation.


This should no longer be necessary with newer Qemu versions (since 2.10 or 2.11 I think) as the USB tablet's device descriptor has been fixed to be standards-compliant in Qemu.

(Source: I'm the author of both that driver and the Qemu patch but I've not been able to spend much time on macOS virtualisation lately so it's possible things have started breaking again.)


Intereesting, thank you. I've been using this habitually since 3-4 macOS releases back, and didn't realize this might be no longer necessary.

Also thank you for the driver. :)


I've been interested in doing something like this so I can run an iMessage proxy. A lot of neat gateway apps for OSx have popped up (like https://www.wemessageapp.com) to get iMessage support on Android.


I've been doing this for years with some of my own personal projects like https://github.com/CamHenlin/imessageclient, https://github.com/CamHenlin/iMessageWebClient, and https://github.com/CamHenlin/imessagebot and some others - one thing that I'll note is that in my experience, Apple is pretty aggressive and somewhat arbitrary at banning accounts from accessing iMessages if they get on to the service from a VM - even if your usage is normal, personal iMessaging. I was trying out using VMWare and virtualbox specifically. In fact, I've been accidentally successful at getting my computer and home network banned from Apple services by accessing iMessages via VM. I strongly recommend running these types of services on bare metal Macs although ymmv.


How is the performance compared to running macOS on the same hardware (ie Hackintosh style)?


Poor unless you have a macOS-supported GPU to put through PCI passthrough. Otherwise, macOS will not use graphical acceleration and the system UI will be very glitchy (e.g. severe ghosting) and slow to respond.


Is the non-GPU passthrough performance bad enough to impact non-graphical applications? Is the whole UI just slow without it?


Well there are 3 realistic options here:

Intel igpus

Nvidia

AmdATI


Linus Tech Tips did a review of this method, including a performance comparison: https://www.youtube.com/watch?v=ATnpEOo3GJA


Ever boot your Mac in safe mode, where you can see the screen re-drawing because acceleration is off? It's like that.


It looks like this:

https://megous.com/dl/tmp/nbfcbjbdceowrvuepvoj.mp4

Software rendering. Not terrible. Ivy Bridge.

I did not even consider about messing with GPU passthrough.


With or without GPU passthrough?


Without


I'm not using this script, but it's reasonable. Good enough for Safari/web testing, or even running Xcode/iPhone emulator.


That's good to hear.

Is this a viable option to have running on a Linux box so that you can use it as a CI for testing iOS apps?

Or to be specific, what kind of specs, i.e. the amount of RAM would be needed to have a reasonable performance?

Thanks


For both iOS simulator and Safari, the lack of GPU acceleration can be a problem, depending on what/how you're trying to test, and also depending on OS version. I believe Xcode 11 requires a Metal-capable GPU in order to even run. As someone else has mentioned, you can however use IOMMU/PCIe passthrough with certain graphics cards to get acceleration inside the VM.


How good is the passthrough perf?

I'd like to build a hackintosh box with amd 3900x and amd rx5700 xt GPU - for video editing etc.

KVM seems like the only choice for AMD cpus. Will the GPU work with KVM? What mobo should I get?


can this handle 'xcodebuild' ?


That's my question. This seems hugely useful to automate MacOS builds in a sane manner. Yet, due to licensing I do wonder if it's even worth caring about.

If I use this at work I'd be risking my job on if Apple decides to sue my work for not following MacOS licensing for our build pipelines. If I use this in OSS / private software, I risk them suing me directly.

Shame, all I want to do is streamline providing software for Apples customers. You'd think Apple would want that more than some small money from a hypothetical non-Apple user merely trying to deliver products, functionality and improved UX to Apples customers. I feel like our (my and Apples) incentives are aligned. /shrug


I think part of the reasoning, perhaps misguided, is for quality assurance. It's easier for them to say our stuff runs only on our 'certified' hardware then to try and support everything under the moon.

These days I don't think that argument holds up though, back in the early days of x86 hardware and peripherals it made more sense.

In a past life we used mac minis sitting on a shelf in a datacenter to run builds off of, it worked well enough.


I just bought a used dual socket (E5 V2) server to play with KVM and to try do just this... I suspect, performance is probably pretty righteous even in the VM, and old xeon's like the 2667 V2 are dirt cheap these days. MacOS doesn't need much VRAM and old AMD cards are pretty cheap (GPU passthrough is easier with AMD cards [1]).

I'm really looking forward to running this later.

[1] I could be wrong on this, but from my previous research into gpu passthrough made it seem as though NVidias consumer cards aren't generally allowed to do it because they're driver locked.


Very nice. If this works on ec2/droplets, I might have found a good solution for my iOS/macOS CI needs.


Do the special network / bluetooth services (iCloud, iMessage, Handoff, AirDrop, AirPods) work with this setup?


Handoff requires a very specific set of Bluetooth hardware iirc, and it would need to be entirely passed through. So most likely no. And I believe that some of the iCloud services (specifically those entangled with iMessage/FaceTime) will require a valid SN (you can “generate” one by brute force though). It’ll also require that you give it two interfaces, one Ethernet and one wireless (and it’ll sometimes need to start a small wireless network for things like Airdrop).


Thanks! So if I were to build a new system just for this and could decide on the components, and had an old Mac Mini flying around whose SN I could take, then it should entirely be possible, right?


That’s generally preferable, yes, but I believe the SN needs to match the model identifier, and it’s generally best to match the model closest to the hardware you’re using. At that point, if it’s a specialized rig for this, I’d just skip out on KVM and just install it. Sites like tonymacx86 have build guides they keep up to date with the “most compatible” parts.


We should have a tool to create VMs on macOS as well. There is the new API but non of the FOSS tools using it. I am wondering why.


I assume by "new API" for VMs on macOS you mean Hypervisor.framework, which is supported by qemu 4.0.0 and xhyve, both open-source. I wrote a blog article about using qemu with Hypervisor.framework to install Debian in a VM here: https://sigmaris.info/blog/2019/04/automating-debian-install...


Excellent! Thank you very much for sharing, this is exactly what I was looking for.




Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: