When upgrading from VCF Automation 9.0.x to 9.1.x, the "Perform Component Upgrade" step may hang or fail. Specifically, tenant-manager or vcfa-service-manager pods may remain stuck in the Init status.
Note: Pods stuck in Init can also indicate underlying Kubernetes issues (e.g., missing configmaps or CSI driver registration failures). Before applying this fix, verify the log signature below to confirm this KB applies to your environment.
The Tenant Manager upgrade log (e.g., cell.log or the post-install-config/upgrade task log) will show the DB upgrade task failing and rolling back with this signature:
org.postgresql.util.PSQLException: Bad value for type int : <large number>
at org.postgresql.jdbc.PgResultSet.getInt(...)
at com.vmware.vcloud.upgrade.tasks.vcf9.CopyVdcStorageClassLRToVcfVdcStorageClass.call(CopyVdcStorageClassLRToVcfVdcStorageClass.java:73)
followed by: Failed to batch copy region quota storage classes from vdc logical resource table
VCF Automation 9.1.1
During the upgrade, the task CopyVdcStorageClassLRToVcfVdcStorageClass migrates VDC storage-class limits from the legacy vdc_logical_resource table to the new vcf_vdc_storage_class table. While both tables use bigint for storage limits, the migration task incorrectly attempts to read/write these as Java int. Any storage class with a limit exceeding Integer.MAX_VALUE (2,147,483,647 MiB, or ~2 PiB) causes the task to throw an exception, aborting the upgrade transaction.
Run this query against the Tenant Manager database before starting the upgrade to identify problematic storage classes:
SELECT lr.id, lr.name, lr.lr_limit, vdc.id AS vdc_id
FROM vdc_logical_resource lr
INNER JOIN vcf_virtual_datacenter vdc ON lr.vdc_id = vdc.org_prov_vdc_id
WHERE lr.lr_type = 'STORAGE_CLASS'
AND lr.lr_limit > 2147483647;
If this query returns rows, the upgrade will fail without intervention.
This issue requires direct database changes and should only be performed by GSS or Engineering. Customers encountering this issue must open a Support Request (SR) to engage GSS.