After updating Supervisor Services on vCenter 8.0 Update 3, configuration remains stuck at "Configured Core Supervisor Services"
search cancel

After updating Supervisor Services on vCenter 8.0 Update 3, configuration remains stuck at "Configured Core Supervisor Services"

book

Article ID: 372640

calendar_today

Updated On:

Products

VMware vSphere with Tanzu

Issue/Introduction

  • Running vCenter Server 8.0 Update 3 or later
  • After updating Supervisor Services, the configuration process remains stuck and loops at "Configured Core Supervisor Services":
  • When checking details of the update process, at least one of the following error messages can be seen:
    (where 192.168.0.10 is the virtual IP of the Supervisor Cluster)

    Service: velero.vsphere.vmware.com. A general system error occurred. Error message: Get "http://localhost:1080/external-cert/http1/192.168.0.10/5000/v2/velero-vsphere/package/velero-vsphere/manifests/1.6.1-23741747": net/http: request canceled (Client.Timeout exceeded while awaiting headers).

    Service: tkg.vsphere.vmware.com. A general system error occurred. Error message: Get "http://localhost:1080/external-cert/http1/192.168.0.10/5000/v2/tkg-svs/package/tkg-service/manifests/3.0.0": net/http: request canceled (Client.Timeout exceeded while awaiting headers).

  • The network communication on TCP/5000 is blocked/not working between vCenter Server and the Supervisor Cluster.

Environment

vCenter Server 8.0 Update 3

Workload Management/vSphere IaaS is enabled

Cause

Since vCenter Server 8.0 Update 3 additional checks have been added, where the service wcp on the vCenter is retrieving the manifest of certain container images. These container images are hosted on the container registry running on the Supervisor Cluster. Due to this, vCenter now requires network connectivity to the virtual/shared IP of the Supervisor Cluster cluster on port TCP/5000.

Resolution

Allow network communication between vCenter Server to the virtual/shared IP of the Supervisor Cluster via TCP/5000, where the container registry is running on. During the next configuration attempt, the issue should be solved.