On the topic of VMware Fusion for ARM

[Yebubbleman]

I've been looking carefully over both the Twitter post on VMware's account by Michael Roy of VMware and the comments therein.

He says "So everyone wants to know about Fusion on Apple Silicon macs of the future... What I'd like to ask the community: What do you want to see and why? Knowing that Windows or Linux guests must be ARM only, what would you use it for?"

Most of the people commenting and replying to it seem to either miss the "Knowing that Windows or Linux guests must be ARM only" or are asking from the standpoint of dreaming big and/or acting as though either dreaming big or living in a world where pigs can fly. They say things like "being able to run x86 operating systems". Those that do seem to at least acknowledge the "ARM only" part either talk optimistically of Windows 10 for ARM64 or just say that, without the ability to run x86 operating systems that there's no point.

If VMware Fusion on an ARM Mac could only emulate ARM OSes, I'd personally be happy with the ability to virtualize Apple OSes, any ARM Linux variants out there and Windows 10 for ARM64. But (a) I don't know if that's enough capability for it to sell terribly well, and (b) I don't know if the responses to that Tweet being largely being requests that Roy said can't happen or sentiments of "I have no use for that".

Given all of this, and given that VMware seems to otherwise be readying the next Intel version of Fusion for Intel Macs, what do we think is in store for the future of VMware Fusion on ARM?

Do we think they're going to not support ARM Macs? Or do we think that they'll make something that gets us all of the virtualization that they can?

 

[Janichsan]

...what do we think...?

Do we think...? Or do we think...?

Are we some kind of hive mind?

Anyway, I guess they will probably at least test the water and release an Arm version of their product, even if alone to avoid leaving the market to Parallels, who are already working on an Arm VM.

The question will be if it will actually be worthwhile to release such a VM. A good portion of current customers bought a VM to run Windows Intel applications, in part games. Windows 10 for Arm is not available as stand-alone product, MS has no intention to release it as such, and even so, it's worthless to run games. So why even bother?

Whether system administrators and developers will be enough to provide a sizeable market remains to be seen, especially considering the limitations of not being able to virtualise Intel systems.

 

[Yebubbleman]

Are we some kind of hive mind?

Anyway, I guess they will probably at least test the water and release an Arm version of their product, even if alone to avoid leaving the market to Parallels, who are already working on an Arm VM.

The question will be if it will actually be worthwhile to release such a VM. A good portion of current customers bought a VM to run Windows Intel applications, in part games. Windows 10 for Arm is not available as stand-alone product, MS has no intention to release it as such, and even so, it's worthless to run games. So why even bother?

Whether system administrators and developers will be enough to provide a sizeable market remains to be seen, especially considering the limitations of not being able to virtualise Intel systems.

We (royal "we" now [kidding]) wouldn't rule out Microsoft just yet. I think they'd be foolish to not expand on support and usage of Windows 10 for ARM64 by allowing it on the Mac IN SOME FASHION. Similarly, as was the case last time, I think Apple would be foolish to not at least entertain the idea. Both parties stand to win something here. That and it was a good 10 months after the Intel switch was announced that Apple reversed a similar stance of being able to run Windows on the Intel Macs.

If nothing else, the ability to make even macOS VMs on an ARM Mac (albeit only of ARM based versions of Big Sur or newer) would be really useful! But I don't know if that's enough to entice VMware.

 

[Stephen.R]

VMWare specifically I wouldn't be surprised to see skip/not support Arm. It's very much a small piece of their total pie, and they're otherwise pretty focused on x86. They're also not the quickest to adapt to industry trends. It wasn't long ago that some of their web-based management interfaces required Flash. (They might still require it for all I know).

Parallels is pretty much focused all on Mac now, and they seem to adapting more closely to the Mac specific market - their regular product has the option to use either the Parallels or the Apple supplied hypervisor support, and they have a Mac App Store version which only uses the Apple provided Hypervisor.

I'd imagine this is how/why they were able to demo Parallels on Arm with relative ease: it was probably using the macOS provided hypervisor.

 

[Janichsan]

I'd imagine this is how/why they were able to demo Parallels on Arm with relative ease: it was probably using the macOS provided hypervisor.

Not just probably. This was specifically mentioned.

 

[Stephen.R]

Not just probably. This was specifically mentioned.

I wonder if it means they'll not ship the non-MAS version for Arm. I'd actually prefer MAS (distribution wise - it's much less hassle to setup a new/reinstalled Mac) but AFIK the Intel MAS version is quite light, and doesn't support the features of the Pro version.

 

[chucker23n1]

I wonder if it means they'll not ship the non-MAS version for Arm. I'd actually prefer MAS (distribution wise - it's much less hassle to setup a new/reinstalled Mac) but AFIK the Intel MAS version is quite light, and doesn't support the features of the Pro version.

I don't know what specifically the MAS version of Parallels supports, but Apple's Hypervisor.framework (at least past versions of it) is really just the CPU virtualization. No GPU, no networking pass-through, and so on. So there's quite a few things to build on top of it, some of which may require kernel extensions, network extensions, DriverKit, etc.

The big question, VMware and Parallels aside, is really about Microsoft. Yeah, on paper, you can run Windows on ARM on any ARM machine, but in practice, that seems to be OEM-only so far, and there's quite a few hurdles to overcome, such as:

• the emulation is slow, and often-needed. Even major things like the entire WPF UI framework are x86-only for now. Tons of tooling doesn't yet exist to build an app for ARM, even if you want to. Microsoft is moving to open that up, but slowly.
• the emulation is 32-bit-only. That's kind of another funny footnote in how Microsoft never quite managed to migrate everything to 64-bit. If only someone had invented fat binaries decades ago.
• drivers/specific optimizations. Maybe this doesn't matter as much if Metal is being targeted.

 

[Stephen.R]

The big question, VMware and Parallels aside, is really about Microsoft.

For some, sure.

I personally have zero interest in running Windows.

 

[chucker23n1]

For some, sure.

I personally have zero interest in running Windows.

I guess I don't see the big Linux use case. Wouldn't one typically do that in a Docker container these days?

 

[leman]

I don’t see much point in virtualizing ARM Windows... it doesn’t really offer much useful software. Microsoft API and ABI hygiene is all over the place and their obsession with backwards compatibility populated the Windows ecosystem with overly complex, poorly coded and unmaintainable software.

 

[Stephen.R]

I guess I don't see the big Linux use case. Wouldn't one typically do that in a Docker container these days?

Some people do.

but like all industry buzzwords, it’s not a silver bullet. the arm cpu change is likely to highlight to a number of people how much they’re depending on something they don’t understand.

 

[theluggage]

If VMware Fusion on an ARM Mac could only emulate ARM OSes, I'd personally be happy with the ability to virtualize Apple OSes, any ARM Linux variants out there and Windows 10 for ARM64. But (a) I don't know if that's enough capability for it to sell terribly well

Virtualisation of some form is pretty much a must-have for development these days - its so useful. Even MacOS. ARM Linux is well developed and huge tranches of web development work are completely CPU independent.

Also, if the ARM Mac is even slightly successful it will quickly outnumber the Surface Pro X and other ARM Windows machine, so if MS doesn't abandon ARM windows, they're probably gonna want to see it running on Mac somehow.

I'd imagine this is how/why they were able to demo Parallels on Arm with relative ease: it was probably using the macOS provided hypervisor.

Almost certainly - -

I wonder if it means they'll not ship the non-MAS version for Arm.

I'd guess they'll almost certainly only support the Apple hypervisor... but, as I said above, we'll see what Apple has done to extend what can be done with standard frameworks/within an App store sandbox: they mentioned "new virtualization technologies" and the MacOS hypervisor isn't exactly new.

I don't know what specifically the MAS version of Parallels supports, but Apple's Hypervisor.framework (at least past versions of it) is really just the CPU virtualization. No GPU, no networking pass-through, and so on.

It's only the CPU virtualisation part of the hypervisor that absolutely has to x86 dependent - large chunks of the other code probably just re-compiled for ARM without fuss, especially the MAS version, which pretty much has to work via standard frameworks. It's the sort of thing where changes to frameworks and security models between Catalina and Big Sur are likely to be a bigger deal than ARM vs x86.

The bits missing from the current MAS (https://kb.parallels.com/123796) are pretty much the sort of MacOS/guest OS integration that can't be done from an App Store sandbox. That and, maybe, a bit of product differentiation by Parallels (the non-App-store-version is already a 'lite' version vs. the pro subscription.

What we know is that Apple showed a Linux instance running with a GUI and networking (it served a webpage to the host)... although, given the brief glimpse we got, the GUI could have been running using XQuartz via the network (...in theory Linux's X window system was designed to run from a headless machine with a remote client* doing the rendering - but it doesn't make for a smooth experience with modern graphically rich UIs).

(*Yes, dear pedant, I know...)

I guess I don't see the big Linux use case. Wouldn't one typically do that in a Docker container these days?

Docker containers only run on Linux - the Docker for Mac/Windows packages are basically remote management tools + a virtual Linux machine actually running Docker (originally, a bundled copy of VirtualBox, now it uses Windows or MacOS' built-in hypervisors). Admittedly, it only needs a headless Linux instance, but it still needs Linux.

I don’t see much point in virtualizing ARM Windows...

If nothing else, it will probably be the "least worst" way of running x86 Windows apps under emulation/translation - having ARM Windows emulate/translate x86 app code and catch system calls to handle natively should suck less than software-emulating the entire operating system.

I think the "third way" that people are missing in this thread, and which I suspect someone will offer (and probably do already) is offering a windows x86 instance running "in the cloud" and connecting via Remote Desktop.

 

[chucker23n1]

Also, if the ARM Mac is even slightly successful it will quickly outnumber the Surface Pro X and other ARM Windows machine, so if MS doesn't abandon ARM windows, they're probably gonna want to see it running on Mac somehow.

Yup.

I'd guess they'll almost certainly only support the Apple hypervisor... but, as I said above, we'll see what Apple has done to extend what can be done with standard frameworks/within an App store sandbox: they mentioned "new virtualization technologies" and the MacOS hypervisor isn't exactly new.

Yeah, I imagine they've extended Hypervisor.framework a little.

It's only the CPU virtualisation part of the hypervisor that absolutely has to x86 dependent - large chunks of the other code probably just re-compiled for ARM without fuss, especially the MAS version, which pretty much has to work via standard frameworks.

Yes. But the non-MAS version heavily relies on kernel extensions, and I don't know how much of that functionality can be replicated by newer APIs (such as DriverKit).

And I'm guessing their low-level stuff like networking (bridging, NAT, etc.) has some x86-specific code in it. I could be wrong. But don't be surprised to see early versions of Parallels, etc. to lack some features the x86 version had.

It's the sort of thing where changes to frameworks and security models between Catalina and Big Sur are likely to be a bigger deal than ARM vs x86.

Yep.

If nothing else, it will probably be the "least worst" way of running x86 Windows apps under emulation/translation - having ARM Windows emulate/translate x86 app code and catch system calls to handle natively should suck less than software-emulating the entire operating system.

We'll see!

I think the "third way" that people are missing in this thread, and which I suspect someone will offer (and probably do already) is offering a windows x86 instance running "in the cloud" and connecting via Remote Desktop.

Sure. You can do that with Azure if you want to.

However, there's lots of stuff that isn't great about that. Mac versions of RDP don't even have easy file transfer via copy & paste, much less drag & drop.

 

[Stephen.R]

I think the "third way" that people are missing in this thread, and which I suspect someone will offer (and probably do already) is offering a windows x86 instance running "in the cloud" and connecting via Remote Desktop.

That isn't exactly new - people have been using remote headless servers for various tasks from low-resource machines for a while (the common one admittedly isn't windows, it's a Linux VM to run a dev environment with just the IDE locally). But, it's a big step back for plenty of scenarios. Not saying it doesn't work for some, but it's also not a silver bullet, and I'd be surprised if many had low enough latency network connections to make it usable for anything that's particularly interactive via a GUI.

Docker containers only run on Linux

I can't be sure but I assumed @chucker23n1 meant, "why do you need Parallels to support <Pro Features> for a Linux VM, wouldn't you just use Docker (which provides it's own VM and thus implicitly has all the features required for a dev environment", rather than "why use a VM at all, just use Docker".

 

[chucker23n1]

I can't be sure but I assumed @chucker23n1 meant, "why do you need Parallels to support <Pro Features> for a Linux VM, wouldn't you just use Docker (which provides it's own VM and thus implicitly has all the features required for a dev environment", rather than "why use a VM at all, just use Docker".

Exactly. I don't think there's a lot of people on macOS who want to virtualize a full-blown Linux, especially its UI (be that GNOME, KDE or something else). Rather, they want to run specific apps (almost exclusively command-line ones), and for such use cases, a container is typically enough, and better — more lightweight, and therefore faster to set up and run.

So while running GNOME on ARM (I think it was) in Parallels made for a neat tech demo, I'm not sure there's much of a use case.

 

[Yebubbleman]

Exactly. I don't think there's a lot of people on macOS who want to virtualize a full-blown Linux, especially its UI (be that GNOME, KDE or something else). Rather, they want to run specific apps (almost exclusively command-line ones), and for such use cases, a container is typically enough, and better — more lightweight, and therefore faster to set up and run.

So while running GNOME on ARM (I think it was) in Parallels made for a neat tech demo, I'm not sure there's much of a use case.

It was Debian on ARM. The way they brought attention to their virtualization capabilities in that demo, you'd think that it would be an INCREASE in relative functionality to what we currently have on Intel Macs.

 

[chucker23n1]

It was Debian on ARM.

Right, but I think it showed a GUI. Not sure with which window manager and/or desktop environment.

The way they brought attention to their virtualization capabilities in that demo, you'd think that it would be an INCREASE in relative functionality to what we currently have on Intel Macs.

Well, not really. You can do that on Intel. The point of that demo was to emphasize that Linux on ARM is already a thing (seems to me showing a Raspberry Pi would've been a neat way to show that?), and that they've already spent some effort themselves into making sure stuff works. They made that letter point a bit better with the slide from SOTU(?) that showed various ported FLOSS projects.

 

[Stephen.R]

I don't think there's a lot of people on macOS who want to virtualize a full-blown Linux, especially its UI (be that GNOME, KDE or something else).

I would agree. I think they only used that for the demo, because it's something people can see.

Rather, they want to run specific apps (almost exclusively command-line ones), and for such use cases, a container is typically enough, and better — more lightweight, and therefore faster to set up and run.

There's two aspects for this. If you just want to run "one app", it's going to be no more lightweight to use a container. You still need the Linux VM to host the container. If you want multiple things, then using multiple containers (rather than multiple VMs) is likely to be lighter on resources.

But, as I said, Docker isn't a silver bullet, and despite what some people may think, it's not ubiquitous.

 

[theluggage]

Exactly. I don't think there's a lot of people on macOS who want to virtualize a full-blown Linux, especially its UI (be that GNOME, KDE or something else).

It's a nice facility to have - I've usually got at least one Linux distro installed in Parallels - but it is not a deal breaker. However - there's currently plenty of interest in Linux on ARM anyway but no real desktop ARM hardware for developers, short of the Raspberry Pi - the new ARM Macs would be the obvious choice for that.

This seems like a moot point when Apple have already shown it working... it obviously wasn't hard to achieve and if you can provide "nice to have" without much effort, why not?

The problem with Windows support is that although the demand is a lot greater, it's still a minority interest and the only real solution to that would be for the Mac to stay anchored to x86 until Microsoft finally succeeds in killing off Win32 - which they've been struggling to do for the last 8 years.

But, it's a big step back for plenty of scenarios. Not saying it doesn't work for some, but it's also not a silver bullet, and I'd be surprised if many had low enough latency network connections to make it usable for anything that's particularly interactive via a GUI.

It's worth remembering, though, that it is going to be 3 years or more before anybody is forced to change (...depending a bit on how the transition works out) - if Apple had just axed x86 Macs last week - forcing the change as soon as your Mac breaks down or your company has to kit out a new employee - then I completely agree that it would be a disaster.

Running Windows and x86 Linux was a big selling point for me in 2006 - but between more/better Mac software (even enough games to keep me amused) better web standards and the near-demise of Internet Explorer, more emphasis on web/electron applications, the need to test Windows stuff on touchscreen, cheap pay-for-what-you-use linux instances in the cloud, the performance of cheap PC laptops and SFF systems it's nowhere near as compelling today as it was. If anything stops me buying another Mac it will be the lack of a decent headless desktop that costs less than 5 figures - which an ARM Mac Mini not knobbled by the weakest GPU Intel can provide might solve.

 

[chucker23n1]

stay anchored to x86 until Microsoft finally succeeds in killing off Win32 - which they've been struggling to do for the last 8 years.

Win32 isn't stuck to x86 (it already runs on x86_64 anyway, despite the "32", and much of it runs on ARM).

Many frameworks, however, have yet to be ported. Even stuff like WinForms and WPF, for now.

The Surface Pro X clearly wasn't enough to garner much interest (not a shock, given that it launched in tandem with the Surface Pro 7), but Apple hardware could be.

Running Windows and x86 Linux was a big selling point for me in 2006 - but between more/better Mac software (even enough games to keep me amused) better web standards and the near-demise of Internet Explorer, more emphasis on web/electron applications, the need to test Windows stuff on touchscreen, cheap pay-for-what-you-use linux instances in the cloud, the performance of cheap PC laptops and SFF systems it's nowhere near as compelling today as it was.

Agreed.

Not for everyone, though. I might have to go Windows-only. Or two-computer.

 

[Stephen.R]

It's worth remembering, though, that it is going to be 3 years or more before anybody is forced to change (...depending a bit on how the transition works out)

Oh absolutely.

 

[Tech198]

VMWare specifically I wouldn't be surprised to see skip/not support Arm. It's very much a small piece of their total pie, and they're otherwise pretty focused on x86. They're also not the quickest to adapt to industry trends. It wasn't long ago that some of their web-based management interfaces required Flash. (They might still require it for all I know).

Parallels is pretty much focused all on Mac now, and they seem to adapting more closely to the Mac specific market - their regular product has the option to use either the Parallels or the Apple supplied hypervisor support, and they have a Mac App Store version which only uses the Apple provided Hypervisor.

I'd imagine this is how/why they were able to demo Parallels on Arm with relative ease: it was probably using the macOS provided hypervisor.

CrossOver (from CodeWeavers) generally gets a leg-up in all of this i think.. Aren't they usually the ones who figure stuff out first before the others?

i.e i think they are working on a near metal/WINE port (Vulkan) compatible for x86 architecture, and no one else is. The only reason i can think why they do it because its being paid supported..

Not even sure Crossover can come to the recurse here though with ARM, its probably just seen as a bigger hurdle. I guess wait and see

 

[dogslobber]

A wider question is where people are willing to pay 10 bucks a month to rent VM software from VMWare. Is ARM versions of Linux and Windows worth that amount?

 

[evilzardoz]

I don't need to run ARM VMs. I need to run Intel VMs.

This is because I run Intel applications in VMs under Intel OS's - sometimes legacy OS's, sometimes VMs that I am deploying on Intel hardware. An ARM CPU will not support that.

For me to even consider using an ARM Mac full-time (and this was the enabler that got me to switch to Mac in 2008), is that i need to run applications developed and released in the past. ARM Windows won't help with that as I'm not expecting legacy apps and games for x86 32 and 64bit Windows to be ported to ARM.

I need emulation with VMware emulated hardware i.e. I need to run VMware virtual appliances and my VMware-native VMs on these Macs, or I can't buy them. I would pay a significant amount of money to VMware to make that happen.

 

[Alwis]

That is exactly the point! I have VMs with Windows XP, Windows 7 and Windows 10. I need them for running specific Applications which I can not replace, e.g. configuration software for my KNX bus system, telephone system and other devices. And I need VMs to test my software e.g. on different Windows Versions.

To replace these VMs with a Laptop I would need several Laptop, but I most surly can not find a Laptop with Windows XP. And I would loose the ability to backup VMs before upgrading or testing something.

So the only way for me would be buying a Windows machine and use VMWare on this. But that would be another Laptop cluttering my desk and needing some attention, I just do not want that.

If Apple releases a new Intel iMac this year I will buy that machine, maybe I buy another Intel MacMini to. That will safe me for the next couple of years. After that I hope, that emulation of X86_64 on the ARM Macs is possible.

For my Linux VMs I could probably work with ARM Linux distributions.

I guess I don't see the big Linux use case. Wouldn't one typically do that in a Docker container these days?

Docker is not suitable for every uses case. Beside that, Docker on a Mac still uses a VM under the hood.