Odd behavior with Fusion 12.2 and Windows 11

[MatthiasE]

On a Windows 11 V-machine I'm giving the VM 4 cores. autoVTPM="software", secure boot enabled. MacBook / i7-7700HQ (4C/8T)

These do show up in "device manager": 4 Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz

Taskmanager says: 2 sockets / 2 cores / 2 logical CPUs

In summary only 2 CPUs/cores are used on the host. Windows 10: 4 logical CPUs

Giving the VM 8 cores (ignoring the warning): 4 cores on the host are used (e.g. stress testing the VM and using 100% in VM gives me "400%" out of possible "800%" on the host)

Bug? Feature? Need to double the cores for Win11 VMs?

[wila · Accepted solution]

Hi,

Yes.. smells like a bug. There's been a few reports about Fusion 12.2 and Workstation 16.2 now assigning multiple sockets whereas before it would just use 1 socket.

Btw, 2 sockets and 2 cores --> = 4 cores.

Looks like you can't fix this in the GUI, but you should still be able to fix this in the vmx after you shut down the VM.

numvcpus = "4"
cpuid.coresPerSocket = "4"

(make sure there are no double entries as otherwise Fusion will complain)

--
Wil

[renegade33]

Thanks for the tip. I am also seeing the same issue - I made the edits and the VMX file gets overridden with the default no matter what I do (full shutdown of Fusion and edit, or just VM shutdown and edit). Any thoughts?

Edit: It seems it is due to the encryption - wasn't aware the encrypted key would affect any authenticated VMX config changes, but I suppose that is its point.  

[MatthiasE]

Pay attention: The entry

cpuid.coresPerSocket = "4"

is already present in the VMX file. At least it was for me

I'm back to "normal": Host 4 cores / VM showing 4 cores 

[renegade33]

It's not present in my VMX. As soon as you change anything in the VMX the password to get into the VM is changed and prevents access. 

[wila]

---

@renegade33 wrote:

It's not present in my VMX. As soon as you change anything in the VMX the password to get into the VM is changed and prevents access. 

---

You used the new experimentalmanagedvm.autoVTPM feature?
Yet another problem with it then.

If you want to fix the core issue then you will have to remove the vtpm first (which is easier said than done, see here for details ) before making the manual edit to the vm.

--
Wil

[renegade33]

Thank you, Wil - will do and report back. 

[renegade33]

Ok I removed the TAM and decrypted the VM. At that point I was able to add the line cpuid.coresPerSocket = "4" and boot back up. All is looking good (1 socket, 4 vcpus). Testing with the guest reflects correct usage of the processors in the host - which it didn't with the 2 socket, 2 vcpu representation. 

One note, I did have to reset my pin with Win 11, but it was pretty seamless. 

Thanks for the assistance.