vIDM CSP-102547 upgrade Fails with 100% /db disk space exhaustion during Postgres migration

Products

• VCF Operations/Automation (formerly VMware Aria Suite)

Issue/Introduction

When attempting to apply the vIDM 3.3.7 Patch CSP-102547, the installation fails, freezes, or encounters an unexpected abort.

Reviewing the environment highlights the following specific system indicators:

• The primary storage partition dedicated to the data store (/db) rapidly escalates to 100% utilization, even if several hundred gigabytes of additional temporary storage were manually added prior to starting the upgrade.

• Checking disk utilization inside the guest OS via df -h isolates a massive, volatile surge inside a newly created workspace directory path: /db/oldData (which can scale to over 200 GB depending on historical data/token accumulation).

Environment

vIDM 3.3.7

Cause

This issue occurs due to a transient data duplication mechanism built directly into the automated Postgres database migration utility (pg_upgrade) used by the patch framework.

Before committing structural alterations or migrating database schemas, the update engine generates an absolute physical backup of all raw relational data tables inside a newly mapped directory named /db/oldData to safeguard data integrity.

If the production database holds a large volume of persistent historical records—particularly bloated OAuth refresh tokens (OAuth2RefreshToken table)—the temporary cloning task will instantly double the active storage footprint of the database. This rapidly exhausts the /db storage partition, breaks the relational migration pipelines mid-process, and leaves the database engine in an inconsistent, unstartable state.

Resolution

To recover the appliance and ensure a successful patch process, you must purge the bloated tables, scale up the virtual disks, and redeploy the patch workflow.

Step 1: Revert to Clean System Snapshots

Because the database tables were left in an inconsistent state when the disk hit capacity, you must revert to Snapshots/Backup.

1. Log into the managing vCenter Server web client.

2. Locate the impacted VMware Identity Manager (vIDM) virtual machine.

3. Revert the VM to its clean, pre-patch baseline snapshot taken prior to initiating the upgrade workflow.

Step 2: Clear the OAuth2RefreshToken Table

• To minimize the data footprint that needs cloning during migration, purge the transient token cache tracking tables following vIDM 3.3.x vPostgres DB OAuth2RefreshToken table consumes most space on the appliance leading to service outages.

Step 3: Expand Virtual Hardware Disks & Guest Partitions

• Expand the /db partition on the VMware Identity Manager (vIDM) node(s) to slightly more than double its current capacity, following the procedure outlined in the KB article: How to Increase vIDM appliance disk space.

  For example: If the /db partition is currently 200 GB, you should add an additional 250 GB of space."

• Add additional buffer space to the / (root) partition simultaneously to accommodate any high-volume OS logging transients.

Step 4: Execute the Patch Installation

• Re-trigger the vIDM patching per the steps outlined in CSP-102547 Patch Instructions for VMware Identity Manager 3.3.7 and VMware Aria Suite Lifecycle 8.18.0 Patch 8.