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:
I find that I must create my guest VMs with:
If I don't create my VMs with those pieces, I find that:
(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?
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.
BTW, this issue appears to be resolved in 17.0.2.