XSAVE keeps me from running any VM on Mac Pro 5,1

[Direwolf8]

I installed Fusion 12.2.3 on my Macintosh Pro 5,1 running Big Sur 11.2.3.
None of my existing VM's run, and I can't load a new one. I get the following error:

"The processor does not support XSAVE."

My Mac Pro has a Radeon RX 580 GPU installed. According to this article https://kb.vmware.com/s/article/2005196
the combination is supported.

I saw posts indicating that others had this problem over a year old, but haven't found a solution. How can this be fixed?

[bluefirestorm]

For Apple, the last supported macOS for Mac Pro 5,1 is High Sierra.
https://support.apple.com/kb/sp765?locale=en_US

Catalina, Big Sur require Mac Pro 2013 or newer for the Mac Pro line.
https://support.apple.com/kb/SP803?locale=en_US
https://support.apple.com/kb/sp833?locale=en_US

XSAVE is a CPU instruction. Mac Pro 5,1 CPUs (whether Nehalem or Westmere) does not have the XSAVE instruction. XSAVE is available from Intel Sandy Bridge generation of CPUs (the one after Westmere). So if the instruction is not available in the transistor circuitry of the CPU silicon there is nothing that can be done to magically bring it to life. You cannot upgrade to a Sandy Bridge CPU as they have different sockets to the Nehalem/Westmere CPUs.

[Technogeezer]

Also from the Fusion 12.2.3 release notes:

System Requirements

• Hardware

  Intel Mac models that support macOS 11.0 Big Sur and newer versions.

  • Mac models that support macOS 11.0 Big Sur - https://support.apple.com/en-us/HT211238.

Given that Big Sur isn’t listed as supported by Apple on a 2010 Mac Pro (Mac Pro 5,1), I’m assuming you are using OpenCore Legacy Patcher to get Big Sur to run. Just because you can get it to run does not mean it’s supported by Apple or VMware or that the hardware has all the features needed by Fusion. And as @bluefirestorm has noted, the supported Macs for Fusion 12 have a CPU instruction that Fusion needs. 

The solution is to drop back to supported Fusion/macOS versions that run on your hardware. And no, earlier versions of Fusion do not run on Big Sur. 

[Direwolf8]

Since Fusion 12 runs on the Westmere processor, but not with a Westmere running Big Sur, it ought to be possible for

VMWare to modify the kext that they use with 10.X:

https://support.apple.com/en-us/HT211860

macOS Big Sur 11.0 and later allows management of legacy system extensions for both Intel-based Mac computers and Mac computers with Apple silicon.

It doesn't seem like it would be a major development for them to extend the functionality to Big Sur on a Mac 5,1.

[ColoradoMarmot]

If apple doesn't support the OS on that hardware, VMWare will never support Fusion on it.

[Direwolf8]

They already do, don't they? Fusion 12 is supported on the Westmere running 10.X, which uses a kext. It doesn't magically add the hardware function to the processor.

[Technogeezer]

@Direwolf8, no they don't. Fusion 12.0 is supported on Mac models that are supported by Apple that run Catalina or Big Sur. Mac Pro 5,1 are not supported by Apple to run Catalina or Big Sur. The last macOS version that Apple supports for a Mac Pro 5,1 is Mojave.

Apple has also stated that kexts are deprecated technology and support will be removed in a future release. Because of this, VMware made the decision to stop supporting their kext hypervisor in Fusion in favor of integrating with the Apple Hypervisor framework in Big Sur and later. They didn’t want to invest more effort in a dead technology.

My prior comments on hardware support for macOS versions still stand. Not supported by Apple, not supported by Fusion.

Re-introduction of kext support and support for Macs that Apple doesn't support isn’t happening.  Run a supported version of macOS on that hardware (Mojave was the last), and a compatible version of a Fusion for that release (11.5.7 was the last) and it will continue to run with kexts. 

[Direwolf8]

All you've done is rehash the reasons that have already been repeated. I think we already know that Fusion 12 doesn't run on the Mac Pro 5,1 running Big Sur.

Big Sur doesn't support kext files anymore, but does have a new way to add kernel extensions. So Fusion 12 COULD be made to work on that platform.

"VMware made the decision to stop supporting their kext hypervisor in Fusion in favor of integrating with the Apple Hypervisor framework in Big Sur and later. They didn’t want to invest more effort in a dead technology."

So are you privy to the company's internal product development decisions, or are you speculating?  If it's just a matter of supplying a new-style kernel extension. why do you object so much to their doing it?

Buying a new mac as someone suggested isn't a good solution to an otherwise simple-appearing problem. A 12 core Mac Pro with 96 GB RAM, similar to my current configuration, is $ 8000, not counting the cost of updating or getting adapters for firewire peripherals. And it would add 50 pounds of e-waste.

I'm not claiming that VMWare will do this. I just wonder why some of you seem to be so dead set against it that you're making excuses for why it won't work.

[Technogeezer]

We're tilting at windmills here.

We're not making excuses or dead set against anything. We're stating reality.

VMware explicitly states that Fusion supports specific macOS versions and the Mac hardware that Apple supports for those macOS versions. Anything else is unsupported. They're not going back to do anything to make Fusion work on your unsupported hardware/software combination. I'm sorry that's the case but it is what it is. 

I'm not a VMware engineer and I suspect that you aren't either. I'm going on what VMware has said here and in other areas about how/why they have decided to integrate with new macOS operating system versions, and their decision to use the macOS Hypervisor Framework going forward.

As with most things, the situation about kext vs system extensions may not be as simple as it may appear. My suspicion is that system extensions are not a 100% replacement for kernel extensions.  I would also suspect that if it was easy to use system extensions vs. the new Hypervisor Framework that both VMware and Parallels would do it to preserve as much of their existing hypervisor code as possible. But it doesn't appear that either chose that route.

I'm not saying buy a new Mac. You can run that Mac forever on the software that both Apple and VMware say are supported for it. I am saying that vendors make decisions (both Apple and application vendors) about what platform combinations they are going to develop for and support. You may not like those decisions.

And if you're worrying about e-waste, Apple will recycle that Mac for you.  

[Technogeezer]

There's been some timely posts over on The Eclectic Light Company by Howard Oakley (eclecticlight.co) about kernel extensions.

Kernel extensions run as part of the kernel with enhanced privileges and access to the innards of the OS. System extensions run in user space, not at the OS level like kernel extensions. They don't have the same privileges and access as before.

The Apple Hypervisor Framework also lets virtualization code run from user space, and provides APIs to manage low level virtualization functions that now are part of macOS. My theory is that those necessary low level capabilities that hypervisors used to use are not accessible to user space applications without going through the Virtualization APIs. In which case, you can't simply port a hypervisor code 1:1 to the new macOS paradigm. It has to be refactored to support the new APIs because you don't have access to the inner workings of macOS that you had with kexts.

So in essence, VMware is already running with something like system extensions on Big Sur and Monterey. 

.

[ColoradoMarmot]

The issue isn't can it be done, the issue is does apple support that hardware and os stack.  In this case the answer is no.  So expecting a vendor to spend limited time and development resources on support for an unsupported platform leveraging legacy technology (kext) isn't reasonable.  VMWare would be taking on having to troubleshoot the hacks you had to put in place to install the OS itself, as well as their own product.  Not going to happen by any vendor, let alone one who's primary focus is on enterprise-grade software because there is effectively zero revenue associated with it (and a whole lot of cost and risk).

Your choices are to upgrade to a supported platform, or accept the limitations of running legacy OS software versions if you want vendor support.  Choosing to hack the OS and other software to force it to run means choosing to accept all of the potential limitations and issues.

That machine is ~10 years old.  Like it or not, it probably is time to upgrade.

[tombsb]

The current situation is a mess.

After upgrading the Mac Pro, all VMs do no longer work. I cannot migrate them to another platform, because Vmware Tools are installed and subsequently won´t open there. I also cannot uninstalled the tools, because Fusion cannot start up the VMs.

Trying to copy them to another platform with an earlier OS and supported Fusion version does not help either - on the contrary, I have had two situations where the VMs were totally corrupted after trying to launch them (empty VMX file or DUMMY entries).

P.S.: Regarding "use a supported machine" - I have tried on a brand new 2019 Intel Macbook Pro. All VMs which have been working fine on the MP under Mojave prior to moving to Big Sur do not launch there. The Macbook runs Monterey and Fusion 12, still no solution and nobody knows why ...

[Technogeezer]

@tombsb 

I have to assume based on your comments that you're in the same situation as the OP. Running a Mac Pro 5,1 with OCLP to make it run a newer version of macOS that's not supported by Apple. I understand the frustration, but there's really not much more to say if that's the case. VMware versions 12 and later do not support a kernel extension-based hypervisor. They are dependent on what Apple provides in the Hypervisor Framework. Apple decides what Macs they're going to support with a release, then builds the capabilities based on that hardware. In this case, it looks like the Hypervisor Framework was not built with the CPU found in the Mac Pro 5,1 in mind. 

The MacBook Pro situation is a bit more puzzling, though.

I assume that those VMs were shut down (not suspended) before moving them to other hardware?

The "empty VMX or DUMMY" entries are puzzling as well. Were the contents of the VMX files double checked after transfer, and were they configured for a virtual hardware version supported by the older Fusion version?

What happens when you try to launch the VMs you transferred to the MacBook Pro? Error message?

On the MacBook Pro, have you tried the following:

Make sure you're on macOS 12.3.1

Completely uninstall Fusion using the process in https://kb.vmware.com/s/article/1017838 - don't just drag the application to the trash. Make sure you have your Fusion license keys handy because this process deletes the installed keys.

Reboot

Re-install Fusion 12.2.3

[Mikero]

Yah, it is kind of a mess. 

We _could_ work around it if we used our own Kexts, yes.

However, we can't use our own kexts on Big Sur+ due to Apple policy changes, so we have to live with what their hypervisor.framework provides. This is just what we get. 

A similar situation exists with MacBook Pros... after updating to BS or later, nested VMs stopped working because Apple decided that the chips they bought from Intel didn't need vPro, so it's missing a special and important CPU instruction that we use for running Nested VMs (VM in a VM).  We worked around it eventually, but it's painfully slow... So nested is only good on Macs that have Xeons basically. (I can't recall if iMac or Mac Mini also suffered, but my personal Mac Mini is locked to Catalina as a result...).

[Technogeezer]

@Mikero , I think that "can't use our own kexts on Big Sur+" will be met with a reply from people that "Well, Parallels still runs with kexts so why doesn't VMware?".

Isn't it a bit more accurate to say that VMware made the decision to get ahead of the curve and focus development resources on building for Apple's recommended hypervisor framework? And it was done because Apple has said that support for kexts is deprecated and will be removed? I can see why you would make such a decision - why keep investing resources in a dead-end technology.

I sincerely hope that your work with the hypervisor framework APIs is encouraging Apple to improve it where it may be lacking.

The situation with the removal of python 2.7 in macOS 12.3 also shows that Apple can remove deprecated technologies at any point in time without notice..

[tombsb]

@Technogeezer Thank you for your reply.

I absolutely see the point and I can understand if this poses some technical challenges, but there are a few things which bug me, being a long-time Vmware customer and having moved a lot of folks from Parallels to Vmware:

The development of Fusion left a lot to be desired and there has been a lot of talks about "what is going on" in the channel throughout the years. Vmware has sent out many advertisements and surveys, but it obviously was asked too much to keep their Fusion customers up to date regarding this problem.

What I mean is that everyone knows that many pro users are still happy with the performance of their older machines and given that they work nearly flawlessly with the patchers we have, it is a terrible idea to turn them into electronic waste (and it needs to be said how ALL companies say how environmentally conscious they are, just to forget all of this when it suits their needs).

Being a bit familiar with other Mac developers, these guys all know pretty well how many pro users are still using their 2010 Mac Pros. So it is safe to say that the devs at Vmware are aware of the situation too - so why not address this and mention the situation in their many mails? Would have been so easy ...

But like I said, I understand your explanation and would like to thank you very much for your assistance regarding my MBP issue. I will try to see if your suggestions work and hopefully can get back soon on this.

[Technogeezer]

@tombsb - I do understand. Some of that older hardware is still useful, especially those Mac Pros. If Apple had continued to enhance those instead of the ill-conceived 2013 Mac Pro, we might have been better off. A good portion of this mess I blame on Apple. They drop OS support way too soon IMO - if we had published timelines for OS end-of-life and extended security update support, we'd have a lot fewer of these useful machines having to resort to hacks to keep them going.

But there are times that I wish VMware were a bit more forthcoming about what they are doing. They're just as "close to the vest" as Apple is sometimes, and that's not a good thing. They're unnervingly quite about some issues that are bothering a lot of Fusion users (how long does it really take to get a fix for the tech preview because a kernel security patch keeps updated kernels from booting, networking flakiness with the new apple network frameworks, upgrade issues to name only a few).

Keep us posted on that MacBook Pro. I have a funny feeling that in-place updates of both Apple's OS and Fusion don't quite mesh. Especially if you're migrating from macOS earlier than Big Sur to Big Sur or Monterey with a kext-based version of Fusion installed. 

[texter65]

look like I'll use virtual box that works fine no XSAVE issue with that

[boogereater]

So Fusion 13 is out, and they still didn't fix it.

At least Parallels knows how to program, or at least set the compiler options correctly.

Blizzard did the same dumb thing on the latest World of Warcraft release, and had to fix it. It wasn't just 5,1's, it was multiple models.

This is not a Mac problem, it's an Intel problem, and Mac software developers not setting up their compiler correctly. A new version of the compiler came out with an option switched, so it broke a lot of applications on multiple Intel Macs.

It's not just Big Sur. I am running Mac OS 12.6 Monterey.

These 5,1's are more powerful than most of the new Macs, and they are Apple Supported.

I am using the Apple recommended and supported ATI Radeon rx580 Sapphire 8GB Metal GPU and dual x5690's, NVME, and 256GB RAM. Yes, we even have Handoff, the latest WiFi/BT, USB 3, and Thunderbolt. The systems are not outdated. The new Macs simply can't keep up, unless you spend $54k on a new Pro, then talk about software problems...

[Technogeezer]

Suggest you read up on what XSAVE is and why it might be useful to a hypervisor. It was an engineering decision for efficiency, doing in one instruction something that a hypervisor needs to do often which would take multiple instructions to accomplish. It’s not just a “compiler option”.

With the number of customers VMware has for their hypervisor products (likely many times more than Parallels), they might have a pretty good idea on how to code one. 

I’m sorry you’re disappointed that VMware didn’t modify their code to run on Macs that Apple doesn’t support with Big Sur and later. It should not have been a surprise or an expectation given the discussion in this thread and others like it.

if Parallels or Virtual Box run on that configuration, I guess that’s what you’ll have to do.