I have a Windows 11 VM on a Mac host running Fusion Pro ver 12.2.4, and I need to enable the nested virtualisation, but after I enabled the check "Enable hypervisor application in this virtual machine", the VM itself becomes very very slow and unstable. If I unselect that check everything is ok,
How can I enable that feature on my Fusion installation? Do I have to upgrade to the version 13?
Any helps is very appreciated. Thanks
As you have posted to the area for a Fusion Tech Preview but are using the commercial release, I have reported your post to the moderators asking them to move it to the regular Fusion area.
From what I understand Apple did not always use CPUs that supported nested virtualization. If you can post your exact Apple model and CPU we can probably confirm this. My recollection on MacBook Pros is that the low end and >high end< CPUs do not support nested virtualization but the mid-range CPU option did.
@gringley your recollection is spot on. The Apple hypervisor framework that Fusion uses implements Nested virtualization using an Intel chip feature called VMCS Shadowing. If the chip does not have this feature, a software implementation in Fusion is used to work around the lack of the hardware feature. That will allow nested virtualization to work on chips that don’t have VMCS shadowing but enacts a performance penalty.
@tmaurizio if you look in the vmware.log file contained in the virtual machine’s bundle, you can easily find the Intel chip in use on your Mac. Use that to see if the model is listed in Intel’s list of vPro CPUs found here: https://www.intel.com/content/www/us/en/products/details/processors/vpro/products.html
VPro processors are the ones that have the VMCS Shadowing feature. If the chip in your Mac isn’t on the Intel list of vPro processors, it doesn’t have the feature.
@Technogeezer Looking in the vmware.log the CPU of my Mac is Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz and it is not listed in the url you provided, and then as you said the nested virtualisation doesn't work. Anyway thanks a lot.
Not saying it doesn’t work. It’s just that VMware says it will run slower on those systems where it has to drop back to software support for nested virtualization.
I think though that some people are finding that the software implementation isn’t very useful (that is, doesn’t perform well enough) for their purposes.
@TechnogeezerIt runs very very slow. It is unusable
Not surprising and not uncommon - unfortunately.
That Intel NUC running ESXi is looking more and more attractive...
This is weird, I have a MacBook Pro with the Intel Core i7-4870HQ CPU @ 2.50GHz, It's not listed on the Intel VPro page linked above, but its specs here:
...say:
@mikesilv wrote:
I've submitted a bug to Apple, using my dev account, to suggest that their hypervisor may not be properly recognizing the capabilities of certain Intel CPUs. Not, that now they probably care much. Perhaps, if you folks at VMWare contact them, they'd care slightly...but probably not much...more.
I wish you luck on that with Apple, but I fear you're going to face an uphill battle. The MacBook Pro running that Intel chip was last supported by Monterey, and Apple isn't putting any effort Into "bug fixes/enhancements" to Monterey other than selective security fixes.
More importantly, the ship is sailing on Intel support from Apple. It's clear that their priorities are on Apple Silicon. Note that they don't support their high-level virtualization framework APIs on anything but Apple Silicon Macs, for example.
Yeah, agreed, thus the smiley and snark about Apple's propensity to 'move on' at the end of my last post. ![]()
But, it took all of 3 minutes to submit the radar/feedback to Apple, and you never get anything if you don't ask! Who knows, maybe I get lucky, they look, and go, 'oops, looks like we defined a whole bunch of CPU's VPro support incorrectly in this structure', and I inadvertently make the experience better for some folks.
And, just from an engineer nerd perspective, I'd be interested to know from a VMWare commenter if my conjecture that this chip *should* support VPro is even correct. It sure seems like it was when Fusion wasn't roped into using Apple's Hypervisor.
Thanks to all for your indulgence of me bumping this 6 month old thread. It is a frustrating state of affairs!
You can confirm by looking at the “Use VMCS Shadowing” in the vmware.log (at least this still shows on version 12.2.5). If it shows {0,1} under the Host VT-x Capabilities section, that means the Intel CPU has that feature.
There would be another “Use VMCS Shadowing” that would show { 0 } under the “Guest VT-x capabilities” section if the “Enable hypervisor” option is enabled in the Processor settings. But this will always be zero as VMCS shadowing does not go beyond the host CPU level and won’t be able available at the virtual CPU of the VM. There has to be real circuitry in the CPU and cannot be made up in a virtual CPU; and that's the whole point why VMCS shadowing makes nested VMs much faster as there is no software overhead and minimises VM-exits.
<timestamp> In(05) vmx Host VT-x Capabilities:
<timestamp> In(05) vmx Use VMCS shadowing {0,1}
<timestamp> In(05) vmx Guest VT-x Capabilities:
<timestamp> In(05) vmx Use VMCS shadowing { 0 }
As for hoping for enhancements/fixes for an unsupported software version, here is my two cents.
Many companies that makes software (especially large ones and it does not get any bigger than Apple in terms of market cap and revenue) just makes it nearly impossible to have unsupported products to have any more enhancements. If a software product goes unsupported that means there is minimal to zero budget allocated (money, people, resources, support web pages no longer updated or completely removed, etc).
So even if some rogue software engineer decides to work on code of unsupported software product, he/she would have a hard time justifying it (assuming the time spent has to be reported in some timesheet/project accounting system; even if there is no accounting or truthful accounting of time spent, there certainly would be logs on source code files being viewed/changed, etc). Plus the code would have to undergo review/signoff and testing and more people will likely have to be involved. Doubtful anyone would want to sacrifice their job/career to work on an unsupported software product version.
