Home > Blogs > VMware Fusion Blog

Fusion on Apple Silicon: Progress Update

It’s been a few months since our informal announcement via Twitter back in November where we committed to delivering VMware VMs on Apple silicon devices, so we wanted to take this opportunity to share a bit about how our progress with our little project to bring Fusion to life on Apple silicon Macs this year.

The quick read

Before we get right into it, I just want to summarize our position way up front with a quick tl;dr:

  • We will be delivering a Tech Preview of VMware Fusion for macOS on Apple silicon this year.
  • Development is moving along very well, meeting or exceeding our expectations, but there are challenges and much work still to do
  • We don’t plan to support installing or running x86 VMs on Macs with Apple silicon.
  • Windows is second priority behind Linux
    • Microsoft currently does not sell licenses of Windows 10 ARM for virtual machines.
    • Insider builds of Windows 10 ARM may only be installed on systems with a licensed version of Windows 10, which is currently not available on Apple hardware.
  • macOS VMs are not in scope in the short term. There are challenges there which will require Apple to work with us to resolve.

A new generation of Macs

With the introduction of Apple silicon, it was revealed that the new CPU line would be based on the same Arm CPU architecture found in an iPhone or on an iPad as opposed to the x86 or x86_64 Intel (or AMD) architectures found on desktops and notebooks. With the new architecture comes incredible performance gains, thermal improvements, and dramatically improved battery life, but poses some unique challenges for virtualization apps like Fusion Pro and Player.

With first generation of Apple silicon chips, namely the M1, Apple has made significant performance and efficacy improvements, with claims of “Up to 2.8x CPU performance; Up to 5x the graphics speed; Up to 11x faster machine learning; And up to 20 hours of battery life” on a new 13” MacBook Pro.

Seeing improvements like that, it comes as no surprise to us that when users got their hands on M1 devices they naturally wanted to run virtual machines on them! Why not take advantage of that extra CPU power and carry around a single notebook instead of 2 laptops, right? We agree.

In much the same way they did when moving from PowerPC to Intel CPUs back in 2006, Apple introduced a new version of Rosetta to support running Intel apps on Apple silicon. For the most part, apps ‘just work’, even if they’re a bit slower.

However, for those that need to run another operating system like Linux or Windows, Rosetta 2 doesn’t support Virtualization, and Apple silicon Macs don’t support Boot Camp. That means it’s time for us to innovate and rebuild our beloved desktop hypervisor for Macs, VMware Fusion, to support the next generation of Apple hardware.

Fusion’s roots

With the 2006 transition, a tiny (but incredible!) team of engineers at VMware saw an opportunity. As a side project, this small group were able to essentially rebuild Workstation to run on the Mac using Apple’s UI, thus creating the foundation of what we now know as VMware Fusion

One of the benefits our users appreciate of having older “enterprise-grade” siblings with Workstation on the desktop and ESXi in the data center is that it gives organizations a consistent operating model. A VMware VM behaves pretty much the same regardless of what product it’s running on. Developers and Operations teams can move VMs and templates between data centers, desktops, and clouds with ease. This is super important to us and to our customers, particularly as more and more operational workflows become automated.

For those who might not have studied the history of VMware, the hypervisor stack in Fusion shares much of the same code as the stack that runs in the majority of the world’s data centers: ESXi, which itself was created from breaking apart the internals of VMware Workstation into it’s functionally discrete components: Storage, Networking and Compute.

Some context

Now, we’re no stranger to Arm CPUs, having shipped what is currently a something we call a Fling with ESXi Arm Edition. Delivering ESXi for Arm has been a multi-year effort, and yet it’s still not quite a Product like ESXi on x86 currently is.

So when we learned about the M1 devices, we knew we had the in-house expertise on both the Arm team, and also on the Fusion bench, to set in motion a plan to re-invent our Mac desktop hypervisor to support this incredible new platform. Being able to build on top of what we’ve learned with our still-evolving Fling has been crucial, and thankfully we have some overlap in the teams’ history, meaning folks have exactly the right experience needed for this project. 

To support Fusion on M1 devices, while maintaining code and feature compatibility with our ecosystem, we are essentially bringing the core of these two projects together.  This is a much different task that simply shipping a single product like Fusion to say the least!

So, how’s it going?

Well, our initial assessments are going very well! For starters, we have VMs booting in a variety of Arm operating systems, and we are very impressed with the performance! 

Because of our kinship with ESXi, we have a major architectural advantage over our competition. ESXi is designed to be enterprise-grade, which includes security, resiliency and performance benefits that both Fusion and Workstation get to benefit from.

Here’s a couple of screenshots from my test desktop, a M1 MacBook Air with 8 CPU + 8GPU cores and 16GB of RAM:

You can see 7 VMs booted in the Library window, with Fedora 34 up front and Ubuntu 21.04 in the Preview window. Still runs 20 degrees (Celsius) cooler than my Intel Mac Mini
Same VMs as above but in separate windows, elegantly viewed with Expose.

You can see here that I have 7 ARM VMs booted at once… 2 are CLI only (Photon and BSD), the others are full desktops… each is configured with 4CPU and 8GB of RAM. 6 different Linux flavors and 1 FreeBSD… MacBook Air. On battery. No fans. Yep. 

Of course, just booting a bunch of VMs that are mostly idle isn’t quite a ‘real world experience’, nor is it the same as doing some of the stress testing that we perform in the leadup to a release.  Even with that said, and note that I’m using ‘debug’ builds which perform slower, in my 12 years at VMware I’ve never seen VMs boot and run like this. So we’re very encouraged by our early results, and seriously can’t wait to get it on every Apple silicon equipped Mac out there.

Sounds good, so what’s the hold up?

While booting all that at once and it being usable (which it all has been in my testing) is an impressive feat in itself, we do still have a ways to go, and some challenges along the way.

For instance, the best Linux VM experience comes by installing VMware Tools, and by and large Tools are included with every Linux distribution. Currently, open-vm-tools are not readily available on the aarch64 (Arm) platform.

Quick refresh, VMware Tools:

  • Is included by default with most Linux distributions
  • Is part of what enables the features that work between host and guest.
  • Improves VM performance
  • Provides a consistent management layer.
  • Delivers graphics drivers and ‘plumbing’ (via open-vm-tools-desktop)

The ESXi-Arm project, in addressing this gap, currently has users build open-vm-tools from source itself. That works just fine for some people, but obviously not everyone is comfortable doing that.

Because open-vm-tools is such a key building block to support the experience we want to deliver for Linux VMs on every platform we support, we’re working with various Linux upstream projects to include the necessary kernel patches to support open-vm-tools and open-vm-tools-desktop on arm64/aarch64 architectures so they can be included in OS distributions. These changes will also benefit the ESXi-Arm Fling by not having to compile Tools from source going forward, so things should ‘just work’ out of the box, as users have come to expect.

So for now, while VMs are booting, we don’t currently have things like 3D hardware accelerated graphics, and other features that require Tools which Fusion users on Intel Macs have come to expect.

That said, even without hardware 3D and while using debug-enabled-builds, we are super impressed with how well things are performing, even against the GA release of our competition.

What about Windows?

Of course, users are expecting to run Windows in a virtual machine, much like we’ve been used to for many years now. With Windows on ARM however, this presents a unique situation, particularly as it relates to Licensing. 

The Insider Preview program says: “To install Windows 10 Insider Preview Builds, you must be running a licensed version of Windows 10 on your device.” And as far as we are aware, there is no way to buy a Windows 10 ARM license for a Mac with Apple silicon. There have been plenty of discussions on the topic from users and the media, and from the Insider Download Page, it reads:

With Windows 10 on ARM Insider Preview builds, you can create 64-bit ARM (ARM64) VMs in Hyper-V on Windows 10 ARM-based PCs. Creating ARM64 VMs is not supported on x64 hardware.

ARM64 VMs are only supported on devices that meet the pre-requisites:

  • Windows 10 ARM-based PCs with a Microsoft SQ1, Microsoft SQ2, Qualcomm Snapdragon 8cx, or Qualcomm Snapdragon 850 processor
  • Windows 10 Pro or Enterprise, build 19559 or newer
  • Hyper-V enabled (instructions)

You can see it doesn’t say anything about Apple silicon. We have reached out to Microsoft for comment and clarification on the matter. 

For the time being, our work has been focused on Linux guest operating systems, and we’re confident that if Microsoft offers Windows on Arm licenses more broadly, we’ll be ready to officially support it.

What about x86 emulation?

We get asked regularly about running x86 VMs on M1 Macs. It makes total sense… If Apple can emulate x86 with Rosetta 2, surely VMware can do something too, right?

Well, the short answer is that there isn’t exactly much business value relative to the engineering effort that is required, at least for the time being. For now, we’re laser focused on making Arm Linux VMs on Apple silicon a delight to use.

So, to be a bit blunt, running x86 operating systems on Apple silicon is not something we are planning to deliver with this project. Installing Windows or Linux from an x86 ISO, for example, will not work.

Why not? Let’s explore:

  • For Windows for Arm, Microsoft has an evolving x86 emulation layer within the OS itself
  • For cloud, OCI multi-arch containers can be built with both Arm and x86 layers in a single image from the same build process.
  • For Linux, there are only a handful of apps that haven’t yet been cross-compiled for Arm
  • There are already great open source tools whose primary function is x86 emulation (i.e. Qemu)

More personally speaking, I really don’t think the next era of Macs will be defined by “switchers” in the same way the previous one was. I expect this platform will be one to more rapidly introduce new experiences at the expense of cutting away from the past. Where we’re headed is anyone’s guess, but I am confident the direction we’re moving isn’t backwards.

That being said, we’re always looking to broaden our horizon with respect to use cases, so if there’s something we’re missing, give us (or me) a shout, we’re eager to hear about it.

When can we get it?

The beta that started it all… now 15 years young!

Ah yes, the burning question: When can everyone get their hands on a tech preview?

We’re working diligently to get VMware VMs on Apple silicon and making great progress as you can see, but we would be remiss if our product did something unexpected or unsafe to any computer it was installed on. Even for a Tech Preview there’s a good deal of QA/QE work still to be done as we continue to add code to bring features online.

We’re the leaders of virtualization in the enterprise with SDDC stacks like VCF because we consistently deliver a high measure of quality, security and performance across all our products. It’s not because we shipped first, it’s because we ship when it’s ready.

That said, the team is planning to deliver a Public Tech Preview of VMware Fusion for macOS on Apple silicon before the end of this year, and we can’t wait to get it in the hands of every Apple silicon Mac owner.

Wrapping Up

If you’ve made it this far, the team and I appreciate it! The world is a bit crazy right now, but there are great things coming. Thanks for your understanding and patience as we take the time to get it right amidst all of the challenges of today.

We really couldn’t be more excited about not only the development progress, but for life with Fusion on Apple silicon. The hardware is incredible, and if our early testing is any indication, users are going to be very happy running VMware virtual machines on the latest Macs of today the future.

Keep an eye out in the VMTN community or follow us on Twitter for our Tech Preview announcement in the coming months!

And please consider donating to the charities above to support our Indian friends and colleagues affected by the global pandemic. <3

May 3 – this blog was updated to reflect that the timeframe to deliver this offering is not currently impacted by the COVID situation. That said, for folks looking to help with the relief efforts in India, please check out the 2021 India COVID-19 Recovery Fund.

35 thoughts on “Fusion on Apple Silicon: Progress Update

  1. Bob Comer

    I really need that x86 emulation and Windows, so there’s just no way I can buy VMWare fusion for my M1 MAC. It probably also means I wont be purchasing any more M1 Macs until I get that emulation.

    1. Mazen

      Thank you, Michael, for the update, although I have to say it’s disappointing. I have to use some highly specialized x86 based software for the industrial controls industry (think Rockwell, Siemens PLCs, etc). If I can’t run VMs on my M1 MacBook Pro, then I will probably go back to using a Lenovo Windows laptop and forego the M1 altogether, which would be a shame. I’ve been a loyal VMware customer for over 10 years, but this is disappointing and I’m going to try the Parallels release that was just announced.

      1. Fabrizio

        Parallels gives you Windows ON ARM which is very VERY different from Windows

        If you are dealing with software for industrial application please evaluate if driver and other stuff can run on Windows ON ARM…

        So VMWARE or Parallels are more or less the same…

  2. Flash Sheridan

    > “into it’s functionally discrete components”

    “it’s” should be “its”.

    > “we’re always looking to broaden our horizon with respect to use cases”

        I agree with Bob Comer about x86 emulation and Windows, and disagree with “there isn’t exactly much business value relative to the engineering effort”. There are decades worth of legacy Windows apps, which is what made Intel Macs so exciting—a truce (now expired) in the Mac vs. PC wars. My use case is Quicken: I’ve looked into MacQuicken since its first OSX beta, and every few years since then; they’ve never seemed serious about data migration integrity.

    1. James

      > There are decades worth of legacy Windows apps

      Would they not run with the x86/x64 emulation provided by Windows 10 for ARM?

      1. Flash Sheridan

        Thanks, I got a CodeWeavers trial license in 2008, but real Quicken performance, even on an Intel Mac, was so slow that it never actually converted my data, which was quite worrying. Data conversion seems a lot easier to simulate on the same processor architecture than, for instance, emulating UI code on ARM.
        (BTW, Hi back at you, Jim, and thanks for the UTM pointer. Likewise to Mazen for Parallels, which I used before I switched to VMware—from what I heard they were a lot more serious about quality.)

  3. Trey F

    I was hoping that VMware being the market leader in virtualization and cloud tech would have been the first to the table with x86/64 emulation for Apple Silicon. Whomever at VMware come to the conclusion “..there isn’t exactly much business value..” for x86/64 emulation should reevaluate that there won’t be not business value for Fusion to exist if it can’t support x86/64 emulation. UTM is only $10 for ARM only VMs, but I would be happy to pay more for x86/64 emulation in addition to ARM on Apple Silicon.

    1. James Bailey

      UTM emulation of x86-64 works on an M1 Mac. It is reasonably usable if you turn on the force multi-threading option. It isn’t clear if that is safe though.

      QEmu 6.0.0 just came out today so I’m looking forward to seeing how well that works. If you aren’t aware, UTM uses QEmu internally for both its hypervisor support and for emulation.

  4. John Hamilton

    One business use case for Dev and Test has been legacy OSs in the past. VMWare Fusion has been on par with VMWare Workstation and ESXi in the past by allowing me to run OSs from DOS6.2 up to Mac OS Catalina. Why does MS licensing even have to enter the discussion when producing a VM. License usage is in the purview of the user not the VM Hypervisor manufacturer. Just produce x86 emulation and you will give people access to a huge library of legacy OSs and software that only runs on legacy OSs. You also skirt the Windows for ARM licensing problems you are simply creating by not having x86 emulation. The business case? LOSS OF MARKET SHARE. If you can’t produce a hypervisor capable of running ALL the popular architectures regardless of the underlying platform, then you become much less useful. It’s funny that you are touting the seamless ability for VMs to be experienced the same on all platforms but at the same time saying that if I move a VM from an x86 hypervisor to an ARM hypervisor that it just won’t be supported. This eliminates one of VMWare’s core concepts of Hardware abstraction that has been a PLATFORM for arguing VMs since the beginning. Again focus on every hypervisor supporting every architecture and VIOLA the licensing become a problem between the user and the OS manufacturer.

  5. Robert

    Thanks for this update!

    I agree with previous comments about x86 support. For me the value of VMs is precisely to be able to look backward and use previous operating systems and programs.
    Even a very slow x86 emulation would be a good start and very valuable.

  6. Thomas Stimper

    > ..already great open source tools…..

    sure, same for the hypervisor itself ….

    >. … there isn’t exactly much business value ….

    One example:
    I am working with an Mac for about 10 years.
    Most of my business depends on VMs running on ESXi,
    which i test on my Mac and my ESXi servers.
    The performance of the M1 Macs is great.
    I need to replace my Mac in the near future and I always try new technologies to see how it can help in business.
    Should i switch back to a x86 Linux Notebook? Perhaps …, or get one of the last Intel Macs…

    Another example:
    Students gets M1 Macs
    In five to ten years they decide which technology should be used in the future.
    If they cannot run an x86 VM with VMware Fusion soon, they possibly will not think about to run anything on ESXi in the future.

    > ..already great open source tools…..

  7. Marcos Barrionuevo

    Thank for this update!

    I think that we need the emulation for x86. In my case, I use home labs based with VMware, and I can’t find a Vcenter for Arm.?? On the other hand, I use vms for openstack in x86, how to leave all your old VMware environments?

    Best regards

  8. Madhawa

    Parallels currently loving it. The performance on their VM on M1 macs is so great. they released the the tech preview months back. comone vmware. you’re getting too late to the party.

    1. T

      Wow, I hadn’t heard of this, I am going to try it out. I became a macOS convert because of VMware and Win10 support. I was pumped to get the new M1 chip too, I bet you can guess how that ended up. The reason I use it is to run excel addons and other weird software that is Win exclusive (some only work on x86 of course) in my workflows so this may be the next step for me. I really appreciate you sharing.

  9. Brian c

    I get the sense VMWare isn’t serious about the Mac market. I’ve been a customer for 12 years. But when I upgraded to macOS 11.3 a Windows VM suddenly started crashing. Rather than pay them $50 for support (that is apparently not included with my license) and hope that a future Fusion release resolves the problem, I downloaded the Parallels trial. So far it’s working great, so I’ll probably just stick with it.

  10. Josh W

    Will the final product still have a “Pro” incarnation that can connect up to ESXi & vCenter servers? That is a mission-critical function for me, so I really hope it doesn’t go away!

  11. mw

    I’m using a few WMWare Windows systems, w10. w7 and even server … I can’t rebuild those with a reasonable effort.

  12. Mazen

    Thank you, Michael, for the update, although I have to say it’s disappointing. I have to use some highly specialized x86 based software for the industrial controls industry (think Rockwell, Siemens PLCs, etc). If I can’t run VMs on my M1 MacBook Pro, then I will probably go back to using a Lenovo Windows laptop and forego the M1 altogether, which would be a shame. I’ve been a loyal VMware customer for over 10 years, but this is disappointing and I’m going to try the Parallels release that was just announced.

  13. Henrik Wivel

    I recently purchased an M1 Macbook Air, and rely heavily on Sparx Enterprise Architect for my daily work, Windows only. I have tried CrossOver Mac from Codeweavers earlier on my 2017 15″ i7 MacBook, and it left a lot to be desired. Tried it again on my M1 Air and it runs so much better here, thar I don’t think I will need a WM in the future.

    I know that CrossOver is a bit of a hit and miss, but I have no issues with Enterprise Architect.

  14. Golden G. Richard III

    This is *really* disappointing and I hope VMWare will change their mind:

    –> We don’t plan to support installing or running x86 VMs on Macs with Apple silicon.

    My entire research infrastructure is currently intertwined with VMWare products and this is a deal-breaker that means I will need to look for an alternative and dump VMware Fusion in the near term.

  15. Rusty Shackleford

    Blaming VMware Fusion for not being able to handle a Windows problem. You jam an entire new processor design into a Mac, Windows itself is on the strugglebus for ARM based CPU’s and this is on VMware? Trust me VMware will support it eventually once MS gets their act together. Besides all I hear is people complaining about Windows on a Mac. Hey why not just buy a Windows computer then? People you know who buy Mac’s use, you know. OS X. VMware has always been good about adapting to new technology and hardware. No one does it better. Someone might have a leg up right now, but in the long term VMware always comes out on top. Fusion for Mac isn’t exactly a large portion of VMware’s revenue so it makes logical sense for them to prioritize projects. If you are so up in arms (pun) about it buy a 2020 MBP with an Intel processor. Problem solved.

  16. yes

    Please release an early VM Fusion / ESXi that can run at least mac VMs on M1 for automation testing.

  17. Jean Pierre


    Is just TOO late.

    I will be convincing my company to move away from VMware and purchasing Parallels for it’s clients as we have a real need and it’s immediate because APPLE is selling the M1 and we are buying them…

    Terribly ill thought out roadmap and plan VMware.

  18. KC

    I don’t understand all the complaining in these comments.

    It’s clear VMware doesn’t care about M1 Macs. They’re the ones that know how many people are actually *paying* for VMware Fusion. If this was an important business decision, they would have made it much earlier. They’re capable of emulating or virtualizing pretty much anything they want – it’s their core business for decades.

    *Apple* decided to make their own custom silicon. What does VMware owe you to build an entire product line to make your workflow perfectly transition over? Go tell Tim Cook that you won’t buy any more Macs because you only really used them to run your non-Apple software in a pretty little package. I’m sure it will really cut into their bottom line.

    If you need x86 that bad, BUY A PC. All these threats of “well, maybe I’ll just switch over to something else” is exactly what you should do. If “performance doesn’t really even matter, as long as I can run DOS” is actually true, you should have no trouble finding x86 hardware that can run all your precious virtual machines.

    1. Anonymous User

      If you need an x86 that bad, BUY A PC?!?” – Sorry, most wintel HW builds are crap, with plastic pieces falling off after 6 months of usage. The SW isn’t much better, with bloatware added OEM as a “feature”. Don’t even get me started with the Lenovo BIOS that phones home to China, and “self-heals” if you make any changes (read: you try to remove their backdoors).

      Oh and the service. Dell used to be good, now they are crap. Thinkpad support has sucked since IBM stepped out of the picture…4 redirects for service, including one to an analog answering machine on my last go around 4 years ago. Never again.

  19. Eric Fortin

    I understand you work on Fusion on M1, But your Parallels is already release their product on M1. Somewhere in 2021 is very large. Personally I will wait a couple of weeks and switch to Parallels if VMWare is not announce a more precise date. It would not be am easy decision because I support VMWare for a log time.

    Hope to have ny Fusion M1 soon

  20. Kreeblah

    I have exactly zero use cases for which a virtualization product that doesn’t support x86/x64 would work for me, since the only thing I need a VM for is for using hardware that has (Intel-based) Windows-only drivers. ARM Windows can’t load those, and they obviously won’t run in WINE, so I don’t really have a lot of options other than getting an Intel-based Windows computer. I’ve kept upgrading my Pro license for a while, but I don’t think it really makes sense to continue doing that if I won’t have any use for it after upgrading from my existing Mac.

  21. Jeremiah

    I can’t believe Apple isn’t more interested in helping you push this to completion faster. As someone who develops and tests enterprise software for macOS, running macOS VMs is a part of our daily life. If I can’t do that with M1 I’m not supporting M1. It’s as simple as that.

  22. Stephen Schumacher

    Super disappointed that VMware is dropping the ball so far with x86 VMs on M1, which unfortunately is a deal-breaker for me for future purchases of Fusion and going all-in on M1s. Among other things, software protection mechanisms such as dongles and machine IDs don’t work in Wine and CrossOver, but work fine in VMs. I’ve preferred VMware solutions for decades, but if it can’t/won’t get it’s act together to port x86 VMs to M1, this will be a huge blow to many users, who will be pushed to investigate other options that will hopefully emerge. Pleaase reconsider this sorrowful abandonment of your Fusion user base.

    1. Steven W.

      Totally agree. No x86 VMs, no future purchases for Fusion for myself and most of my professional colleagues. It’s not just Win support, but other vintage and legacy OS’s that our customers use and require support for.

      I choose VMware because I though they added value over the other VM offerings. Very disappointed.

  23. David Harvey

    So how do I get a refund? I have been running a mac in a windows environment for over 10 years happily using Fusion. Mac died. Upgraded to M1 because Fusion was supported on Big Sur and M1. Restored from Time Machine. VM no boot. Ok cool. I get it. Wait it out for Fusion beta. Now no support for x86 and a year for possibly windows arm? I have no use for this product that I was only able to use for 3 months.

  24. Stefano

    Very disappointing. For my needs (test lab for Windows 10 SAC/LTSC and Windows Server) your product becomes useless on Apple silicon.

    > x86 emulation (…) there isn’t exactly much business value relative to the engineering effort that is required
    So there is much business value in supporting only Arm Linux VMs? Or the engineering effort is very low? But then, why the delay?
    It makes no sense to me…


Leave a Reply

Your email address will not be published. Required fields are marked *