• After migrating a VMware Identity Manager (vIDM) cluster to a new datacenter and changing the IP addresses using the official documentation, Aria Suite Lifecycle (LCM) Inventory Sync fails.
• The LCM user interface displays the following error: Error Code: LCMVIDMIMPORT0018
• When retrying the synchronization by manually inputting the new IP address, the task fails again, and the UI reverts the input to the old IP address.
• The /var/log/vrlcm/vmware_vrlcm.log file on the LCM appliance contains the following exception trace:
ERROR vrlcm[####] [pool-3-thread-##] [c.v.v.l.u.SshUtils] -- JSchException encountered
INFO vrlcm[####] [pool-3-thread-##] [c.v.v.l.p.a.s.Task] -- Injecting task failure event. Error Code : 'LCMVIDMIMPORT0018', Retry : 'true', Causing Properties : '{ CAUSE :: hostNameOrIP === vidmSshPassword ######## }'
java.lang.RuntimeException: Cannot execute ssh commands. Exception encountered : java.net.NoRouteToHostException: No route to host (Host unreachable)
• Below the error in the vrlcm.log there will be two "type" listings. "vidm-secondary" and "vidm-primary". Both the old IP addresses and new IP addresses will be listed.
• Basic network connectivity tests (ping, forward/reverse DNS resolution) from LCM to the new vIDM IP addresses succeed, and the sshuser password is confirmed valid and unlocked.
VMware Identity Manager (vIDM) 3.3.x (Clustered)
Aria Suite Lifecycle (LCM) 8.18.0
• During the IP address update procedure, the internal PostgreSQL database failed to overwrite the previous node network configurations. Instead, new rows were appended for the new IP addresses inside the ServiceInstance table, resulting in duplicated cluster records (e.g., 6 total entries for a 3-node cluster).
• When LCM performs an Inventory Sync, it queries the vIDM database to validate the cluster topology. Upon reading the ServiceInstance table, LCM retrieves the stale (old) IP addresses. It then attempts an SSH connection to an unreachable subnet, triggering the java.net.NoRouteToHostException. Subsequently, the LCM database caches this failure state and reverts the UI input to match the old IP it discovered.
Contact Broadcom Support referencing this article (KB 430244) to validate and provide the next steps.
• Executing the Disaster Recovery script referenced in Broadcom KB 377774 does not resolve this specific condition. That script is designed to correct misaligned hostnames in existing records, whereas this specific failure is caused by orphaned rows in the database that must be explicitly dropped.