

running VM within a VM such as WSL2 inside a Windows VM or running docker inside a VM) as it reduces the amount and need for VM entry/exit. The VMCS Shadowing is an Intel CPU feature that is useful for nested virtualisation (i.e. That alone already has some performance penalty although it may not be so obvious. Starting with Big Sur, VMware Fusion VMM makes Apple Hypervisor Framework API calls instead of direct Intel VT-x calls. The Virtual Machine Monitor (VMM) used in Catalina and earlier macOS is a kext (so probably higher priority as well) and makes direct VT-x calls instead of having additional overhead of Apple hypervisor API at user level privilege. So for a 2019 16" MBP, the 2.3GHz i9 has vPro but the 2.6GHz i7 and 2.4GHz i9 does not.Ī possible alternative would be to go back to Catalina and run Fusion 12.1.2 to avoid using the Apple hypervisor framework. The middle one (in terms of price of default configuration) are the ones that has vPro (and thus VMCS shadowing). In a bizarre twist, the 15"/16" MacBook Pro models from 2016 to 2019, the least and most expensive default configuration from the Apple Store does not have vPro. The experimental vTPM with version 12.2.x still has a lot of deficiencies (the encryption password is not known to you, cannot move to a different host, the virtual disk is partially encrypted but it would be pain to remove).Īs for the CPU, The ones with vPro as "Yes" would have VMCS Shadowing. It will be impossible to shrink as punching zeroes using sdelete from the VM would result in non-zeroes being written (as it is suppose to be encrypted). checking the vmware.log for specific entries may tell if VMCS shadowing is available on your Mac if indeed you have allowed nested virtualization in your VM settings.įor encrypted VM with encrypted disk, make sure that the virtual disk is using preallocated otherwise the virtual disk will have runaway growth.

There's nothing you can do about that since VMware's software solution is working around a constraint given to it by Apple's hypervisor framework.Īccording to this article.

Do you have side channel mitigations disabled for the VM? If so, turn it off and see if the situation improves.If so, I can think of one of two things right off the bat (referring to about limitations of nested virtualization) I'm wondering since WSL2 uses Hyper-V components if this is technically considered nested virtualization. Is your virtual machine configured to allow hypervisor applications? Have you considered upgrading to the latest macOS 12.4 and see if the symptoms change? I did notice that you're 3 updates behind on Monterey updates.
