How to modify the Provider Definition (pd) configuration in VCF Automation

Products

• VCF Automation

Issue/Introduction

VCF Automation 9.x upgrade prechecks may fail via VCF Operations Fleet if underlying vSphere infrastructure has been modified.

The precheck fails with a Platform Health Check Error output indicating it is unable to validate vSphere objects or resolve a specific identifier.

Platform Health Check Error [platform-vmsp-platform-validate-resources-vsphere-resources : unable to validate vSphere objects: unable to resolve <ObjectType> identifier <ObjectType>:<ID> ServerFaultCode: The object 'vim.<ObjectType>:<ID>' has already been deleted or has not been completely created] [VCFMS-HEALTH-002]

Depending on which underlying vSphere object is missing, the <ObjectType> in your error log will differ. Use the chart below to match your specific error string snippet to its dedicated troubleshooting article:

Infrastructure Variant	Error String Snippet	Spoke Article Reference
Cluster	...unable to resolve cluster identifier ClusterComputeResource...	VCF Automation Upgrade Prechecks pre-check result status: Failed for ClusterComputeResource:domain-#####
Resource Pool	...unable to resolve resourcePool identifier ResourcePool...	VCF Automation Upgrade Prechecks pre-check result status: Failed for ResourcePool:resgroup
Network / VDS	...unable to resolve network identifier Network...	VCF Automation Upgrade Prechecks pre-check result status: Failed for DistributedVirtualPortgroup

Environment

VCF Automation 9.1

Cause

This issue occurs when underlying vSphere infrastructure objects (such as a Cluster, Resource Pool, or VDS/Network Port Group) referenced by the vmsp control plane are deleted and recreated in vCenter, often resulting in new inventory names or paths.

The vmsp control plane pd (Provider Definition / Platform Deployment) configuration continues to point to the old, stale friendly names or paths (e.g., /QA/host/LINUX/Resources). Because these paths no longer match the current vCenter inventory, the vSphere object validation fails during the upgrade precheck phase.

Resolution

To resolve this issue, you must identify the new infrastructure names or paths in vCenter and update the pd configuration within the vmsp-platform namespace to match them.

Step 1: Identify the new friendly names or paths in vCenter

Log in to the vSphere Client and note the exact new inventory names and paths for your recreated infrastructure.

• Cluster Example: QA-OS (previously /QA/host/LINUX)

• Resource Pool Example: QA-VCF-MGMT

• Network Example: QA-VDS-PortGroup

Step 2: Update the stale configuration in VCF Automation

1. Connect to the vmsp control plane via SSH.

2. Log in as the vmware-system-user.

3. Switch to root access by running: sudo su -

4. Back up the current Provider Definition (pd) configuration by running: kubectl get pd -n vmsp-platform -o yaml > /tmp/pd-backup.yaml

5. Open the configuration for editing: kubectl edit pd -n vmsp-platform

6. Scroll down to the values: provider: vsphere: block. It will look similar to the following, containing the stale path values:

    values:
      provider:
        vsphere:
          cluster: /QA/host/LINUX
          network: /QA/network/VDS-QA
          resourcePool: /QA/host/LINUX/Resources

7. Modify the cluster, network, and/or resourcePool values to match the new friendly names or paths you identified in vCenter during Step 1.

8. Save and exit the editor (if using vi/vim, press Esc, type :wq, and press Enter).

9. The vmsp pods will automatically detect the configuration change and reconcile.

10. Retry the VCF Automation upgrade precheck in VCF Operations.

Additional Information

Do not modify datastore values if they are not correct. This procedure is covered in Storage configuration mismatch between VCF management components and vCenter causes VCF to fail upgrade or patching