
macOS 11 Virtualization Framework to Run Linux in a VM - _venkatasg
https://developer.apple.com/documentation/virtualization
======
saagarjha
Notably, Apple still has not released an Apple silicon chip that can do
virtualization. So as far as I can tell, this framework is currently not
testable on their systems using the A12Z.

~~~
bonyt
What were they doing with the A12Z when they demoed Linux running in a VM at
WWDC, then?

~~~
saagarjha
They must have not been using an A12Z for that.

~~~
fgdfgddfg
They already said they were using the mac mini with A12Z for the whole
presentation demo

~~~
ridiculous_fish
Parallels clearly has something significant under wraps:
[https://www.parallels.com/blogs/apple-silicon-
wwdc/](https://www.parallels.com/blogs/apple-silicon-wwdc/)

My guess: Parallels on Apple Silicon will support virtualizing AArch64 VMs,
_and also_ x64 VMs through Rosetta 2. Support for AArch64 alone doesn't seem
interesting enough to keep under wraps, and Apple did commit to supporting x64
JITs, so x64 VMs seems like a natural extension.

~~~
4ad
We'll see, but I doubt it.

A user-level emulator is a completely different beast performance wise than a
full system emulator. With a user-level emulator the kernel, and possibly even
the shared libraries are native code, and the code that needs to be emulated
is relatively easy to translate from one architecture to another.

For a full system emulator not only you need to emulate the kernel also, but
all the system-levels instructions have to be emulated as well (unlike user
space instruction that can be JITed).

Just compare the performance of qemu-system-aarch64 with qemu-aarch64 running
on amd64, and you will see a MASSIVE difference in performance. It's very
likely rosetta will be more optimised than qemu, but still there is a
fundamental problem here.

I'm sure qemu-system-x86_64 will run on aarch64 macs, but I doubt
Apple/Parallels/VMware will touch this space.

~~~
ridiculous_fish
Fair points, and on reflection you are probably correct.

But Apple has a history of weird but _successful_ systems that nobody else
tried, like 64 bit user space with a 32 bit kernel, or mixed-endian processes
sharing memory. And there's pointed coyness around "Apple Silicon" and
Parallels keeping mum. So I want to believe.

~~~
jki275
I need to believe because it makes a massive difference for me as an embedded
developer. I can't use Macs anymore if I can't run multiple x64/x86 Linux VMs
on them.

------
stock_toaster
Looks like this is just the "Virtualization Extensions" (apple silicon
support) for the hypervisor framework (which has been around since 10.10 and
is used by xhyve, and I believe the macos docker port?):
[https://developer.apple.com/documentation/hypervisor](https://developer.apple.com/documentation/hypervisor)

Is that correct?

~~~
saagarjha
No, this looks separate. You'll notice the APIs have to do with virtualized
networks and filesystems, rather than lower-level hypervisor tasks (creating
and running virtual machines, servicing exits, etc.)

~~~
lstamour
Possibly it was needed for no-driver virtualization while preserving the same
functionally of [https://blogs.vmware.com/teamfusion/2020/07/fusion-big-
sur-t...](https://blogs.vmware.com/teamfusion/2020/07/fusion-big-sur-tech-
preview.html) — note there’s a newer beta if you view the community link, I
think, and I can’t find an equivalent public beta from Parallels yet but
presumably they’re working hard on it...

~~~
pilif
That VMWare tech preview ran in Beta 2 already which didn’t have this
framework yet.

No kernel extension required

~~~
lstamour
I’ll admit though I ran it in Beta 2, I’m not aware of the details of which
release had which API or which features VMware is using or not. It’s possible
VMWare, having inside access to Apple docs, started working with private APIs
that Apple has now made public? I really don’t know the details, I’d be happy
if others chimed in, though. :)

------
pjmlp
Ironically the "Year of Desktop Linux" seems to be running GNU/Linux inside
VMs on macOS, Windows and even ChromeOS.

~~~
raghava
Year of "virtualized Linux on Desktops!" \- growing strong since 2010, powered
by Docker, k8s and Cloud.

~~~
pjmlp
Thing is, it all proves the point that most users of such solutions don't
really care about Linux per se, rather they want a POSIX CLI.

Otherwise they would be paying GNU/Linux OEMs.

~~~
raghava
Exactly. BlinGyUI on the streets, POSIX under the sheets - is what many really
want.

------
naetius
The real question here is how documented/open the boot loader is gonna be and
if (how) it'll be possible to just boot whatever ARM64 code instead of going
down the hypervisor way.

~~~
saagarjha
You might be interested in this video, specifically the parts of how boot
security works:
[https://developer.apple.com/videos/play/wwdc2020/10686/](https://developer.apple.com/videos/play/wwdc2020/10686/)

~~~
naetius
Yeah, I’m aware of that process. The question here is whether disabling secure
boot (which in that video would allow running “even old macOS versions”) would
also permit unsigned blobs to boot and set up the silicon.

We are still not sure about ASi’s memory map and if/how there are other
limitations that might prevent it from booting anything other than macOS.

------
sys_64738
Isn’t this just the HV FW that exists already? Would you really expect the API
to change between x86 and Apple ARM chips?

~~~
rafaelturk
Well hopefully not, however given that x86 and ARM are different CPUs API will
likely change

~~~
jen20
This is a _much_ higher level API - hypervisor.framework is documented here:
[https://developer.apple.com/documentation/hypervisor](https://developer.apple.com/documentation/hypervisor)

~~~
monocasa
Yeah, hypervisor.framework is a very thin passthrough to the Intel VMCS page
manipulation. It's so low level it wouldn't even make sense on an AMD CPU.

~~~
saagarjha
But they will be available on ARM?

~~~
duskwuff
Not without significant changes. The Hypervisor.framework API was quite
specific to x86.

~~~
saagarjha
Seems like the core API is the same to create and manage virtual machines,
it’s just that Intel-specific features like VMCS aren’t available on Apple
silicon.

------
antoncohen
I'm assuming Big Sur on ARM will be virtualizing ARM, not emulating Intel,
meaning a VM will need to run an ARM Linux distro.

In the short term I expect that to be problematic. First party packages in the
distro's package manager will be fine, but I expect it might be hard to find
some third-party software compiled for ARM Linux. And any Docker containers in
the Linux VM will need to use multi-arch or ARM Docker images.

~~~
LawnGnome
I don't think it'll be all that bad: one advantage of Raspberry Pis having
been out for several years is that there's already been some demand for ARM
and ARM64 builds of software.

Closed source, commercial software might be a bit more of a crapshoot, of
course, but this should provide a fair bit of impetus.

~~~
marcan_42
Actually, the rPi foundation have been extremely lazy about ARM64 support. The
Pi 3 and newer support it (and I run 64bit Arch on mine), but Raspbian does
not. I'd wager 95% of Pi users are stuck with 32-bit ARM software, as you have
to go out of your way for ARM64 support.

~~~
brirec
There is a beta build of Raspberry Pi OS (née Raspbian) in ARM64 available.
[https://www.raspberrypi.org/forums/viewtopic.php?p=1668160](https://www.raspberrypi.org/forums/viewtopic.php?p=1668160)

~~~
quaa55
This. plus fedora and arch/manjaro and many others have great aarch64 support.
pinebook pro user here.

------
hiphipjorge
There might be nothing available on this page right now, but wow is this
useful. I recently started doing some macOS dev and realized that this is a
pretty big limitation when it comes to my normal CI workflows. I know there
are some projects that dockerize macOS but they did not seem simple to work
with.

~~~
m463
> wow is this useful.

I agree.

I liked that you could run docker on osx, but there was no support for
something like FROM macosx:10.6

Maybe it will be possible? If apple put 1/1000th of the effort into
virtualization/containers that they put into emojis...

------
beamatronic
I don’t understand the headline. I already run Ubuntu, which is Linux, under
Virtual Box, on Mac.

~~~
nine_k
I suppose the idea is to not need VirtualBox, like in WSL under Windows.

~~~
saagarjha
It’s the same kind of emulation as VirtualBox. (And WSL2.)

~~~
nine_k
BTW AFAIK in Win10, _both_ the Windows kernel and the WSL2 Linux kernel run
under the same hypervisor. Apparently performance implications are minimal.

------
Alupis
Is it possible yet to virtualize an OSX install without breaking the EULA?

~~~
josteink
> Is it possible yet to virtualize an OSX install without breaking the EULA?

Has a single court of law yet made a ruling to set a precedent saying they are
legally binding?

If no, I’ll just keep treating EULAs like what they are: a corporate wish list
of unlawful restrictions they want to impose on their customers.

Why should anyone care about that?

~~~
Alupis
Why would it not be binding? It's a legal contract containing terms of use and
prohibited activities. You give consent too...

Many of the use cases for virtualizing OSX are for business purposes. Not a
great idea to build a business off pirated software and trampled software
licenses.

~~~
josteink
> Why would it not be binding?

By requesting and reading this reply you hereby grant me 50% of your future
income the next 5 years.

By your logic, this statement should legally binding too, _just because
someone somewhere wrote it and put it on your screen_.

Obviously it’s not though, so why should a EULA be different? It’s literally
the same thing.

~~~
nojito
[https://jolt.law.harvard.edu/digest/apple-inc-v-psystar-
corp](https://jolt.law.harvard.edu/digest/apple-inc-v-psystar-corp)

------
cV6WB
“No overview available.”

~~~
tonyedgecombe
Documentation has been my biggest frustration with Apple development.

~~~
jagged-chisel
Their documentation had been stellar until just around the new focus on Swift.
The C, C++, and Objective-C APIs were documented well, complete with guides on
the preferred way to use them. I think it might have been well before the
Swift switch that they headed downhill - I have a vague memory that some New
Big Features came along on OS X and the documentation was lacking and then
never caught up to the quality of the older stuff.

------
skee0083
Linux is just an app that runs in macOS and windows.

~~~
saagarjha
There's an app called iSH on TestFlight that gives you precisely that for iOS
as well ;)

~~~
deeblering4
iSH is actually pretty great, considering the compromises that must be made to
get a local shell on an iPhone.

Just wish it was debian based

------
beervirus
> No overview available.

Cool, why is this even posted?

~~~
saagarjha
Because it shipped as part of the SDK in the Big Sur beta today.

~~~
beervirus
It’s just a bunch of undocumented class names though.

~~~
zitterbewegung
That’s basically what you can get from apple at this time. They aren’t that
motivated for documentation.

~~~
balladeer
Most of the times when I face a problem on my Mac or iPhone I am surprised to
find an official support article by Apple for that problem. But the answer is
almost never in that article and then I have to anyway hunt for the answer on
the Internet.

------
nikolay
So, you create a problem... and then you create a solution. Windows 10 with
Terminal, winget, WSL2 with soon X Window beats macOS as a development
platform.

~~~
baddox
Well, no. What’s the problem they created?

~~~
creativeCak3
The fact that it is very unlikely that you will be able to run linux(or any
other OS; unix-based or otherwise) on a computer that you PAY(potentially more
than 1500 hundred dollars) and all you get some "BootCamp" Spagetti Windows on
the hardware asides from macOS. I'm sure the ones in the Apple Cult will still
pay for these ARM-based machines, but Apple really is shooting themselves the
foot with all this lockdown. And nybody who thinks this makes their platform
"secure" or "less prone to attacks" is full of it. I'm kind of interested in
seeing the clusterfuck this will turn into when Apple comes out with their own
proprietary firmware for EVERYTHING on their glorified Apple Silicon.

~~~
outworlder
Why so angry?

There will be some inconveniences, but the reign of desktop x86 can't come to
an end fast enough.

> The fact that it is very unlikely that you will be able to run linux

The jury is still out. There's some problem with _booting_ other operating
systems natively (BIOS support?). If people can get that to boot up, Linux on
ARM runs fine.

Apple has never supported Linux on Macs, and yet people have run it
successfully, myself included.

Also note that many (maybe most?) people get Apple computers in order to run
OSX. Linux users are a tiny minority - even Windows users are quite niche.

~~~
creativeCak3
I’m not angry about anything. Was just offering my POV. My point was, given
Apple’s recent history, they are going to lock down apple computers even
further now. Last I checked, you could not run anything other than what was
“approved” by Apple because they GLUED an ssd to a motherboard. Now that they
call the shots on the CPU(you know, the actual computer), they might require
people to log in with their icloud-crap account to just play candy crush on a
computer. And not that I care about karma, downvote away. But you all need to
chill.

~~~
saagarjha
> Last I checked, you could not run anything other than what was “approved” by
> Apple because they GLUED an ssd to a motherboard.

This isn’t really accurate at all.

