Can you share any info about macOS guest support?

[viking1304]

@Mikero can you share any info about macOS guest support? I am really eager to participate in testing when it's ready.

Even if you can't share any ETA, "we are working on it" would be appreciated.

[Mikero]

It's something we're working on, yes.

The challenge is that it basically means we can't use any of our existing hypervisor stack or APIs, we have to use all Apple's.

There are drawbacks to this. There are no APIs for things like clones, snapshots, suspend/resume, and the VMs wouldn't be compatible with vSphere (ESXi-ARM for example). We basically have to start from scratch entirely in the UI.

It's not exactly a short-term project... and the APIs are all brand new, so they may not meet our quality or UX bar yet (this has happened before, take the paravirtual GPU for macOS guests on Intel...Nice tech, missing some critical APIs and is somewhat crashy, but Apple never bothered to fix it on Intel and we're not going to try and support a broken feature that we can't fix...).

The real tough part is that Apple doesn't care so much about backwards compatibility, so API's can have big changes annually, and fixes/changes don't get backported all the time, so that dynamic might cause some heartburn during the development process. 

But we're peeling back the onion, hoping we don't cry all over the place.

[jldement]

Is there any update on support for X86 machine architecture?

All the virtual machines I care about are on this machine architecture and I need support for my work!

Thank you.

[ColoradoMarmot]

There will never be support for x86 guests.  It's simply not an option - no virtualization engine will build emulation capability at the OS level.

If you need Intel guests, you'll need an intel host.

[jldement]

Just to be clear because I am not sure I understand the response (or perhaps I did not state my situation correctly).

I ran my virtual machines on Fusion on previous generations of Macbook Pro without issue.  They are different flavors of UNIX.  Is your "never" statement because of the new M1 Pro chip set on the latest Macbook Pro?

[gringley]

Correct.  M1 is ARM not Intel.  Just as you could never run a PowerPC operating system on an Intel Mac, you cannot run an Intel operating system on a M1 (ARM) Mac.  Apple over the years has provided "Rosetta" but that only works for standard applications that follow the "rules" not virtualization software that works at a much lower level.  Note too Rosetta goes away after the transition is considered complete.

[ColoradoMarmot]

Just like you can't run a diesel car on gasoline, you can't run an intel operating system on an ARM chip.

You'll have to build new guests using ARM based operating systems in order to have them run on an M1 machine.  But there are Linux flavors that are.  To run intel applications inside a guest, you'll have something in the guest that emulates intel.  Windows 11 ARM has that, but it's not supported.  For Linux, you'd need something like QEMU.

[TheWaterbug]

I just wasted a few hours trying to install Big Sur on the Tech Preview running on an M1 Mini 🙄.

If this doesn't work yet, please consider disabling the drag-and-drop of the Big Sur installer app into the easy setup dialog box, or at least popping up an error before going through all the "preparing media" steps, etc.

[viking1304]

---

@TheWaterbug wrote:

I just wasted a few hours trying to install Big Sur on the Tech Preview running on an M1 Mini 🙄.

If this doesn't work yet, please consider disabling the drag-and-drop of the Big Sur installer app into the easy setup dialog box, or at least popping up an error before going through all the "preparing media" steps, etc.

---

Even when macOS support finally came, it will probably support only Monterey and newer versions of macOS, since ARM virtualization API only exists on Monterey. We might be able to install Big Sur as guest (even this is also questionable), but we will not be able to use it as a host.

The number of questions like this one indicates that people are not aware what they actually buying when they purchase Macs with M1.

[Stubb]

Only supporting Monterey (or later) guests on Monterey (or later) hosts seems perfectly reasonable. That's the configuration Parallels supports at present.

[Technogeezer]

---

@Stubb wrote:

Only supporting Monterey (or later) guests on Monterey (or later) hosts seems perfectly reasonable. 

---

You haven't been reading a lot of the posts in the Fusion forums, have you? 😁

There are a lot of expectations for what Fusion "should be able to do" ("I expect to be able to run old macOS versions or my existing Windows VMs on my new M1 Mac because it's a Mac  and I did it before buying the new one") that end up disappointing/enraging people when they find out what can actually be done.

[TheWaterbug]

I think you're mis-reading Stubbs's post. S/he's saying that _restricting_ macOS guest support to Monterey or later on Monterey or later is a reasonable expectation, and that _not_ expecting support for earlier OSes is also reasonable. Further to Stubbs's point, Parallels is currently supporting Monterey on Monterey.

[Stubb]

My M1 Mac just came in, and as a long-time Fusion user I browsed the forums and did some reading to check the state of virtualization on such machines this morning. Some of the requests, perhaps unknown to the posters, were asking for Fusion to become like QEMU and translate x86->ARM along with emulating fancy hardware. I felt compelled to add a perhaps more reasonable request 😉. I'm seeing that Linux as a guest OS is already supported in the public beta 👍.

Apple shares proof-of-concept code to virtualize Monterey on Monterey. Things like pause/resume, drag-and-drop between desktops, and other features users have come to expect aren't supported, but seeing that the core virtualization functionality is now baked into the OS seems grounds for optimism, although this is a different architectural approach as @Mikero says in his post. 

M1 MacBook Pros are beasts. Being able to create per-project VMs would be super useful.

[Technogeezer]

@Stubb @TheWaterbug  - my post was not meant to say that the expectation wes unreasonable. In fact I’m in agreement that it’s a reasonable expectation given how virtualization works, the architectural differences between Intel and Apple Silicon, and the direction that Apple has taken with its API set.  

My comment was meant to say that there are people out there who think that’s not reasonable and that they should be able to run any old version of macOS and Windows on their brand new Mac simply because they’ve been used to doing it. Unfortunately that’s an unrealistic expectation by a lot of new Mac purchasers because they don’t understand about the differences in CPU chip and the fallout of Apple’s decisions.

VMware does have some tough choices to make with Apple Silicon. The Mac has now become an even more different platform than  the other platforms in the product portfolio (ESX, Windows and Linux).

Parallels doesn’t have to deal with that corporate product complexity. It is a bit disappointing as a long time Fusion customer to see Parallels partner with Apple on a demonstration of ARM virtualization while VMware was silent. Maybe the divestiture from Dell will remove some roadblocks to VMware’s forward looking plans. 🤞

[brad-x]

Hey @Mikero I was wondering about mention you made about the Apple hypervisor - is that a requirement Apple has stipulated for macOS guests on Apple Silicon? 

[Mikero]

Pretty much.

So they have this new API I mentioned, but they also don't do their OS images the same way. Basically the aarch64 installation medium is locked now, right from the boot loader, so we can't use the same process we have for Intel macOS guests. Apple considers the interface to make macOS boot quite proprietary.

[Technogeezer]

im not a Fusion product manager but reading the tea leaves I would say that it is  

Apple has deprecated the use of kernel extensions and will eliminate them in a future macOS release .That’s why Fusion does not use their kext based hypervisor in Big Sur and Monterey. 

It makes a lot of sense that if Apple was building virtualization capabilities for their operating system, they’d build it with APIs in their Virtualization Framework in mind, not a kext based implementation. Any hooks that they’d put into macOS to make it more easily virtualized would come out of that work  

Does it make sense for VMware to continue to invest in development and testing on a technology that Apple has said they will  soon cast aside?

And last but not least, Apple Silicon won’t run versions of macOS before Big Sur and Intel Macs are on their way out. And we also know that Apple is all about moving in a forward trajectory, 

[Technogeezer]

@Mikero funny you should mention the macOS boot process. I recently read a series of articles by Howard Oakley over at eclecticlight.co that exposes the differences in Apple Silicon booting vs. Intel. The most intriguing thing if I understand  it is the lack of a “traditional” UEFI boot and the whole idea of validating the sealed system volume. Which is very very different than what we see on Intel systems, and as you say very unique to macOS and Apple. 
To me this also means an uphill battle for anyone that thinks they’re going to be able to dual boot a non-Apple operating system on Apple Silicon Macs. 

[juldrig]

I just want to add that it takes a spectacular lack of consideration for users on the part of a software manufacturer to create an app package delivered on a disk image that can't possibly be run from the disk image volume, and include a graphic image that is displayed in the main window of the disk image volume containing the words "Double-click to install".

[ColoradoMarmot]

Not sure what the issue is.  You double click it to install the package on the system.  Just works.