We are running a cluster of ProLiant DL380 Gen10 servers running VMware ESXi, 6.7.0, 10302608.
On each host, we are seeing a warning when browsing to Monitor => Health. The warning is "Concurrent-context attack vector vulnerability in Intel processors". After reading more about it here https://kb.vmware.com/s/article/55806 , there is a paragraph that says:
Note: It may be necessary to acquire additional hardware, or rebalance existing workloads, before enablement of the ESXi Side-Channel-Aware Scheduler. Organizations can choose not to enable the ESXi Side-Channel-Aware Scheduler after performing a risk assessment and accepting the risk posed by the Concurrent-context attack vector. This is NOT RECOMMENDED and VMware cannot make this decision on behalf of an organization.
We have discussed this in our organization, and we wish to accept the risk and not enable this feature. How do we disable the warning from the vCenter web UI? Since we do not consider this warning relevant for us, we would like to reset this warning to green. Right now it is potentially obscuring other, more relevant warnings.
Thank you in advance.
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).
We are in the same boat and need to disable this warning we get on all DL380 G9/G10 servers.
Is there really still no solution around for such a basic request?
I agree with wayne7215 - I can't believe there isn't a way to turn it off, it's noise and impacting our ability to effectively handle events/alerts in our environment. Suggesting it's on HPE to provide a fix is not adequate if we wish to assume the risk we should be able to turn-off the alert.
Why not just enable SCAv2 (if you're on the correct vSphere version)? You really aren't going to notice any difference in performance between having SCAv2 enabled or disabled - and the warning will be gone.
Yes maybe this would be just the quickest solution, but I don't want to take the risk of any performance issue, even the stats show up SCAv2 is better than v1, for a security risk we definitely can swallow and just because VMware is not allowing me to suppress a warning. How they will handle other warnings in the future we as customer would have to fix in their opinion? Do we will get as well notifications on every login for each security patch we have not immediately installed?
In my opinion customers should be allowed to decide which warnings they wanna get and which not, it's so easy.
I thought I had replied to this via email yesterday but it doesn't appear to have worked.
The only way you're going to notice any difference between using full HT and having SCAv2 switched on is if your cluster is severely over utilised in the CPU area, in which case you have more pressing matters to concern yourself with than a warning in vCenter.