I am running Big Sur on "unsupported" hardware - a Mac Pro 5,1. With updated graphics and WiFi/BLE it is actually running without patches,
To avoid KEXTs VMware 12 is using some extended instructions like XSAVE under Big Sur. Parallels still allows using it with KEXTs and works fine right now.
Is there a VMX parameter to disable this?
monitor.allowLegacyCPU = "true" does not do it.
Unlikely... on Big Sur it's an entirely new monitor stack.
We would have to load the entire vmx86 kext, and that can't happen on Big Sur.
I'm curious tho, what is the use case behind the request?
The use case?
That's easy, you can not use VMWare Fusion 12 at cMP 5.1 any longer. I have the same problem, it's not possible to open a VM because there is an error message of missing XSAVE support.
sysctl -a | grep machdep.cpu.features
machdep.cpu.features: FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA CMOV PAT PSE36 CLFSH DS ACPI MMX FXSR SSE SSE2 SS HTT TM PBE SSE3 PCLMULQDQ DTES64 MON DSCPL VMX SMX EST TM2 SSSE3 CX16 TPR PDCM SSE4.1 SSE4.2 POPCNT AES PCID
Independently of the guest OS, nothing works. As guest OS it's no problem to start Big Sur with Fusion 12 on Catalina (same machine cMP 4.1 > 5.1, 2x X5680 @3.33GHz).
I'm wondering why Parallels has no problems with this, Big Sur as host starts all old Parallel VMs and also Big Sur as guest OS with the latest version 16. So technically it's possible.
Looks like you're using Big Sur... That Mac Pro isn't supported on macOS 11.x.
On Big Sur, we've completely done away with Kernel Extensions, quite deliberately.
As such, the remaining limitations are due to Apple's hypervisor API implementation. It requires certain hardware features.
I'm surprised it even boots on that Mac, tbh.
I know that the hardware is not supported but this has been the case since Catalina, regardless Fusion worked perfect for me. The point is that Parallels 16 works anyway on Mac Pro 5.1. For me as normal user it's totally irrelevant how they technically implemented it, it works.
I will not buy a new machine only because Fusion is not working any longer on this machine, but Big Sur does. I guess it's time to say good bye after years. What a bummer, Fusion was always the better solution for me because of the interchange with VM Workstation on Windows.
There are a lot of Mac's which are unsupported but still will run Big Sur -> https://forums.macrumors.com/threads/macos-11-big-sur-on-unsupported-macs-thread.2242172/ .
At least an option to handle this would be nice, like haralds asked for.
Apple has deprecated Extensions (KEXTs,) but you can still load them.
It would be great if VMware would allow more experienced users to enable the older HyperVisor it uses on Catalina as Parallels does.
It is a bit of a hassle with "Allow"ing this in preferences and rebooting, but it beats ditching the VMware altogether.
Meanwhile I have switched to Parallels and am slowly converting all my VMs.
you say it is the API from Apple!
If I look at the configuration of a VM in Parallels, you can switch the hypervisor between "Apple" and "Parallels" (see attached screenshot, in German). Default is "Apple", and it works on my Mac Pro 5.1 with 2x X5690 processors.
So it seems to me this is not just a problem of Apples API !?
if I start Parallels 16 and with setting "Apple" as hypervisor, there are no loaded kext's from Parallels in the system information apps (see attached screenshot).
So it looks to me that with the new Apple API it would be still possible to support a cMP5.1 or other older machines.
Can this be true?
We understand your confusion. There are a LOT of people out there still running the 2009-2012 Mac Pro's with "unsupported" OS's. There are various patch tools, including OpenCore, which make installing and using Catalina and Big Sur quite easy. They also enable a lot of the features we've been missing on these older machines. I'm using OpenCore with Catalina on my 2010 Mac Pro, and I can't think of a single macOS feature that doesn't work, including unlocking my Mac with my "Series Zero" Apple Watch.
Most of us perform extensive hardware upgrades, including dual 3.46GHz X5690 Xeon's, upgraded BlueTooth & WiFi, NVMe booting, USB3, AMD GPU's, such as the RX580, to achieve full AVC/HEVC encode/decode acceleration, and even Thunderbolt!
My point is that you're going to lose that share of the market to your competitor due to you only supporting Apple's hypervisor, whereas your competitor gives us the option of using theirs or Apples. I hate to think this is the end of VMware for me, but it is what it is I suppose. Can you confirm the business decision of only using Apple's hypervisor is final?
I'm in the same boat. I upgraded my cMP 5,1 to Big Sur last night. When I tried to fire up VMWare Fusion this afternoon, I received the "The processor does not support XSAVE." I much prefer VMWare over Parallels, but I need to be able to run Windows. Parallels may be getting my money if VMWare can't provide a way forward with this issue.
This may be a limitation of the Apple Hypervisor, if so, it's on apple to change for Fusion - and that also means that even Parallels will be done with Big Sur, since the next OS release will prevent kext's from loading at all.
Hello @dlhotka ,
as I already showed in my screenshot attached above, I have Parallels 16 test version installed and it did not install any kext's, and in the configuration of the VM the hypervisor is "Apple" .I tested a Windows 10 and Ubuntu 20.04 VM and both worked, so for me it seems to be possible to run VM's on a cMP5.1 / Big Sur with the Apple hypervisor ...
Very interesting... So VMware's implementation of the Apple hypervisor does not work due to our CPU's not supporting XSAVE, but Parallel's implementation of the Apple hypervisor is not using XSAVE? How is that possible, VMware? Seems you're doing something different, and it's not Apple's fault after all...
Parallels is not loading any KEXT's. Perhaps it would help if you read up on the difference between a kernel extension and a system extension, and then what Parallels is doing might make more sense. https://developer.apple.com/support/kernel-extensions
Also, here's an explanation from the vendor. https://www.parallels.com/blogs/system-extensions-big-sur/
The bottom line: Parallels is not loading any KEXT's. Parallels hypervisor works in Big Sur. Parallels implementation of APPLE's hypervisor does not throw the error "This processor does not support XSAVE", whereas VMware's implementation of APPLE's hypervisor does. That is the difference we're trying to get to the bottom of in the various Mac Pro forums and groups, before all of us leave VMware and move to Parallels.
My final reply... I gave my money to Parallels, rather than VMware Fusion v12, since BOTH Parallels and Apple's hypervisors work in Big Sur, without VMware's XSAVE requirement. I'm now running Big Sur, but Parallels isn't without issues. Their networking is completely broken, so I'm having to route VM traffic through WiFi, but at least I'm able to run my VM's in Big Sur, and access my NAS. It's been a good, long ride VMware, but I'm afraid the ride is over.
I personally expected more here. VMware's own documentation says this is supposed to work...
VMware Fusion Version Hardware Requirement Software Requirement
So form what I can tell, someone at VMware should be looking into;
A) is the Mac Pro 5,1 with a metal capable GPU supported by Fusion 12.x or not?
B) Why is XSAVE a blocking error to begin with? XSAVE is not a required feature for hypervisors to function.
C) Why is VMware not leading the pack on this issue? Every other hypervisor I have tested running BigSur on works... Why is fusion the only one that fails? If this isn't a BUG with fusion, then it is a bug with apples API and again VMware should be leading that discussion with Apple.
What shouldn't be done is exactly what has been done here... Anyone running BigSur on a Mac Pro 5,1 already knows that it isn't officially supported by Apple. Yes it older hardware. But it does work and work quite well, and there is no technical reason that it shouldn't.
It's either a bug with Fusion or Apples API, or VMware has failed to publish correct official documentation on what the requirements actually are for Fusion 12. In any of these cases VMware needs to be actively driving the resolution here! And for crying out loud this has sat long enough without a resolution.
So update the requirements, and get those refund checks ready... or fix it...