CSP-102547 Patch Upgrade Experience VMware Identity Manager 3.3.7 & Aria Suite Lifecycle 8.18.0 (Patch 5 → 7)

-

In this blog, I would like to share my real-time experience and troubleshooting steps while applying the CSP-102547 patch for:

  • VMware Identity Manager (vIDM): 3.3.7
  • VMware Aria Suite Lifecycle (vRLCM): 8.18.0 (Patch 5 to Patch 7)

This includes the issues encountered during PostgreSQL cluster patching and how they were resolved.

 

Pre-Upgrade Validation

Before starting the upgrade, I performed the necessary pre-check validations:

  • Verified vIDM cluster node health
  • Checked vRLCM status and services
  • Confirmed connectivity and credentials

We followed the official Broadcom KB article: 

 https://knowledge.broadcom.com/external/article/426230

 

Patch Upgrade Status

VMware Identity Manager

  • CSP-102547 patch was applied successfully
  • All vIDM cluster nodes were upgraded without issues

Aria Suite Lifecycle

  • Upgrade from Patch 5 to Patch 7 completed successfully

 

Issue During PostgreSQL Cluster Patch

The issue occurred during the PostgreSQL cluster patching step in vRLCM.

Problem:

  • vRLCM failed at Step 10 of the KB
  • Error while enabling Auto Recovery

“LCM failed on enabling the auto recovery”

 

Troubleshooting Steps

I performed multiple validations and troubleshooting steps:

1. Basic Validation

  • Triggered vIDM Inventory Sync
  • Verified admin and configuration passwords
  • Checked version consistency across nodes:
    • vIDM: 3.3.7 (25163938)
    • PostgreSQL: v14
    • vRLCM: 8.18.0 Patch 7

 

2. Cluster & UI Validation

  • Verified vIDM pool nodes status

  • Confirmed vIDM UI accessibility
  • Checked overall cluster health

 

3. OpenSearch Issue

Observed that:

  • OpenSearch status was showing “Unknown” for all nodes

After restarting OpenSearch, encountered permission errors:

ERROR Could not define attribute view on path

"/opt/vmware/opensearch/logs/horizon_deprecation.json"

access denied ("java.lang.RuntimePermission" "lookupUserInformation")

Resolution Attempt:

Followed KB:

 https://knowledge.broadcom.com/external/article/419056

  • Fixed log directory ownership and permissions
  • Restarted OpenSearch service

 

4. Auto Recovery Troubleshooting

  • Checked auto recovery logs → No clear errors
  • Attempted to:
    • Enable auto recovery
    • Disable auto recovery
  • vRLCM UI showed auto recovery enabled, but behavior was inconsistent

Final Resolution

To resolve the issue, I performed the following steps:

Step 1: Fresh Patch Request

  • Initiated a new request for “Patch PostgreSQL Cluster”

Step 2: Control Auto Recovery via LCM

  • Set Skip = true
  • Disabled auto recovery initially

Step 3: Enable Auto Recovery Separately

  • Enabled auto recovery only from vRLCM
  • With Skip = true, auto recovery was enabled successfully

Step 4: Retry PostgreSQL Patch

  • Triggered patch again
  • With Skip = true, the request completed successfully

 

Final Outcome

After applying the above steps:

  • PostgreSQL cluster patch completed successfully
  • OpenSearch status updated correctly in UI (no more “Unknown”)
  • vIDM UI was fully accessible
  • Authentication via vIDM to vRA worked without issues

 

Key Takeaways

  • Auto recovery step in vRLCM can fail silently during PostgreSQL patching
  • OpenSearch issues may impact cluster visibility and health reporting
  • Using “Skip = true” strategically helps bypass blocking steps
  • Always validate:
    • Cluster health
    • Service status
    • Permissions for OpenSearch logs

Conclusion

The CSP-102547 patch upgrade was successful overall, but required additional troubleshooting during PostgreSQL cluster patching.

By isolating the issue around auto recovery and OpenSearch, and using controlled execution in vRLCM, the environment was stabilized and fully operational.

Comments

Post a Comment

Popular posts from this blog

Creating Snapshots for Unmanaged VMs in Aria Automation (vRealize Automation)

-
Image
 In multi-tenant environments powered by Aria Automation (vRealize Automation) , it's common for tenants to occasionally request snapshots for unmanaged virtual machines (VMs) . These unmanaged VMs exist in vCenter but are not provisioned through vRA and therefore fall outside the standard automation lifecycle. To address this need without impacting the broader environment or other tenants, we implemented a dedicated catalog item that allows tenants to safely request snapshots for their unmanaged VMs— securely, in isolation, and with auditability . Here’s how we approached this solution using a custom workflow and catalog configuration in Aria Automation. The Challenge Tenants may operate legacy or externally imported VMs that are not managed via vRA’s provisioning engine. Creating snapshots for these VMs traditionally requires manual intervention from infrastructure teams, which: Increases support overhead Introduces potential human errors Offers ...
Read more

Bulk import security policies into Palo Alto Networks firewalls

-
Image
To bulk import security policies into Palo Alto Networks firewalls, you'll typically need to leverage the Palo Alto API or CLI with a script. I am using an Excel file (XLS), IP address validation, and mapping source and destination zones, for comprehensive solution to automate the process. 1. Input from XLSX File : You will first need to read the data from the XLS file. 2. Check for Existing Rules : Before creating new rules, you should check if similar rules already exist on the firewall. This could be done by comparing the rule names, source, and destination IPs, and zones. 3. Mapping Source Zone and Destination Zone : Ensure that the source and destination zones are correctly mapped according to your firewall configuration. 4. IP Address Validation : Before adding a rule, you'll need to validate that the IP addresses specified in the file are valid 📝  Flow Diagram  (Text Representation) Further Automation If you need enhancements or additional automation features , fee...
Read more

Automating Tag Creation & Assignment to VMs with vRA + vRO

-
Image
  Use Case Summary A user provisions a VM from vRA. Once the VM is deployed in vCenter , a vRO workflow is triggered via Event Broker subscription. The workflow: Checks if the Tag exists (using REST API to NSX-T). If not found, creates the Tag under the correct category. Assigns the Tag to the newly provisioned VM. This eliminates the need for manual intervention and ensures every VM is tagged correctly for policies, automation, and visibility . High-Level Flow VM Provisioning in vRA User requests VM with required details (e.g., Environment, Owner, Application). Event Broker Subscription After provisioning, vRA triggers a vRO workflow . vRO Workflow Actions Connects to vCenter using REST API. Checks if Tag exists. If exists → Skip creation. If not exists → Create new Tag under category. Assigns Tag to the VM. Result VM is provisioned with the right tags automatically applied . Flow Diagram Steps Start VM Prov...
Read more