How to be sure that all the vCPU are detected on a specific ESXi.

[hpoirier8]

hi,

We had an issue on a blade where the MultiThreading is not detected . I explain:
We had a specific Blade for which the Multithreading is not detected in VMware . the Motherboard has 2 CPUs with 4 cores each, it means 8CPUs, and with the MultiThreading, normally, we should have 16vCPUs.The multiThreading is correctly activated in the Blade BIOS, so it should be recognized. but at the moment, in the vCenter, we can see only 8vCPUs !!!  .
We suspected that the blade had some issues, so we decided to replace it .
After replacing the Blade (same type, same processors type), we still have 8vCPUs.

The question is :  do we have something to do to refresh the information stored in the vCenter, like a  "rescan" or something like  ?
Is there something to do like unregister // register again the Blade /ESXi?

Or maybe something to do at the ESXi level ?

VMware vSphere 6.0 is our current version.

Thanks for your update.
Any help would be greatly appreciated.
Thanks
hubert

[IRIX201110141]

Hm....  reasons for not seeing what you expect.

1. The Intel(R) Xeon(R) CPU E5-2609 v2 for example doesnt support HT
2. You have enable the adv. Setting VMkernel.Boot.hyperthreadingMitigation which disable HT because of security issues (Spectre/Meltdown)

Regards,
Joerg

[hpoirier8]

Hi,

Thanks for your reply.

the processor type we have support the multithreading : Intel(R) Xeon(R) CPU E5-2637 v3 @ 3.50GHz

However, there is something strange I noticed, as in the Blade Enclosure, we have 10 blades with the same processor, same configuration as the one which shows only 8vCPUs.
When I check the adv Parameters, only the one with 8vCPUs has this parameter (VMkernel.Boot.hyperthreadingMitigation) defined, all the others dont have this parameter. This parameter was set to TRUE, I set it to False but it is still the same . only 8vCPUs available.

any ideas ?

Thanks beforehand for your help.

hubert

[IRIX201110141]

The E5-2637 is one with HT.  Do you reboot the host after modify the parameter? Whats the value after the reboot? Did you check the docs how the mitigation works on your old ESX 6 version? Maybe its another parameter but for it goes into the right direction because disable HT on Hypervisor level was VMware favorite way to deal with the problem.

Regards,
Joerg

[vbondzio]

Just a few notes. In ESXi terminology, a vCPU is something that is scheduled, i.e. your VMs have vCPUs that are scheduled on PCPUs. Whether SMT/HT is available or not, the top most thing vCPUs (and other worlds) execute on are called PCPU. You just have two PCPUs "in front" of a core with SMT/HT.

The following command should show you everything you need to know (you might see less information on a 6.0 host):

[root@host:~] vsish -e get /hardware/cpu/cpuInfo
CPU global information {
Hyperthreading state: 3 -> enabled
HV state: 3 -> HV Enabled
Number of packages:2
Number of dies:2
Number of tiles:2
Number of modules:2
Number of cores:12
Number of CPUs (threads):24
Number of licensable cores:12
SLC64 capable:0
NVOA:0
Hyperthreading security vulnerability mitigated:0
} 

And yes, the only way to remediate L1TF in software on anything before 6.7 U2 (which introduced the SCAv2) was to effectively disable HT, the reason why a new setting was introduced (instead of recommending to use the old disable HT option / to disable it in the BIOS) was so that ESXi is aware the the reason HT is off is meant only to mitigate L1TF and not e.g. for licensing / performance reasons. Enabling / disabling requires a host reboot.

You can read more about SCAv1/v2 here: https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/performance/scheduler-op...