Skip to main content
Version: 0.1 (unreleased)

Join a cluster

:::note Placeholder page :::

Ballast coordinates with Windows Failover Clustering rather than replacing it. Cluster formation, quorum and failover are owned by the cluster service; the centre declares intent and reports state, it does not hand-roll consensus.

Prerequisites​

  • Every host you intend to add has provisioned networking and matches the others closely enough to pass cluster validation (a TBC: whether Ballast runs Test-Cluster for you and surfaces the report, or expects it run separately first).
  • Shared storage is in place: Storage Spaces Direct (S2D) with Cluster Shared Volumes (CSV) in v1.
  • A witness is configured — file share or cloud, matching your quorum model.

Forming a new cluster​

Declare a ClusterSpec naming its member hosts. On apply, the centre assigns each named host's agent the work needed to bring it into the cluster; the cluster itself is created via New-Cluster.

Joining an existing cluster​

Declaring an existing ClusterSpec with an additional member host added drives that host's agent to join it, the same reconcile pattern as any other desired-state change.

Verifying​

The console's cluster view shows every declared member as settled (Generation == ObservedGeneration), the orchestration steps that got it there, and the cluster's quorum configuration side by side:

Ballast console cluster detail showing a healthy failover cluster settled at generation 13, every orchestration step matching desired state, and the file share witness configuration

"Settled" here means the generation counter, every reconcile step, and the desired-vs-observed comparison all agree — not a single green dot standing in for all three.

Standalone hosts are not second-class​

Everything in Provision a host works identically whether or not the host ever joins a cluster. Clustering adds failover, live migration on host death, and CSV — it does not gate basic host management.