Configuring VMware vCenter scheduling rules for DRS and HA
Virtualization platforms rely on intelligent workload placement to keep applications responsive and resilient. Within VMware vSphere, the Distributed Resource Scheduler and High Availability clusters form the backbone of automated resource management. When administrators understand how these mechanisms interact, they can fine-tune VM behaviour to match business priorities rather than relying on defaults.
Scheduling rules are the bridge between raw cluster automation and the operational realities of running production workloads. Affinity, anti-affinity, and VM-host relationships shape where virtual machines land during initial placement and during live migrations triggered by imbalance events. These rules prevent scenarios where two database replicas end up on the same physical host, creating a single point of failure that defeats the purpose of clustering.
Australian enterprises operate across multiple time zones, from Perth in the west to Brisbane and Melbourne in the east, and often run critical systems that cannot tolerate unplanned downtime. Local regulations around data sovereignty, combined with the country's reliance on interconnected industries like banking and telecommunications, mean that even short outages carry reputational and financial consequences. Configuring scheduling rules thoughtfully helps meet the expectations of boards, auditors, and end users.
This walkthrough explores how to design, apply, and troubleshoot these rules within vCenter Server. Practical examples, PowerCLI snippets, and Australian-specific scenarios will anchor each concept, so the guidance translates directly to your own hybrid IT environment.
How DRS and HA interact in a cluster
DRS continuously balances compute and memory across ESXi hosts, while HA restarts failed workloads after host or VM crashes. Scheduling rules belong to DRS, but they directly affect HA behaviour because a poorly placed workload can undermine failover capacity. Admission control policies within HA dictate how many host failures a cluster can tolerate, and they reference the same resource pools that DRS manages.
When administrators create VM-host affinity rules, they constrain where DRS can place workloads. An anti-affinity rule keeping two SQL servers apart improves resilience but may force DRS to make suboptimal balancing decisions. The interaction becomes more complex when stretched clusters span data centres in Sydney and Melbourne, where latency and replication considerations influence rule design.
A common pitfall is layering too many constraints on a small cluster. With only three hosts, applying multiple anti-affinity requirements can leave DRS with nowhere to move workloads during contention, which in turn triggers HA alarms during failover. Reviewing cluster size against rule density is a healthy habit for any administrator responsible for capacity planning.
Building DRS affinity and anti-affinity rules
Affinity rules keep specific VMs together on the same host, which suits tightly coupled application tiers. Anti-affinity rules do the opposite, separating workloads that should never share physical infrastructure. vCenter Server exposes these options under the cluster's Configure tab, where administrators define "should run on" or "must run on" relationships.
For Australian financial institutions like ANZ or Westpac, regulatory expectations often demand that primary and disaster recovery database instances never co-locate. Anti-affinity rules deliver this guarantee at the hypervisor layer, supplementing storage-level replication between sites. When defining these rules, give them descriptive names that reflect business intent, such as "DB-primary-DR-separation," so future audits and handovers remain straightforward.
Hard rules ("must run on") override DRS recommendations entirely, while soft rules ("should run on") guide DRS when no better option is available. Soft rules work well for performance-sensitive workloads, such as keeping a vRealize Operations cluster close to the workloads it monitors. Hard rules suit licensing boundaries, where software is bound to specific physical hardware.
Admission control policies for high availability
HA admission control reserves capacity so that failover remains possible when a host fails. Three policies ship with vCenter: slot-based, percentage-based, and dedicated failover hosts. Each balances cluster utilisation differently and interacts with scheduling rules in subtle ways.
Percentage-based admission control has gained popularity among Australian organisations because it scales with cluster growth and avoids the slot-size complications that arise from mixed VM sizes. A policy reserving 25 percent of cluster resources ensures failover capacity remains available even as workloads expand. Pair this setting with a clear anti-affinity rule set, and the cluster tolerates single-host failures across both Sydney and Brisbane sites without exhausting reserved capacity.
Dedicated failover hosts work well when licensing or compliance mandates specific hardware for standby roles. A government contractor handling protected-tier data may need to dedicate a host to specific clearance levels. Scheduling rules must then ensure that only designated VMs land on the reserved hardware, which means hard affinity rules paired with carefully scoped resource pools.
Maintenance windows and Australian business cycles
Scheduled tasks rarely align perfectly with local operational rhythms. Australian businesses often pause critical changes during the Christmas-New Year shutdown, when skeleton IT crews manage operations across the country. Building maintenance windows around public holidays, including Australia Day and ANZAC Day observances, reduces risk and respects staff availability across time zones.
PowerCLI scripts can automate rule enforcement during planned maintenance, applying temporary affinity changes when patching ESXi hosts. A common pattern involves creating a maintenance mode workflow that triggers rule evaluation after hosts re-enter the cluster. Pair this with a structured vCenter alarm strategy so administrators receive early warning when scheduling decisions drift from intent.
Time zone awareness matters when scheduling automated tasks across regions. AEDT shifts each October, and neglecting daylight saving transitions can push maintenance windows outside approved change windows. Configuring vCenter tasks with explicit Australian time zones, rather than relying on UTC offsets alone, prevents confusion during handover between Sydney and Melbourne operations teams.
PowerCLI automation for rule management
Manual rule configuration becomes unwieldy as environments scale. PowerCLI provides cmdlets such as New-DrsRule and Get-DrsRule for managing DRS constraints programmatically. Combined with vSphere tags, scripts can apply rule sets dynamically as workloads are tagged or retired.
A practical example involves exporting existing rules to CSV for quarterly governance reviews. Administrators in large managed service providers serving customers across Brisbane, Perth, and Adelaide often rely on these exports to demonstrate compliance posture. Storing rule definitions alongside infrastructure-as-code repositories ties VM placement decisions to broader change management practices.
Version control adds accountability to scheduling rule changes. Treating DRS configurations as code means reviews accompany every modification, which reduces the risk of conflicting rules appearing in production. PowerCLI pipelines running through CI tools can validate new rules against existing clusters before deployment, catching logic errors before they affect live workloads.
Resolving rule conflicts and troubleshooting
Conflicting rules generate warnings in vCenter, but they do not always block deployment. A VM with two anti-affinity requirements that cannot both be satisfied may simply be left unscheduled, leading to orphaned VMs that never boot. Administrators must review the cluster's Monitor tab regularly to catch these silent failures.
Diagnostic logging within vCenter records rule evaluation outcomes, and esxtop provides real-time visibility into how rules influence VM placement. When troubleshooting, start by reviewing the DRS recommendations log to understand why specific migrations were allowed or denied. Cross-reference this with admission control failures during HA events to map rule behaviour to operational impact.
Communication between infrastructure and application teams prevents rule conflicts at the source. When a new workload requests specific placement, the request should include rationale and expected lifespan. Embedding this conversation in standard service request templates saves time and keeps the cluster free from overlapping constraints.
Practical scenarios from Australian datacentres
Consider a national retailer running point-of-sale infrastructure across Sydney and Melbourne distribution hubs. Affinity rules keep POS application servers close to their database tier, while anti-affinity rules separate payment processing workloads from reporting instances. HA admission control reserves capacity so a host failure during peak Christmas trading does not interrupt transactions.
Another scenario involves a university in Brisbane hosting research workloads with strict licensing constraints. Hard affinity rules bind certain VMs to hosts carrying GPU capabilities, ensuring compliance with software agreements. Soft anti-affinity rules distribute batch processing jobs evenly across the remaining hosts, maximising throughput during semester peaks.
Telecommunications providers operating under the Telecommunications Act and aligned with Telstra engineering standards often layer DRS behaviour across regional points of presence. Scheduling rules support network function virtualisation by keeping control plane and data plane components separated, which simplifies fault domain analysis when incidents occur.
Recommendations for reliable scheduling rules
- Audit DRS and HA configurations quarterly and after significant cluster changes
- Prefer soft rules over hard rules when business requirements allow flexibility
- Combine rule definitions with infrastructure-as-code workflows to enforce reviews
- Document the operational intent behind every rule using descriptive names
- Test failover scenarios regularly to confirm admission control capacity matches expectations