Anyone have any information on this?
I am not entirely sure if this helps, but have tried the option provided in KB 56534 ( option about SuppressHyperthreadWarning)
Thank you for your answer. However, after checking, I can see that UserVars.SuppressHyperthreadWarning is already set to 1 per default on all our hosts. No warnings show up on the host on the summary tab and there are no issues or triggered alarms, but if I go to Host => Monitor => Health, I can see there are warnings displayed from the last health check.
Same warning behavior noticed in my 3 node ESXi 6.7 Update 2 cluster in my home lab. All 3 defaulted to SuppressHyperthreadWarning value of 1, but warning still there.
Keeping an eye on this thread...
I was able to clear the alert by modifying the two Kernel Values below, which was the inverse of how they were.
VMkernel.Boot.hyperthreadingMitigation = True
VMkernel.Boot.hyperthreadingMitigationIntraVM = False
This applies to ESX 6.7 U2 , build 13006603; according to 3b in the linked article, lower versions are not supported for SCAv2.
Based on the below image (from KB Article 55806), this is a balance of performance and security.
Specific Info here: VMware Knowledge Base
Ok, so setting VMkernel.Boot.hyperthreadingMitigation or VMkernel.Boot.hyperthreadingMitigationIntraVM to True would hide the warning. Thank you for the clear explanation.
The original question was if there was a way to hide the warning if you do not wish to enable these mitigations because the vulnerability does not pose a threat to your business. This question is still unanswered.
Sorry if I confused your thread. My assumption is that we won't be able to hide the "less impactful" fix, but still can hide the "more impactful fix". Previously we only had the choice of major impact.
So my best guess is to address the lower impact, not implement the higher impact, and watch the alert go away. But it is just a guess. I'll refrain from future comments.
Oh, no, I'm sorry if I gave the impression your answer wasn't relevant. Your answer provides valuable and easy to understand information about the subject and a kind of "workaround" to the original problem. So I'm very happy you commented! I only meant to explain that the original question on how to hide the notification without any mitigation was still unanswered.