How to Create a VMware Cluster: Step-by-Step Guide (2025)…

Creating a VMware cluster means bringing multiple ESXi hosts under one shared resource and management boundary so that DRS, HA, and centralized operations can work together. The short answer is this: prepare vCenter and host onboarding first, create a new cluster object under the datacenter, enable vSphere DRS and vSphere HA if needed, choose the right automation mode, and plan admission control before production workloads rely on it. This guide is written for administrators working in the August 25, 2025 context.

Quick Summary

Broadcom KB 308413 and TechDocs define a cluster as a group of ESXi hosts operating with shared resources and a shared management interface.
Broadcom TechDocs states that you can create a cluster without a special license, but you need licensing to enable vSphere DRS or vSphere HA.
DRS automation levels are Manual, Partially Automated, and Fully Automated.
Broadcom TechDocs explicitly says you must have at least 3 hosts in the cluster to use vSphere HA admission control.
Broadcom KB 394680 shows that in a two-host cluster, maintenance mode can stall even with fully automated DRS when HA admission control is enabled.
Broadcom KB 396016 explains that Insufficient HA failover resources alerts can be caused by admission control settings and VM reservations.
In the August 25, 2025 context, Broadcom KB 326316 lists vCenter Server 8.0 Update 3g / 8.0.3.00600 / Build 24853646 as one of the visible current vCenter 8 baselines.

What Should Be Ready Before Creating a Cluster?

This guide is for teams building a new compute cluster under vCenter and then managing hosts, networking, storage, and policy behavior at the cluster level. The wizard is short, but the real work is prerequisite planning.

Before you start, make sure these items are clear:

vCenter is already installed
the ESXi hosts intended for the cluster are already added to vCenter
management networking and time synchronization are validated
host hardware and capacity profiles are reasonably aligned
it is clear whether you will enable DRS, HA, or both
the admission control model is decided before production use

Creating a cluster is not just creating an object. It is defining operational behavior for failover, placement, and balancing.

Which vCenter Baseline Makes Sense for August 25, 2025?

Cluster behavior depends on the vCenter build managing it. According to the build table in Broadcom KB 326316, one visible vCenter 8 baseline in the August 25, 2025 context is:

Product: vCenter Server 8.0 Update 3g
Version: 8.0.3.00600
Release date: 2025-07-29
Build: 24853646

This guide uses vCenter Server 8.0 Update 3g / Build 24853646 as the operational baseline.

What Is the Cluster Logic Behind DRS and HA?

Broadcom KB 308413 explains that a vSphere DRS cluster is a collection of ESX or ESXi hosts and associated virtual machines working with shared resources and a shared management interface. The same official explanation says that a vSphere HA cluster lets hosts work together so that, as a group, they provide higher availability than an individual ESXi host can provide by itself.

In practical terms:

DRS is about placement and load balancing
HA is about recovery behavior when a host or workload fails

That is why the first correct question is not “Should I create a cluster?” but “How do I want DRS and HA to behave in this cluster?”

How to Create a VMware Cluster Step by Step

1. Create a New Cluster Under the Datacenter

According to Broadcom KB 308413 and the TechDocs workflow, you start from the intended datacenter in vSphere Client and launch New Cluster.

At this stage, the cluster name should already reflect operational meaning such as site, workload type, or purpose. This helps later when policies, alarms, and capacity decisions scale.

2. Decide on DRS and HA Together with Licensing

TechDocs makes an important distinction:

you can create the cluster object without a special license
you need licensing to enable vSphere DRS or vSphere HA

So before you switch services on, confirm the licensing model. Enabling DRS or HA first and then finding out licensing is wrong creates unnecessary operational churn.

3. Choose the DRS Automation Level

Broadcom TechDocs defines three DRS automation levels:

Manual
Partially Automated
Fully Automated

The practical difference is:

Manual: initial placement and migrations are recommendations only
Partially Automated: initial placement is automatic, migrations remain recommendations
Fully Automated: initial placement is automatic and migrations are run automatically

For many first-time production clusters, Partially Automated is the safest starting point because it provides automatic placement without immediately turning every balancing action into an automated migration.

4. Enable HA Based on the Failure Model You Actually Need

Once HA is enabled, the cluster becomes more than a resource group. It now carries failover behavior.

Before completing the configuration, decide:

will admission control remain enabled?
how many host failures should be tolerated?
are there significant VM CPU or memory reservations?
is this a two-host design or a three-plus-host design?

These answers determine whether your cluster behaves predictably during maintenance and failure events.

5. Plan Admission Control Based on Host Count

Broadcom TechDocs explicitly states that you must have at least 3 hosts in the cluster to use vSphere HA admission control. That sentence matters because it changes how small clusters should be designed.

Broadcom KB 394680 shows the field impact of that rule: in a two-host cluster, maintenance mode can stall even when DRS is fully automated if HA admission control is enabled.

That leads to a practical rule set:

for a 2-host cluster, test admission control behavior carefully before production maintenance
for a 3+ host cluster, failover capacity planning is more predictable

6. Move the Hosts into the Cluster

After the cluster object is created, the ESXi hosts already onboarded into vCenter are placed into the cluster. At this point the goal is no longer only visibility, but shared policy and scheduler behavior.

After moving hosts into the cluster, validate:

all hosts are Connected
DRS service state looks healthy
HA service state looks healthy
shared networking and datastore visibility are consistent

7. Review the First Alarms and Resource Health

Immediately after cluster creation, review the first health signals. Broadcom KB 396016 explains that Insufficient HA failover resources alerts can come from admission control settings and VM reservations.

In the first minutes after go-live, check:

cluster alarms
HA failover resource sufficiency
VM CPU and memory reservations
admission control behavior
DRS recommendations

Most Common Cluster Warnings and Design Mistakes

`Insufficient HA failover resources`

Broadcom KB 396016 says this usually comes from two places:

HA admission control configuration
VM reservations in the cluster

If a two-host cluster is expected to satisfy aggressive HA guarantees, or if VM reservations exceed what the remaining host can provide, this warning is expected.

VMs not migrating during maintenance mode

Broadcom KB 394680 shows that on a two-node ESXi cluster, maintenance mode can stop progressing even with fully automated DRS if HA admission control is enabled. In practice, the fix is to adjust admission control behavior or add another host.

The cluster exists but DRS or HA cannot be enabled

The most common cause is licensing. TechDocs clearly states that the cluster object itself is separate from the licensing needed for DRS and HA.

DRS feels too aggressive or too passive

This usually points to the wrong automation level. Teams that want automatic placement but manual review of balancing actions often get a cleaner operating model from Partially Automated.

First 20-Minute Checklist

The cluster object was created under the correct datacenter
DRS and HA were enabled with the expected license state
The automation level was chosen intentionally
Admission control was reviewed against the actual host count
All hosts show Connected
Shared datastore and networking visibility is correct
HA failover resource alarms were reviewed
DRS recommendation behavior matches expectations

Next Step with LeonX

After the cluster is created, the correct next step is to define datastore standards, vMotion networking, HA and DRS policies, backup integration, and capacity monitoring as one operating model. That is how a cluster becomes operable instead of merely existing.

Related pages:

Frequently Asked Questions

Does creating a VMware cluster require a special license?

Not for the cluster object itself. But Broadcom TechDocs says you need licensing to enable vSphere DRS or vSphere HA on that cluster.

Which DRS automation level should be chosen?

That depends on the operating model. Manual is the most controlled, Fully Automated is the most aggressive, and Partially Automated is often the best initial balance because placement is automatic while migrations remain recommendations.

Why is 3 hosts such an important number for HA admission control?

Because Broadcom TechDocs explicitly says you must have at least 3 hosts in the cluster to use vSphere HA admission control. Small clusters can still work, but their failover design needs more care.

Is a 2-host cluster impossible?

No. It is possible. But Broadcom KB 394680 shows that maintenance and admission control behavior can become more fragile in a two-host design.

What does `Insufficient HA failover resources` really mean?

According to Broadcom KB 396016, it means the HA admission control model or VM reservation profile does not align with the actual capacity available in the cluster.

Conclusion

Creating a VMware cluster is not just grouping hosts together. It is a design decision about DRS behavior, HA failover posture, licensing, and capacity discipline. In the August 25, 2025 context, the safest approach is to work from a visible current vCenter 8 baseline, confirm licensing first, map DRS automation to the real operating model, and make the HA admission control decision according to the actual host count.

If you need support with cluster design, admission control planning, or post-onboarding operating standards, you can contact LeonX.

Sources

Share this article

Facebook

Twitter