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.
Any updates as to how we can mute individual VSphere Health alarms ? For example like this one where we have accepted the risk.
Also interested in the answer
I have several admins who are also interested in how to suppress the alert if they are willing to accept the risk.
Just log a case with your hardware vendor HP, for this alert. They must have some upgrades like BIOS/Firmware for this. Mostly Both Vendors (Vmwar/HP) will ask you to upgrade to latest whether patches or firmware upgrades.
You will definitely get solution from them only. First try with HPE.
these are the warning as to new esxi 6.7 they introduce second scheduler option to mitigate these CPU Venerability. go through these to understand the risk behind it.
https://kb.vmware.com/s/article/55806 - talks what is L1 Terminal Fault
https://kb.vmware.com/s/article/55767- talk about performance impact .. like CPU hypertreading will impacted and can be impact 30% less performance and you can't commit more vcpu to vm.
https://kb.vmware.com/s/article/56931- talks about the assessment tools to check what will be the impact on your environment if you mitigate this and use 2nd scheduler.
its your choice as per your environment to just ignore this warranting or implement the change and compromise with 30% perfomance on your enviorment.
I am interested to the answer too: the main reason is that if you have a yellow alert that you cannot mask (and I was told by support you can only disable all the group), this can mask other issues that you wand to be immediately aware of (i.e. disk running out of space).