Host incompatible With vLCM desired image during VCF workload domain Creation / Expansion
search cancel

Host incompatible With vLCM desired image during VCF workload domain Creation / Expansion

book

Article ID: 426665

calendar_today

Updated On:

Products

VMware SDDC Manager

Issue/Introduction

During a VMware Cloud Foundation (VCF) workload domain creation, expansion, the SDDC Manager reports a failure such as:

Applying personality to cluster domain-c### failed with error: com.vmware.vapi.std.errors Error. Error(com.vmware.vapi.std.errors.error) => { messages = [LocalizableMessage (com.vmware.vapi.std.localizable_message) => { id = com.vmware.vcIntegrity.lifecycle.RemediateClusterTask.incompatibleHosts, defaultMessage = Cluster '<cluster_name>' remediation failed because hosts '<host_name>, <host_name>, .....' are in 'incompatible' compliance state., args = [<cluster_name>, <host_name>, <host_name>, ....], params = <null>, localized = Cluster '<cluster_name>' remediation failed because hosts '<host_name>, <host_name>, .....' are in 'incompatible' compliance state.}], data = <null>, errorType = ERROR }

This indicates that one or more ESXi hosts do not pass the vSphere Lifecycle Manager (vLCM) compliance check against the cluster’s desired image. As a result, VCF cannot complete the workflow (e.g., host remediation, dmain creation, domain expansion). The underlying symptom is that the hosts’ installed VIBs and image profile do not precisely match the vLCM desired image definition.

Environment

  • VMware Cloud Foundation (VCF) is used.

  • vSphere Lifecycle Manager (vLCM) image-based management is enabled for clusters.

  • ESXi hosts were installed using a vendor OEM-customized ISO

  • The target vLCM image was created from standard ESXi

Cause

The failure occurs because the ESXi hosts and the cluster’s vLCM desired image originate from different source, which leads to a VIB-level mismatch that vLCM cannot reconcile.

This situation typically happens in environments that use OEM-customized ESXi images and later need to upgrade to a newer ESXi version for which an OEM image is not yet available.

A common sequence that leads to this condition is:

  1. Initial deployment

    The ESXi hosts are installed using an OEM-customized ESXi image (for example, from a hardware vendor). This image includes vendor-specific drivers, agents, and add-ons that are not part of the standard ESXi distribution.

  2. Upgrade to a newer ESXi version

    When upgrading to a newer ESXi release (version B), the OEM vendor does not yet provide a customized ISO for that version. As a result, the hosts are upgraded using the standard ESXi ISO instead of an OEM-customized one.

  3. vLCM image configuration constraint

    When configuring the cluster’s desired image in vLCM:
    • The OEM image for the old version (A) cannot be used, because the hosts are already running a newer ESXi version (B).
    • The OEM image for the new version (B) is not available from the vendor.
    • Therefore, the standard ESXi ISO for version B is typically chosen as the desired image, since an OEM-customized image for that version is not available from the vendor.

  4. VIB-level incompatibility
    The standard VMware ESXi image for version B does not contain all of the OEM-specific VIBs that are already installed on the hosts, or it contains older versions of those components.
    As a result, the desired image is missing some VIBs or specifies lower versions than what is installed on the hosts.

Because vLCM enforces an exact VIB-level match between the desired image and each host, it will not allow remediation if applying the image would require downgrading or removing installed VIBs. This causes the hosts to be marked as incompatible with the cluster’s desired image, which in turn blocks VCF workflows such as cluster creation, host remediation, or domain expansion.

Resolution

Step 1 - Identify the incompatible components

  1. Log in to the vSphere Client and navigate to the affected cluster.

  2. Go to Updates > Image.

  3. Click Run Compliance Check (if it has not already been executed).

  4. In the Compliance tab, review the reported mismatches. This will list any VIBs or add-ons that are either:

    • Installed on the host but not present in the desired image, or

    • Present in the desired image at a lower version than what is installed on the host.

These components are the reason the host is reported as incompatible with the desired image.

 

Step 2 - Align the desired image with the hosts

Choose one of the following approaches to resolve the mismatch:

  • Obtain an OEM-customized image
    Request an updated OEM-customized ESXi image from the hardware vendor that includes all required vendor add-ons and driver versions, and use it as the cluster’s desired image.

  • Extract the image from an existing host (recommended when OEM image is unavailable)
    Extract the image from an ESXi host and use it to build a custom vLCM image that includes the same VIBs and versions currently installed on the hosts. Use this extracted image as the cluster’s desired image.

  • Reinstall the host(s) to match the desired image
    Reinstall the ESXi host(s) using the image that will be used as the cluster’s desired image. This approach is disruptive and generally not recommended unless other options are not possible.

  • Remove conflicting VIBs from the host (advanced / risk-based)
    Manually remove VIBs that are not required or are causing the incompatibility, only after carefully validating dependencies and hardware requirements. Removing vendor-specific drivers may lead to loss of hardware functionality and should be treated as a last resort.

Additional Information

Why extracting the host image is often the safest option?

Extracting the image from an existing ESXi host is often the safest and most reliable approach because it preserves the exact set of VIBs, drivers, and vendor add-ons that are already proven to work with the hardware and the current ESXi version.

By building the vLCM desired image from a running host:

  • The desired image matches the hosts at the VIB level, eliminating downgrade or removal conflicts.

  • All OEM-specific drivers and management agents required by the hardware remain intact.

  • The risk of introducing hardware compatibility or stability issues is minimized.

  • No host reinstallation is required, reducing operational impact and downtime.

This approach is especially useful when an OEM-customized image for the target ESXi version is not yet available, but the hosts have already been successfully upgraded and are operating correctly.

Powered by Wolken Software