VMware Communities
gediam
Contributor
Contributor

Multiple CPUs/Cores in Guests Under Windows 11 on Workstation 17.0.1

I apologize upfront:  I am very confident that this issue has been discussed and that the answer is already out there - but because of the mix of keywords, Google isn't helping much (97% of the results deal with installing Windows 11 in a VM, which isn't what I'm trying to do here).  I thank you in advance for your patience.

Physical Host:

  • 12th-Gen i7 system w/TPM 2.0 and 32GB RAM
  • Secure boot is set to "relaxed" (allow 3rd-party signatures)
  • Windows 11 Pro 22H2

 

I find that I must create my guest VMs with:

  • UEFI
  • encryption (only the files needed to support a TPM)
  • TPM added to the hardware list

 

If I don't create my VMs with those pieces, I find that:

  • I can only add to VMs a single CPU with a single core, or VMs won't boot (i.e., adding multiple CPUs and/or cores leads to unusable VMs).
  • Once VMs are running with a single-core single-CPU, they are highly prone to crashing (i.e., even with a single-core single-CPU, VMs are largely unusable).

(Interestingly, I do not have to enable secure boot.)

I have confirmed the above behavior with guests running Windows 10, CentOS 7, Ubuntu 22.04 LTS, and Oracle Enterprise Linux 8.6; OS doesn't seem to matter.

Is this expected behavior?  If not, how can I work around it?

Reply
0 Kudos
2 Replies
Technogeezer
Immortal
Immortal

I'm thinking your issue might be more related to UEFI vs BIOS firmware and not encryption or TPM. If you're finding that UEFI is in use and disabling Secure Boot doesn't cause the problem to occur, then the use of encryption shouldn't matter either.

If Workstation detects that Hyper-V (or anything that depends on Hyper-V such as memory integrity or virtualization based security), then Hyper-V will be used as the hypervisor (search the vmware.log file of the VM and look for Monitor type: ULM). It's conceivable that the interaction between VMware and Hyper-V is what's causing this to happen. There was another issue with multiple CPU support and use of Hyper-V instead of the VMware hypervisor that reared its ugly head when VMs were updated to later Windows builds - that issue was fixed in 16.2.5 and 17.0. It sounds eerily similar.

If it's the same type of issue, then it is conceivable that VMware did not fix the issue for all possible cases - including if BIOS firmware is in use instead of UEFI.

If you can, I would file a service request with VMware so they get a chance to look at it officially.

It would be interesting as an experiment to disable Hyper-V entirely and force Workstation to use the legacy hypervisor.

Personally for any new virtual machines, I'd never use BIOS unless I absolutely had to. I know that this would create a problem for existing VMs using BIOS of course. 

 

- Paul (Technogeezer)
Editor of the Unofficial Fusion Companion Guides
Reply
0 Kudos
gediam
Contributor
Contributor

BTW, this issue appears to be resolved in 17.0.2.

Reply
0 Kudos