VCF precheck "Inventory Consistency Check" fails.
search cancel

VCF precheck "Inventory Consistency Check" fails.

book

Article ID: 312133

calendar_today

Updated On:

Products

VMware Cloud Foundation

Issue/Introduction

This article will provide manual workaround to verify if the check actually passes or whether there really is an unknown host to SDDC Manager.


Symptoms:

When running VCF prechecks on an environment which has ESXi hosts with mixed-case FQDNs, Inventory consistency check will fail, stating: "Missing host ... from the SDDC Manager inventory". The following remediation action is shown in the SDDC Manager precheck results for this check: "Investigate why the SDDC Manager inventory does not have records for host ...".
The messages are also visible in the operationsmanager log file located at: /var/log/vmware/vcf/operationsmanager/operationsmanager.log.


Environment

VMware Cloud Foundation 5.0
VMware Cloud foundation 5.x
Vmware Cloud Foundation 5.1

Cause

The cause of the issue is due to a strict matching condition that verifies that the ESXi hostnames are present in the SDDC Manager inventory, and this check is case-sensitive. So if the actual ESXi hostname contains upper-case letters, the check will report failure.

Resolution

VMware is aware of this issue and working to resolve this in a future release.


Workaround:

Ensure that the ESXi hostname is actually present (even though it has a different casing) in the SDDC Manager inventory. To see the ESXi hostnames that are known to SDDC Manager, run the following command from the SDDC Manager SSH terminal:
curl localhost/inventory/hosts | jq | grep hostName

Check to see if the ESXi host listed in the error message is a part of this list (although with different casing).

There are two other prechecks that have been skipped due to the missing host from inventory error. These need to be performed manually on the ESXI host.

Check 1:
Description: Verify legacy boot mode is not being used on the ESXi host

Steps:

  1. Enable SSH on the ESXi host with mixed-case FQDN
  2. SSH to it and run: vsish -e cat /hardware/firmwareType
  3. If the output contains Legacy BIOS then please refer to KB article https://kb.vmware.com/s/article/84233 for more details if transition to UEFI should be performed.

  4. If the output does not contain Legacy BIOS then the check is considered successful and the ESXi has correct boot mode.

Check 2:
Description: Verify bootbank and symlinks

Steps:

  1. If the environment is VxRail do not run the command below, but skip directly to step 5).

  2. SSH to the ESXi host and run: find -L / -maxdepth 1 -user root -type l

  3. If the command output contains any of the lines, then go to step 4) otherwise skip to step 5):

    /bootbank
    /altbootbank

  4. Remediation: Please check
                                                                                                 
    4.1) If directory /scratch/downloads exists on host. Note that the /scratch is the link to the configured scratch partition. Please refer to kb article: https://kb.vmware.com/s/article/1033696

    4.2) If directory /locker on host has enough space needed during upgrade process and/or is not corrupted by a prior task, if vsan traces have consumed the /locker directory space. Please refer to kb article: https://kb.vmware.com/s/article/2030665

    4.3) Check if directory /locker on host i.e., the SDDC VM NFS mount directory is reachable and if not restart NFS service on SDDC Manager VM if required using 'systemctl restart nfs-server'.

    4.4) Check if the symlink for /bootbank and /altbootbank are linked to correct folders and that the actual folders exist.

  5. Disable SSH on the ESXi.