After resetting the root password for the VMware Data Services Manager (DSM) appliance, you observe the following symptoms:
vCenter Server events are flooded with error: Cannot login dsm-mr-xxxxxxxx@vsphere.local Error vim.event.BadUsernameSessionEvent.
Database clusters show as healthy in the DSM UI, but connection errors persist in vCenter.
In the DSM provider appliance, the lastServiceAccountRotationTime in the vcenterbinding metadata shows a timestamp older than the recent password rotation.
VMware Data Services Manager for VCF 2.2.3.
DSM root password was expired and performed a reset.
This issue occurs because the rotated service account credentials fail to synchronize with the workload clusters following the root password reset. The workload clusters continue to attempt logins using stale credentials, leading to the BadUsernameSessionEvent in vCenter. This is a known issue in DSM versions prior to 9.0.2.
This issue is resolved in VMware Data Services Manager 9.0.2. Broadcom recommends upgrading to this version or later to prevent this behavior.
If you are on an earlier version (such as DSM 2.2.3), you can force a credential synchronization by restarting the CSI-controller pods across all impacted workload clusters.
Please open a Support request with Broadcom for assistance on this.
Step to Verify the Rotation State
SSH to the DSM Provider appliance as root.
Run the following command to check the vCenter binding status: kg get vcenterbinding -o json from DSM provider command line.
Verify if lastServiceAccountRotationTime reflects an older timestamp compared to your recent password rotation.