A vSphere cluster is not just a folder of hosts. It is an operating boundary.

The boundary should tell operators what can fail, what can be maintained, which workloads can coexist, and which automation contracts are safe to depend on. If the cluster boundary is unclear, Terraform, Packer, backup tooling, and Kubernetes node workflows inherit ambiguity.

What The Cluster Owns

Use the cluster to express infrastructure responsibility:

  • HA and maintenance-mode headroom.
  • host compatibility for the workloads placed there.
  • common datastore and network reachability.
  • DRS behavior and placement assumptions.
  • operational ownership and escalation path.
  • automation target for VM provisioning.

Do not let clusters become accidental mixtures of every host that had spare capacity. That makes capacity look larger while making failure behavior harder to reason about.

Boundary Questions

Before adding hosts or moving workloads, answer:

Which workloads belong here?
Which workloads must not share this failure domain?
Can the cluster lose one host and still run the critical set?
Can it enter maintenance mode without draining platform capacity?
Do all hosts see the required datastores and port groups?
Do automation tools reference this cluster by stable name or ID?

The goal is not perfect segmentation. The goal is explicit tradeoffs.

Capacity Is Failure Tolerance

Cluster capacity review should not stop at CPU and memory utilization.

Review:

  • effective N+1 or N+2 headroom for the workload class.
  • memory pressure and ballooning/swap history.
  • datastore contention and free-space trend.
  • network uplink saturation during backup or migration windows.
  • host maintenance frequency and firmware cadence.
  • HA admission control policy and whether operators trust it.

A cluster at 55 percent CPU can still be operationally full if it cannot absorb a host failure, a storage path issue, or a maintenance evacuation.

Contracts For Automation

Terraform, Packer, and node replacement workflows need cluster names to behave like contracts.

Treat these as breaking changes:

  • renaming clusters used by modules or pipelines.
  • moving templates to folders unavailable to the target cluster.
  • adding hosts without the expected port groups or datastore access.
  • changing resource pool structure without updating consumers.
  • changing DRS rules that automation depends on.

If automation targets a cluster, keep a small contract record:

cluster name
purpose / workload class
allowed VM folders
allowed resource pools
required datastores or datastore clusters
required port groups
DRS and HA assumptions
owner and escalation path

That record is more useful than a screenshot of current capacity.

Failure Model

The common failure is treating cluster placement as a harmless inventory move:

VMs move -> automation still points at old assumptions
-> host lacks datastore/network/DRS behavior
-> clone or maintenance fails under time pressure

The VM did not fail because vCenter was fragile. It failed because the cluster boundary stopped matching the automation contract.

The operating rule: a vSphere cluster is a schedulable failure domain. Design and document it that way.