# Any success running MacOS in bhyve?



## zirias@ (May 14, 2021)

Did anyone ever succeed running (any version of) MacOS for x86 in a bhyve vm? If so, any pointers what to do to make it happen?

Background: I don't even want to use it. What I _really_ want to do is to (cross-)compile my own software for MacOS. So far, it seems the only way to obtain an SDK for MacOS is by installing X-Code, which only runs on Macs. In my naive mind, I consider it extremely unfair being forced to buy Apple hardware, just to be able to support their OS in my (free and opensource) software. There's no such problem targeting MS Windows, btw. So, any pointers how to cross-compile to MacOS without owning some Apple hardware would be welcome as well  Still, for testing, a VM would be nice of course.

Side note: Didn't know where to put this thread. Would a "virtualization" subforum make sense?


----------



## kpedersen (May 14, 2021)

I believe you need a VM platform that can simulate some various meta-data that makes the OS think it is running on a "genuine" Mac. The SMC (System Management Controller) is one thing it checks.

I doubt bhyve has this, however I believe it is very possible with VirtualBox. There is no reason the following can't work on FreeBSD's port (in particular, you can see the "setextradata" entries).

https://www.howtogeek.com/289594/how-to-install-macos-sierra-in-virtualbox-on-windows-10/

This should work at least until macOS goes entirely with Apple's vendor specific CPU.


----------



## zirias@ (May 14, 2021)

The problem with _that_ is that you can't have different hypervisors side by side… But maybe my desktop machine might be able to run that Apple stuff in vbox then…


----------



## SirDice (May 14, 2021)

Zirias said:


> Would a "virtualization" subforum make sense?


We have one, created not too long ago.

Wasn't there something in the Apple license that prevented anyone from running MacOS in a VM? Or was that for an older version of OS-X. I can remember something in this regard, just not the details.


----------



## kpedersen (May 14, 2021)

I think you could run one instance in a VM so long as it was on Apple hardware.

For all we know Zirias is running FreeBSD/bhyve on his fancy MacBook Pro


----------



## zirias@ (May 14, 2021)

SirDice said:


> We have one, created not too long ago.


Oops, no idea how I missed that  thanks for moving the thread 


kpedersen said:


> For all we know _*[FONT=monospace]Zirias[/FONT]*_ is running FreeBSD/bhyve on his fancy MacBook Pro


Yeah, of course


----------



## zirias@ (May 14, 2021)

SirDice said:


> Wasn't there something in the Apple license that prevented anyone from running MacOS in a VM?


I think there was something like that. The key issue here is Apple trying to prevent running their software on _any_ hardware not manufactured by them. It seems there _are_ ways around that (if vbox can do it), I'm just interested whether it is possible with bhyve…

And of course, the other part of the problem is that they don't publish SDKs in a way usable for anyone. They are "for free" with Xcode, but that requires you to run MacOS, which in turn requires you to buy their overpriced hardware. Heck, I'd even buy a MacOS license _if_ it came at a sane price and would allow me to run it on whatever hardware I like…

I wonder how people can point the finger towards Microsoft while at the same time praising Apple.

Well, end of rant


----------



## scottro (May 14, 2021)

The enemy of my enemy is my friend? 
Way back in the early 2000's Apple was kind of the good guy. They had just switched over to OSX as it was called then, and they were really nice to BSD folks. In Manhattan, they used to provide meeting space to the NYCBUG (NYC BSD User Group), for NYCBUG's monthly (at the time), meetings.

But these days, I think both MS and Apple are  pretty much considered evil.  Though MS acts more accepting of Linux, it still has all this telemetry stuff in Windows 10, as far as I know.  
And not a real ad, but makes me laugh every time I watch it.





_View: https://www.youtube.com/watch?v=KlIAg1SJ2uo_


As for the original topic, SirDice is correct, Apple only allows it done on Mac hardware. People have made Hackingtoshes, but they seem to break every time there's an upgrade. For awhile, there was a firm selling PC's running Apple at reasonable prices, but of course, Apple put them out of business.


----------



## Beastie7 (May 14, 2021)

Virtualizing macOS on non-apple hardware is against their EULA. Also, good luck getting I/Okit to work under bhyve.


----------



## trev (May 15, 2021)

You can find all the macOS SDKs here: https://github.com/phracker/MacOSX-SDKs/releases

Life is so much easier if you use Apple hardware (I use Mac minis for both FreeBSD and macOS). You can almost certainly pick up a cheap Intel Mac mini now that the M1s have been out a while. Fleabay has 2014 i5 models starting at ~$250 and 2018 ~$500 (USD).


----------



## Alain De Vos (May 15, 2021)

Years ago I have run MacOS in Virtualbox on Windows & Linux. It was a bit slow.


----------



## forquare (May 15, 2021)

Zirias said:


> So, any pointers how to cross-compile to MacOS without owning some Apple hardware would be welcome as well



It might depend on the language, I presume you're not using something like Python or Java.  Golang has the ability to cross-compile, IIRC this is how the gohugo project build software for many platforms (macOS, Linux, FreeBSD, OpenBSD, NetBSD, DragonflyBSD, and Windows on a mixture of x86, amd64, and arm architectures).
Another option to you would be to use something like Github Actions or Travis CI to build your project on macOS - both of which offer free options to open source projects.

Not virtualising for local building or testing, but hopefully a little helpful.


----------



## zirias@ (May 15, 2021)

forquare said:


> It might depend on the language


Right now, it's a library written in C and a GUI using it in C++/Qt.


forquare said:


> Another option to you would be to use something like Github Actions or Travis CI to build your project on macOS


Might be another alternative to look into, thanks. Well, for Windows, I can cross-compile locally on my FreeBSD machine (and of course, for Linux as well). It's a pity I don't find a way to do the same for MacOS…


----------



## kpedersen (May 15, 2021)

Zirias said:


> It's a pity I don't find a way to do the same for MacOS…


It is why Apple software bitrots pretty bad. Also many of us aren't satisfied by Apple that is pretty much exactly why we are on these forums!

I do recall that unlike gcc, our clang is a cross compiler. You just need to provide it with the correct system libraries (probably extracted from a macOS install).

Check out here the files which have been extracted from the Android NDK to allow for compiling with the base clang.

https://misc.openbsd.narkive.com/X6SlBaCB/android-development-on-openbsd

I'm not sure if this is a working solution, but it would be my attempt (if I didn't have a ratty 2nd hand mac mini laying around as a foot stool)


----------



## zirias@ (May 15, 2021)

kpedersen said:


> I do recall that unlike gcc, our clang is a cross compiler.


I actually use GCC for my cross-compiles to Windows and Linux. I think the difference is that with GCC, you have to configure it as a cross-compiler at build time, while clang supports different targets at runtime, does this sound correct?


----------



## kpedersen (May 15, 2021)

Zirias said:


> I actually use GCC for my cross-compiles to Windows and Linux. I think the difference is that with GCC, you have to configure it as a cross-compiler at build time, while clang supports different targets at runtime, does this sound correct?


Oh right. Very true.

Yes, sounds about right. With GCC you need a new build of the compiler for each target. Clang should target all the platforms provided they are compiled in initially (something to check!) without needing to be rebuilt.

My only worry is that Apple has extended their Clang compiler. I wouldn't be too worried about the *.app files. They are really just folders when opened up on other operating system and I believe the *.framework files are also just folders containing static libs. However I am not sure if our clang (in particular the linker) can handle .dylib (rather than .so) files.

Of course Apple also now has that app signing DRM for their vendor specific CPU these days (to only allow your compiled executables to run on your development machine and to prevent distribution outside their AppStore). However you can probably avoid that DRM for a few more years. The Intel CPU build of macOS doesn't enforce this.


----------



## zirias@ (May 15, 2021)

kpedersen said:


> Of course Apple also now has that app signing DRM for their vendor specific CPU these days (to only allow your compiled executables to run on your development machine and to prevent distribution outside their AppStore). However you can probably avoid that DRM for a few more years. The Intel CPU build of macOS doesn't enforce this.


Hell what. Ok, maybe I just abandon the whole idea and close the one Github issue of someone asking for a MacOS version with "go, buy a computer and install an operating system"


----------



## kpedersen (May 15, 2021)

Zirias said:


> Hell what. Ok, maybe I just abandon the whole idea and close the one Github issue of someone asking for a MacOS version with "go, buy a computer and install an operating system"


Yeah it is a big problem. Once people finally start getting hit by it in a couple of years, there will be a bit of an uproar (although, disappointingly people are fine with this same "developer DRM" mechanism on iOS).

https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution

... or, it could make source distribution popular again (because binaries no longer work across machines).


----------



## mtu (May 15, 2021)

kpedersen said:


> ... or, it could make source distribution popular again (because binaries no longer work across machines).


At which point Apple would require source code to be signed before allowing users to compile it


----------



## kpedersen (May 15, 2021)

mtu said:


> At which point Apple would require source code to be signed before allowing users to compile it


Yep. This is already the case for iOS and that has always been Apple's plan for macOS too. Unfortunately you can't even warn the typical computer user. They just don't understand and those that do, can't reach critical mass to change things.

It is basically a race to the bottom with companies like Apple. Ultimately we will be spending more time "jailbreaking" things rather than actually helping other humans achieve great things.

The best you can do is have the foresight to safeguard yourself. And that means using / migrating to an OS now that has a future. Even if it isn't necessarily as "user-friendly" yet. Ultimately those that are just getting by with "whatever works" are technically part of the problem (not that I particularly care. If anything it is fun to watch the drama when the sh*t hits the fan and charge a high fee to "fix" things).


----------



## ziomario (Jun 7, 2022)

I'm working with some developers to add the virtualization of the MacOS on bhyve. Unfortunately I think that it will be not added soon. Is one of them who explains the reason :

"Bhyve doesn’t emulates the CPU as Penryn. Additionally, it doesn’t emulate all the MSRs. I’m not aware of any method to log all vm-exits of bhyve".

It seems that there is a method to virtualize an old version of Snow Leopard with the bootloader Chamaleon that doesn't require the flag "Penryn",but then it will not work anyway because bhyve does not support the MSRs....


----------



## Alain De Vos (Jun 8, 2022)

That's a very old cpu. qemu can emulate but that will be very slow.


----------



## hardworkingnewbie (Jun 8, 2022)

The issue is: 2-3 more years and there will be no MacOS any longer which runs on Intel CPUs; only Apple's own ARM processor line instead.


----------



## ziomario (Jun 8, 2022)

FreeBSD and bhyve for arm64 do exist ?


----------



## Alain De Vos (Jun 8, 2022)

Not on arm64


----------



## getopt (Jun 9, 2022)

scottro said:


> The enemy of my enemy is my friend?
> Way back in the early 2000's Apple was kind of the good guy.


Not exactly my perception. I abandoned Apple ever since retiring my Apple IIe for an IBM PS/2 mod 60. That made me the owner of an IBM Model M keyboard I still love to hack on.








						Why I Still Use a 34-Year-Old IBM Model M Keyboard
					

In a world where rapidly changing technology feels increasingly disposable, one thing remains constant in my computer setup: my 34-year-old IBM 101-key Enhanced Keyboard, commonly known as the Model M. Here’s why I’ll never give up its clicky keys and ideal layout.




					www.howtogeek.com
				




While Apple Inc started 1984 marketing its design of products (Macintosh) for reasoning inflated consumer prices of their products, the main reason for not buying Apple was the lack of compatibility with the rest of the IT hardware world.

The worm in Apple is the "genetic defect" of wanted incompatibility. It's their "DNA" and that never will get a repair.


----------



## ziomario (Jun 10, 2022)

Alain De Vos said:


> That's a very old cpu. qemu can emulate but that will be very slow.



who cares about qemu on freebsd if it is not accelerated with kvm ? it's useless. Instead,what about haxm ? if qemu can be accelerated with haxm this will be interesting.


----------



## kpedersen (Jun 10, 2022)

ziomario said:


> who cares about qemu on freebsd if it is not accelerated with kvm ? it's useless.


Typical qemu, yes (unless you like retro DOS games 

However qemu-static on FreeBSD is fairly good. It only emulates userland; leaving the expensive parts (kernel, X11) to the native host. This means that speeds are actually very reasonable. An aarch jail using qemu-static is quite competitive to using a Raspberry Pi 4.


----------



## ziomario (Jun 11, 2022)

I'm reading here :​







						Add Support for FreeBSD? · Issue #106 · intel/haxm
					






					github.com
				



the comment of  *JayFoxRox is *interesting for me when he says :



As a host: Last I checked, FreeBSD had a KVM kernel module. Even if that was removed again, it's probably easier to fix it up, rather than working on HAXM (which uses a very similar interface, but has less features at the time of writing).
With competition by WHPX and HVF I assume that HAXM will eventually fade into obscurity unless it can find its niche, or the 2 first-party APIs suddenly stop being worked on. HAXMs major benefit over those APIs is that it's open-source and supports older versions of host OS. However, the same is true for KVM, which also happens to be a more mature project (with very active development, as there's no competition on Linux).


So,if it is not so much complicated to fix KVM,why no one is interested to do this ? Adding KVM to qemu will be a very added value to FreeBSD. The guys at Dragonfly-BSD acceelerate qemu with NVMM. Anyway Bhyve is still not so good such as qemu+kvm.


----------



## ziomario (Jun 14, 2022)

I don't know.


----------

