Day 2 vIDM operations fail in Aria Suite Lifecycle after applying Patch 3
search cancel

Day 2 vIDM operations fail in Aria Suite Lifecycle after applying Patch 3

book

Article ID: 407459

calendar_today

Updated On:

Products

VCF Operations/Automation (formerly VMware Aria Suite)

Issue/Introduction

IMPORTANT : Do not perform any Day 2 operations on vIDM if only LCM has been patched.

Following the successful installation of vrlcm-8.18.0-PATCH3.patch in the Aria Suite Lifecycle UI, all subsequent Day 2 operations on VMware Identity Manager (vIDM) are failing, despite the patch installation being reported as successful, and any attempts to manage the vIDM instance are resulting in errors

Error Code: LCMVIDM74055
Unable to perform pcp recovery on the host. Check if there exists a primary node in the set-up. Refer to VMware Aria Suite Lifecycle log for additional details and retry.
Unable to recover all the postgres nodes which are marked down. Ensure the nodes are powered on and delegateIp is assigned to primary node.

Environment

VMware Aria Suite Lifecycle 8.18.0 Patch 3

VMware Identity Manager 3.3.7

Cause

The cause of this issue is an incorrect patch installation sequence. Patch 3 for Aria Suite Lifecycle was applied before the corresponding mandatory patch was applied to the vIDM appliance.

The product documentation specifies that the vIDM appliance must be patched first. Applying the Aria Suite Lifecycle patch out of order breaks the operational dependency between the two products, leading to the failure of Day 2 operations.

Resolution

To resolve this issue and restore normal functionality, the patching process must be completed in the correct order. At this stage, do not perform any Day-2 operations from the Aria Suite Lifecycle UI. If such actions (e.g., remediation tasks) were attempted before patching vIDM, they may have caused incorrect cluster configurations on vIDM.

Steps to resolve the issue:

  1. SSH into all of the vIDM nodes and use the cat /usr/local/etc/auto-recovery.sh  command to review the configuration
  2. To verify if a newer version of the auto-recovery.sh script was unintentionally applied (due to Day-2 operations from LCM before vIDM patching):
    • Check the header/banner in /usr/local/etc/auto-recovery.sh  If a banner is present, it indicates the newer version.

    • Additionally, look for camel-case aliases such as enableAutoRecovery, which replace the older format enableautorecovery.

  3. Copy the correct configuration files from a working node to affected node 

    • /usr/local/etc/failover.sh

    • /usr/local/etc/aliases

    • /usr/local/etc/auto-recovery.sh

  4. Set the file permission for the file using the below command 

    chmod 775 /usr/local/etc/failover.sh
    chmod 775 /usr/local/etc/auto-recovery.sh
  5. Restart the NetworkService to re-enable auto-recovery:

    /etc/init.d/NetworkService stop

    /etc/init.d/NetworkService start

    This will repair the cluster. Confirm the vIDM cluster is healthy before continuing.

  6. Proceed to patch your vIDM appliance with the required CSP-97577 patch, following the official instructions for that update.

  7. Ensure Step #3 (Patch Postgres Cluster) under the Mandatory: Install Patch 3 for Aria Suite Lifecycle after vIDM is patched successfully section completes.

  8. Ensure Step #4 (start the OpenSearch service) under the Mandatory: Install Patch 3 for Aria Suite Lifecycle after vIDM is patched successfully section completes.

  9. Run an inventory sync for vIDM to update the latest information in the Aria Suite Lifecycle UI, and verify the health status. After this, Day-2 operations from Aria Suite Lifecycle should work as expected.



Additional Information

For full details on the correct patching procedure, always refer to the official release notes and knowledge base articles for the specific patch version you are installing. In this case, refer to the VMware Aria Suite Lifecycle 8.18 Patch 3 Release Notes and KB 404054.