With the new release ESXi 8.0 Build 20513097 the tpm activation is shown as warning. This wasn't the case with ESXi7.0U3g - tpm 2.0 activation has been detected flawlessly. The 8.0 installation was on the same machine with preserved vmfs.
On ESXi Host Client, tpm status is declared as "TPM 2.0 device detected but a connection cannot be established.".
On ESXi Shell, tpm is detected but Drtm is shown as false.
localcli hardware trustedboot get
Drtm Enabled: false
Tpm Present: true
/var/log/vmkwarning.log contains some more info about then issue.
2022-10-13T07:39:57.859Z Wa(180) vmkwarning: cpu7:262437)WARNING: tpmDriver: TPMDriverCheckTPM2:56: TPM 2 TIS interface not active.
2022-10-13T07:39:57.859Z Wa(180) vmkwarning: cpu7:262437)WARNING: tpmDriver: TPMDriverAttachDevice:202: \_SB_.TPM_: couldn't validate TPM support: Not supported
2022-10-13T07:39:57.859Z Wa(180) vmkwarning: cpu7:262437)WARNING: Elf: 3156: Kernel based module load of tpmdriver failed: Failure <Mod_LoadDone failed>
2022-10-13T07:39:57.951Z Al(177) vmkalert: cpu5:262408)ALERT: Jumpstart plugin tpm activation failed.
Accordingly to the knowledge base https://kb.vmware.com/s/article/2148536 the issue has been solved in prereleases 6.7/7.0.
There is no indication in the release notes that there is an issue with tpm/drtm, see https://docs.vmware.com/en/VMware-vSphere/8.0/rn/vmware-vsphere-80-release-notes/index.html .
To recreate this, use the following hardware:
Gigabyte X570S Aero G Motherboard or Asus Strix B450-F Motherboard
Both have same issues and both work fine with TPM in VMWare ESXI 7.0.3u.
From the logs, the entry TPM 2 TIS interface not active correlates to the findings of @lamw , see https://williamlam.com/2022/10/quick-tip-tpm-2-0-connection-cannot-be-established-after-upgrading-to.... He mentions that with respect to Intel NUC an older NUC only is compatible to the actual 8.0 (IA) TPM 2 TIS interface status recognition implementation.
For better contribution, please add a device classification e.g.
a) is the device a new model (2022) ? which model and firmware?
b) is the device with its components on the server compatibility list AND it has the tpm issue ?
c) are some components supported ? which ones are not on the list?
d) is the device for homelab purposes only? quantify how many devices
In my case it's d) 1x hpe 250 g8 (latest bios)
from a market companion analyst view, the choice in VMware ecosystem unfortunately has been reduced.
This might be a temporary and wrong view as it isn‘t server business.
Integrating vendor hardware/firmware in virtual hardware version steps - @lamw advertizes the Intel NUC series by strategy. It is more energy saving for developers to focus one vendor product branch. Same e.g. for the vmkusb fling. There is a shortage of skilled workers for such developers.
just thinking loud.
So, if I have read the article correctly, the point of the speech is that the TPM object your system is equipped with, as implemented, does not conform to some necessary specifications, is not supported and consequently not even used.
In order to describe the problem we are discussing here the reference to Intel systems called "NUC" is conceptually irrelevant, he owns those not all possible someone else's. So, getting to the point, what does the article say? Or we live with that warning or we disable the incompatibke TPM object.
Now, let's be practical, products like ESXi do not have the "consumer" market as their reference market but the "business" market with all its own particular needs and that when things don't work as they should it means "losing a pot of money", all the rest (useless) chat. And why on earth would anyone devote time and resources to support non-existent items in the context of their target market?
With respect to development cycles of 12-18 months and facing the goals of Project Keswick, the diversity of edge devices imho is important. TPM releases and implementation flavors shall not become a border.
In 2010 as a system engineer, it was simple to stage Lenovo/Dell/HPE laptops, workstations and small factor devices as ESXi host. Of course, it wasn't supported. The metric of a rich diversity in this area since then is NestedESXi eligibility of devices.
Most AMD Ryzen flavors weren't/aren't officially supported. So far from the field, an increased number of Intel NUCs have the issue with TPM since ESXi8.0.
Yes, the TPM object of my 2022 system is equipped with, as implemented, does not conform to some necessary specifications, is not supported and consequently not even used for non-homelab purposes.
As said, the impression might be totally wrong. Hence, it would be nice to share better feedback with VMware PM. So far, the feedback from the community is somewhat neglectable small.
Especially where this TPM in Ryzen CPUs worked in the previous release, without issues...
Currently working fine in Proxmox as well. I know VMWare is a bit picky about what hardware is supported, but an fTPM built into a CPU, where most OSs require it before they can be installed, should be supported. It shouldn't even be a question to support it, it should just be there, home or enterprise, it doesn't matter.
Good news though, the hardware TPM for my Gigabyte board is scheduled for delivery tomorrow. If that works, it's a good workaround for now (and even a solution), too bad the prices doubled on these with the release of Windows 11...
Well bad news. The TPM 2.0 module showed up today, but VMWare ESXI 8 still cannot utilize it.
- Confirmed FTPM is turned off. Saved BIOS - Rebooted
- BIOS Sees new TPM Module. Enabled for 256 hash.
- VMWare ESXI 8, does not give a warning about the TPM 2.0, however:
localcli hardware trustedboot get
Drtm Enabled: false
Tpm Present: true
I see no other options I can try in VMWare ESXI to pass this through, or enable it or anything.
I started poking around on the BIOS and enabled IOMMU Groups & Secure Boot but it didn't change the outcome.
Maybe others will have better luck.
Reading here and seem to understand that if for yout TPM 2.0 module the "Intel TXT" option is available and active you may need to disable it.
Returning to the argument under discussion, this excerpt from the official documentation should be read:
"Ensure that the TPM is configured in the ESXi host's BIOS to use the SHA-256 hashing algorithm and the TIS / FIFO (First-In, First-Out) interface and not CRB (Command Response Buffer). For information about setting these required BIOS options, refer to the vendor documentation".
Now, IMHO, as this information is disclosed to anyone, it is the manufacturer of a system (the OEM) who should be concerned with implementing things (the TPM module, and not only that) in a manner that conforms to these specifications, admitted he wants his customer to be able to use his product reliably in combination with a very specialized product like ESXi, not the other way around. Otherwise, when things don't work out, the concept of "support" becomes more of a "guesswork", hoping that someone, possibly, will make it (the concept of "best effort").
In my homelab use case the same bios setting works on ESXi 7.0U3g, but gives the warning in ESXi 8.0. In BIOS there are three options: TPM Device (Available), TPM State (Enabled), Clear TPM (no). That's it. That's all. No more option with the latest greated firmware version.
On HPE Gen10 servers there is no issue - you can change TPM bus from FIFO to CRB.
I've seen that some Dell laptops have a tremendous bunch of TPM options e.g. TPM on + Attestation Enable + Key Storage enable + SHA256. On newer Dell servers you can set "Intel TXT" on/off and change the TPM2.0 Algorithm granularly from SHA1 to SHA256.
The matching VMware docs text section in 7.0 and 8.0 hasn't changed.
Neither booting ESXi 7.0U3g nor ESXi8.0, but the alternate boot into Windows 11 says, hey, TPM2.0 works flawlessly. Start tpm.msc and you see TPM is active, e.g. vendor name: INTC, vendor version: 600.7.41.21542, specification version: 2.0.
You start tpmtool.exe getdeviceinformation. The output shows some granular infos e.g. PPI version 1.3 and TPM specification version 1.38.
The latest greatest TPM specification version is 1.59 accordingly to trustedcomputinggroup.org tpm library specification. I haven't found this family 2.0 tpm library specification on esxcli output.
At this point I've given up on it.
With now this issue, and previous issues regarding driver support, I'm back to just using Proxmox. Both TPMs are detected and work flawless in Proxmox 7.2, I also tried Windows 11 this afternoon on this machine bare metal, and it can make use of both TPMs. For giggles I tried ESXi 7.0.3, guess what, no issue detecting and using the external TPM either.
- AMD System: There's no Intel TXT option in BIOS.
- By default, it's set to SHA-256 Hashing and is the TIS interface.
I have no doubt that the Ryzen CPU fTPM and the external TPM 2.0 module both conform to the standards. The most interesting thing is as mentioned, both these TPMs work out of the box in VMWare 7.0.3.
With every release, we seem to get more restricted, moving backwards. I agree that this is really outside of support since we are using unsupported hardware, but this is something very basic that should just work.
Anyways, I'll keep monitoring this thread and probably will try a new release here and there to see what the results are.
Best of luck!