VKS Workload Cluster Provisioning or Expansion Fails with Placement Error: PlaceVmsXCluster failed (Insufficient CPU resources)
search cancel

VKS Workload Cluster Provisioning or Expansion Fails with Placement Error: PlaceVmsXCluster failed (Insufficient CPU resources)

book

Article ID: 435459

calendar_today

Updated On:

Products

VMware vSphere Kubernetes Service

Issue/Introduction

When provisioning a new VMware vSphere Kubernetes Service (VKS) workload cluster or expanding an existing worker node pool, the operation fails or stalls indefinitely.

  • Cluster Status: Remains stuck in AVAILABLE = False or Provisioning state.
  • CLI Inspection: Running kubectl describe cluster <cluster-name> -n <namespace> or kubectl get events -n <namespace> reveals placement faults on worker machine objects similar to:

VirtualMachineProvisioned: PlaceVmsXCluster failed: faults: [ResourcePool <resource-pool-id> faults: The host does not have sufficient CPU resources to satisfy the reservation.]

MachineDeployment <cluster-name>-worker-pool: X available replicas, at least Y required

Environment

VMware vSphere Kubernetes Service (VKS)

VMware Cloud Foundation (VCF) / VMware vSphere Foundation (VVF)

Local Consumption Interface (LCI) 

Cause

This issue occurs when the backing vSphere Resource Pool assigned to the Workload Namespace lacks sufficient unreserved physical CPU capacity to fulfill the strict reservation requirements of the selected Virtual Machine Class.

Mechanism

  • Guaranteed Class Reservations: Worker node pools configured with a guaranteed-* VM Class (such as guaranteed-4xlarge or guaranteed-2xlarge) require a 100% CPU reservation at host placement and power-on.
  • Resource Pool Exhaustion: If the underlying vSphere Resource Pool assigned to the namespace does not have enough unallocated physical CPU capacity to meet 100% of the requested reservation, vSphere DRS / placement engine blocks node creation with the PlaceVmsXCluster failed error.

Resolution

IMPORTANT: If your VKS workload cluster was provisioned using the Local Consumption Interface (LCI) or vSphere Client UI, all topology modifications (VM Class updates or replica counts) must be performed directly through the vSphere Client UI. Executing changes via kubectl on LCI-managed clusters can cause spec drift and lifecycle reconciliation failures.

Select one of the following two resolution paths based on your workload requirements:

Option 1: Reconfigure Worker Node VM Class to best-effort-* (Recommended)

If 100% dedicated hardware CPU reservations are not strictly required for your workload, switch the worker node pool to a best-effort-* VM Class. best-effort classes do not mandate 100% CPU reservations at placement, allowing nodes to boot under shared resource pool conditions.

  1. Log in to the vSphere Client.
  2. Select the target Workload Namespace from the left navigation tree.
  3. Select the Resources tab in the main pane.
  4. Under the Kubernetes tile, click GO TO SERVICE.
  5. Select the affected VKS cluster from the vSphere Kubernetes Service list.
  6. Scroll down to Node pools, expand the target worker node pool, and locate VM Class.
  7. Click Edit and change the VM Class from guaranteed-* (e.g., guaranteed-4xlarge) to the equivalent best-effort-* class (e.g., best-effort-4xlarge).
  8. Click Save.

The Cluster API reconciler will sequentially re-provision the worker nodes. Once completed, the cluster status will transition to AVAILABLE = True.

Option 2: Reduce Worker Node Pool Replica Count

If guaranteed-* class reservations are strictly required but host hardware capacity cannot be immediately expanded, scale down the worker node pool replica count to fit the currently unreserved physical CPU capacity.

  1. Log in to the vSphere Client.
  2. Select the target Workload Namespace from the left navigation tree.
  3. Select the Resources tab in the main pane.
  4. Under the Kubernetes tile, click GO TO SERVICE.
  5. Select the affected VKS cluster.
  6. Scroll down to Node pools, expand the target worker node pool, and locate Replicas (or Minimum/Maximum nodes if autoscaling is enabled).
  7. Lower the Replicas count to match available host capacity (for example, reducing from 8 to 6 replicas).
  8. Click Save.

The reconciler will adjust the target topology state, complete node allocation, and transition the cluster status to AVAILABLE = True.

Additional Information

  • For more information on configuring and sizing Tanzu Virtual Machine Classes, refer to the Broadcom Documentation on Virtual Machine Classes for Tanzu Kubernetes Clusters.
  • If additional dedicated CPU capacity is required, consult your vSphere infrastructure administrator to expand the compute capacity of the backing vSphere Cluster or increase the CPU quota on the target Workload Namespace Resource Pool.