VMware recently released a statement regarding a known vulnerability in the current vCenter Server appliances which could cause remote code execution and authentication flaws Advisory ID: VMSA-2021-0010 and released updates and workarounds to manage this situation.
| Product | Version | Running On | CVE Identifier | CVSSv3 | Severity | Fixed Version | Workarounds | Additional Documentation |
|
vCenter Server
|
7.0
|
Any
|
CVE-2021-21985
|
Critical
|
||||
|
vCenter Server
|
6.7
|
Any
|
CVE-2021-21985
|
Critical
|
||||
|
vCenter Server
|
6.5
|
Any
|
CVE-2021-21985
|
Critical
|
Source: VMware Advisories
Running this update in my test environment from VMware vCenter Server version 7.0 U1d to 7.0 U2b I faced the situation that the HA agents on my hosts failed to start again.
Restarting the “High Availablility” cluster service did not help, neither did restarting the vpxa and hostd service or the hosts itself. Next I checked the fdm.log on the failed hosts using tail -f /var/log/fdm.log and started the HA cluster service again.
This message “Build mismatch (17956805 != 17491166)” repeats multiple times on both failed hosts. So I checked the build version of the fdm VIB on both failed hosts and the host which was running fine and realized that the installed version wasn’t the same.
So I changed the first failed host into maintenance mode and downloaded the fdm VIB from the vCenter server appliance using WinSCP. The needed .vib file was located at
/etc/vmware-vpx/docRoot/vSphere-HA-depot/vib20/vmware-fdm/
I placed this vib on my host storage and checked the output when issuing the command
esxcli software vib install -v /vmfs/volume/MyVol/VMware_bootbank_vmware-fdm_7.0.2-17958471.vib
Realizing that I do have different hardware running in my hosts it may be an old VIB package which is not able to meet the requirements for this installation. Also reviewed the KB 78389.
Using the test environment I forced the installation of the fdm VIB using the command again but with the “force” addition:
esxcli software vib install -v /vmfs/volume/MyVol/VMware_bootbank_vmware-fdm_7.0.2-17958471.vib -f
Restarting the HA cluster service shows that the service is available again, DRS was able to balance the workload evenly and the fdm.log didn’t showed any further mismatch issues.
Note:
I worked on this in a test environment. Please remember that this is not an authorized workaround for production environments and should be treated like that! IP’s and hostnames were changed.
Personal Blog about vAdventures 