During the installation phase of a Workload Cluster via the SSP-I (License Hub Installer), the deployment workflow fails at the MetalLB resource creation task.
The UI display shows:
FOR SSP 5.1.2
Task Failure: Failed 15/18 tasks: [Create metal lb resources] retryable command failed (attempt: 5). exit status 1
FOR License Hub 2.0
Failed 4/5 tasks: [Create metal lb resources] retryable command failed (attempt: 5). exit status 1When inspecting the support bundle or viewing ./var/log/secop/secop.log and ./var/log/syslog on the installer machine, the following error signatures are visible:
ERROR deployment/create_metallb.go:443 failed to run command {"error": "retryable command failed (attempt: 5). exit status 1"}
stderr: "Error: INSTALLATION FAILED: context deadline exceeded\nError: INSTALLATION FAILED: cannot re-use a name that is still in use..."(Note: The log may also contain PodSecurity warnings regarding metallb-speaker baseline violations, which are secondary symptoms of the timeout).
License Hub(SSP) - 5.1.2
License Hub 2.0
This issue occurs due to an underlying IP address conflict or stale MAC address caching (ARP pollution) on the Layer 2 network segment shared by the cluster nodes.
When the control plane and worker nodes are provisioned, if their assigned infrastructure management IP addresses are already occupied by another active virtual machine in the vSphere inventory, asymmetric routing occurs. As a result:
Internal cluster network overlay components (such as the Antrea CNI or internal load balancers) fail to achieve bidirectional communication.
The nodes cannot reach the API control surfaces or cleanly coordinate resources.
The cluster-bootstrap helm operators time out waiting for components to turn healthy, leading to context deadline exceeded and subsequent retry errors (cannot re-use a name that is still in use).
Log into your vSphere Client / vCenter Server.
Navigate to the global VMs view tab.
Filter the inventory using the pool of IP addresses designated for your new deployment.
Confirm whether an older, powered-on, or orphaned virtual machine (e.g., a node from a previous broken deployment attempt) is currently holding onto an IP assigned to your new cluster configuration.
If a conflicting VM is found, Power Off or change the IP configuration of the conflicting appliance to release the address block.
Completely Clean Up the failed deployment instance from the installer platform.
Trigger a clean re-deployment from scratch.