For some yet unknown reason my Debian 10.6 guest fails to start after upgrading my MacBook Pro (Retina, 15-inch, Mid 2015) from macOS Mojave to Big Sur and upgrading Fusion 11 to Fusion 12.
I know about the 'Enable code profiling applications in this virtual machine' option in the Advanced processor settings, but I actually need this to be enabled to use Intel VTune inside the guest.
But anyway, it was working perfectly before the upgrade so I know that virtualised performance counters in my CPU (Intel(R) Core(TM) i7-4870HQ CPU @ 2.50GHz, Haswell (Crystal Well) as per vmware.log) is supported.
For now it is not clear to me if this is due to the upgrade to Big Sur, the upgrade to Fusion 12, or the combination of both.
Does anyone else have this problem, or is able to reproduce it?
Thanks in advance
With Fusion version 12, the hypervisor went from a kext doing direct CPU VT-x calls to calling the Apple hypervisor API on a Big Sur host as Apple is deprecating the kext model. Make what you will with the hypervisor API, as it is likely slower (with the additional layers of software) than the kext model and it might also be the bridge to the ARM-based Macs.
From that tech preview blog, it looks like Fusion 12 will still use kext if the host is Catalina. So you have to at least go back to Catalina OS to get the VPMC feature back.
Thank you bluefirestorm.
I am a bit sad to read this. I was already moving to a Linux virtual machine for HPC development because the VTune does not support performance data collection in macOS directly. At least with the VMPC enabled I was able to do some PMC analysis through Linux Perf-based performance profiling (because I found no way to get Intel's Sampling Drivers to work within the virtual machine).
But now it looks like I am not even able to do that and I am stuck with user-mode sampling, severely limiting collection types (just hotspot and threading). Or, indeed get stuck on running Fusion 12 on Catalina which is not ideal. Or buy some new hardware for development only and run Linux directly on bare metal. Or maybe use Bootcamp to dual boot Big Sur / Linux on my Macbook (also not ideal).
I hope that virtualised PMCs become available in some future version of Apple's hypervisor API, wether on Intel- or ARM-based Macs.
Alternatively, probably not ideal also, you could run Windows bootcamp (instead of Linux) but use VMware Player for Windows with the VPMC enabled for the Linux VM.
I believe the VPMC is a feature of Intel CPUs. I don't know if the Apple hypervisor API covers the Intel VPMC features; unlikely it does as there are some virtualisation features that were lost from the kext model. And given that Apple has officially started the move away from Intel CPUs to their own design of ARM-based chips, quite unlikely they will be expanding the functionality/feature set in the hypervisor API that are specific to Intel CPUs or plan a replacement inside their own CPU design (and that also means Linux on ARM but there is no Intel VTune for ARM); even if they do the priority won't be high.
Perhaps a plan B would indeed be necessary for the longer term. New hardware would also mean newer CPUs that would have Intel Processor Trace (should be Broadwell or newer). The tricky thing is the PT feature may not be available in all models and not identifiable through the Intel ARK website.
This causes my Windows VM, which was only suspended, to fail startup after upgrading to Big Sur. Since I can only change VM settings if the VM is down (and not suspended), I'm up a certain creek without a paddle.
Is there a way to switch off this feature in a suspended VM?
Not really, but there is a way out. In fact, I had the same problem yesterday. Keep the 'option' key pressed while clicking on the 'Virtual Machine' menu item. You will find that 'Shut Down' has changed into 'Power Off'.
I found the solution: Open the .vmx config file within the VM package and change the parameter vpmc.enable = "TRUE" to vpmc.enable = "FALSE". This will lead to a crash of the VM on unsuspend and the need to run dskchk /f, but at least I got my VM back.
@VMware: This is a serious shortcoming and should be prominently mentioned in the product documentation, as well as to your customer base. It is not uncommon that VMs are simply suspended instead of being powered down before an upgrade.
Yes, that is true. After power off you still need to disable the vpmc option, but at least it kept me from manually modifying the .VMX file.
But it is always nice to have multiple solutions to problems 😉
I agree, that solution seems far from ideal as well. The only alternative I can think of now that won't cost any money and can be done right away is to run Linux bootcamp and use Intel VTune directly without using a virtual machine.
But you are probably right that for the future it would be better to buy a dedicated machine and run it headless with ESXi on it or something.
This is happening to me as well.
I just upgraded to Big Sur, vmware fusion 12. VM of Windows 10.
After making the change to the .vmx file for the xPMC property, I'm now getting a prompt saying:
"Module 'HV' power on failed.
Failed to start the virtual machine"
Update - I had to disable the "Enable hypervision .." option. This finally resulted in being able to start up my vm. This instance really gave me a scare... Thank you for the folks above for the information on the vpmc option!
First you have to locate your VM file (file .vmwarevm) in Finder. Then, right click on the file and choose Show Package Contents.
After that think you can edit with text edit (in my case I used vi under a terminal window) to edit the .vmx file.
Hope it help
Thank you. I found the file but unfortunately for me, there was no reference in the file to vpmc.enabled. It was a long shot for me. I'm not intending to hijack this thread. I am hunting any answer to Operating System Not Found after upgrading to 12.0 on Big Sur.
even if the option is not there, it does not mean that you can't add it. After all, the .vmx file is just a text file. A few versions past, I had the problem that my Ethernet did not work properly with Fusion, and a manual edit, as directed by VMware support, saved the day for me.