A: When identifying issue severity, we first categorize them in terms of impacted infrastructure layer, impacted design quality and overall likelihood and we take several parameters into consideration:
The infrastructure layer impacted by the issue: Compute, Storage, and Network contribute to Higher severity, and VM, Management and vCenter to Lower severity.
The design quality impacted by the issue: Availability and Security contribute to Higher severity and Performance, Recoverability and Manageability contribute to Lower severity.
The overall likelihood and impact: based on the specifics of the known issue and the broadness or specificity of the conditions that may cause it, we estimate the overall likelihood and impact, which influences the overall severity as well.
We use 1, 2, and 3 to determine the final severity level for the specific configuration KB. The overall severity indicates how urgently the particular issue must be addressed to mitigate a bigger risk. Log KBs tend to have an elevated severity because they indicate problems that are already happening and may need to be addressed urgently.
Here are a few examples:
KB2144968 has Critical severity because it impacts the Availability of Compute and is estimated to be likely to happen if the specific configuration is detected. So the potential impact could be big - all VMs on the impacted hosts may fail at any time.
KB52245 is also Critical because it impacts Security of Compute and potentially the security of many VMs on the vulnerable host.
KB1027511 is Medium because it impacts the Performance of individual VMs, which is an important issue to be addressed, but at the same time the service is most likely still available, there is no security threat and the impact is only on some VMs. The issue should be addressed soon but it is not critical.
KB196 is Low because it impacts Manageability of individual VMs - the service is up, there is no security or performance issue and therefore there is no urgency in addressing this minor issue.