Error: "No route to host" during VMware Identity Broker (VIDB) registration in VCF Operations

Products

• VCF Operations

Issue/Introduction

Following a redeployment or upgrade of the VMware Identity Broker (VIDB), the vidb-service-gateway reports a Ready status, but the associated Virtual IP (VIP) is unreachable. Users may observe the following:

• VIDB deployment tasks are successful and cluster nodes are created in vCenter
• VCF Operations fails to register VIDB as identified by Failed task:
  
  

  Task Details:
Install components: Identity broker

  Subtask:
Install components using SDDC lifecycle service
Severity: Error
Message: Unable to register components with VCF Operations
(with instructions to go to Control Panel > Management Tasks)

  Management Tasks:
Request Type: Configure Component
Request Status Failed

• Log analysis of /storage/log/vcops/log/component-manager-plugin-*.log on the VCF Operations appliance reveals the following error:

  com.vmware.vrealize.lcm.exception.AdapterTaskException: No route to host

• DNS resolution for the VIDB FQDN works correctly, but network traffic does not reach VIDB

Environment

• VCF Operations 9.1.0
• VMware Identity Broker 9.1.0

Cause

The issue is caused by a configuration mismatch in the HelmRelease and a lack of drift detection in the Flux controller:

1. The HelmRelease supplying shared-gateway VIPs contains empty values, preventing the creation of the required Service manifest.
2. Because the HelmRelease is marked as Ready, the controller does not automatically retry the configuration.
3. Without drift detection enabled, the system does not recognize the mismatch between the desired state (manifest) and the live objects (LoadBalancer Service).

Resolution

To resolve this issue, perform a manual re-reconciliation and enable drift detection using the following steps:

Note: Ensure Identity Broker is backed up prior to completing these steps. Contact Broadcom support if you need assistance.
On-Demand Backup of VCF Management Services

1. Login to the Control Plane node via SSH
   
   ssh vmware-system-user@<CONTROL_PLANE_NODE_IP>

2. Elevate to root privileges
   
   sudo -i
   
   (Enter the configured administrative password for vmware-system-user when prompted)
   
   
3. Export the Kubernetes admin config path
   
   export KUBECONFIG=/etc/kubernetes/admin.conf
   
   
4. Verify that you are connected to the correct Control Plane node and that the cluster is healthy
   
   kubectl get nodes

5. Trigger manual re-reconciliation of the shared gateway to repopulate HelmRelease values:

   kubectl annotate <gateway-aggregation> reconcile-trigger="$(date +%s)" --overwrite
   

6. Apply a no-op spec change to the GatewayConfiguration to force the controller to refresh:

   kubectl patch gatewayconfiguration vidb-service-gateway -n vidb-external --type=merge -p '{"spec":{"enable2xxAccessLogs":false}}'
   

7. Restart the Envoy-gateway controller to ensure it processes the updated objects:

   kubectl rollout restart deployment envoy-gateway -n vmsp-platform
   

8. (Optional) Force full reprovisioning by deleting existing objects if the stale configuration persists:

   kubectl delete gateway vmsp-gateway -n vmsp-platform
   

9. Enable drift detection on the HelmRelease and force a final reconciliation:

   kubectl patch <helmrelease-name> --type=merge -p '{"spec":{"driftDetection":{"mode":"enabled"}}}'kubectl annotate <helmrelease-name> reconcile-trigger="$(date +%s)" --overwrite
   

10. Verify the fix by checking the LoadBalancer Service and Gateway objects:

    # Check for the correct external IP
    kubectl get svc -A | grep LoadBalancer
    
    # Verify the Gateway object shows the expected VIP
    kubectl get gateway vmsp-gateway -n vmsp-platform -o wide
    

Additional Information

On-Demand Backup of VCF Management Services