Using Virtual Machine Affinity Rules without vSphere DRS

Virtual Machine Affinity Rule Behaviour without vSphere DRS

Virtual machine affinity rules, sometimes (mistakenly) referred to as vSphere DRS affinity rules, allow you to define rules to control the placement of virtual machines within a vSphere cluster. But did you know that you can use affinity rules even when vSphere DRS is not enabled on a cluster?

About Virtual Machine Affinity Rules

Before we explain the behaviour of affinity rules without vSphere DRS, let us explain the rules available in vSphere.

Keep Virtual Machines Together

This is VM-VM affinity and means the virtual machines must be run on the same host within a cluster. Workloads may be comprised of multiple virtual machines that have dependencies on each other. Using Keep Virtual Machines Together rules allow you to ensure that all selected VMs are always running on the same host.

Separate Virtual Machines

This is VM-VM anti-affinity and means the virtual machines must be run on different hosts within a cluster. A Separate Virtual Machines rule is useful when you have multiple resource intensive or busy VMs. You can use Separate Virtual Machines rules to ensure that these VMs are always running on different hosts in the cluster to avoid resource contention.

Virtual Machines to Hosts

This rule type controls the VM to Host relationship and has 4 sub-rules. Use cases for Virtual Machine to Hosts rules would include making sure workloads run (or do not run) on certain hosts in a mixed-hardware cluster. For licensing reasons, you may need to ensure that an application only runs on a specific host or specific subset of hosts.

The Virtual Machine to Hosts rules leverage VM/Host Groups. A VM Group is a user-defined group of one or more virtual machines, and a Host Group is a user-defined group of one or more hosts.

Must run on hosts in group

This is VM-Host hard affinity and means the VM group must be run on the defined host group. It is a hard rule and cannot be violated.

Should run on hosts in group

This is VM-Host soft affinity and means the VM group should be run on the defined host group. It is a soft rule and can be violated.

Must not run on hosts in group

This is VM-Host hard anti-affinity and means the VM group must not be run on the defined host group. It is a hard rule and cannot be violated.

Should not run on hosts in group

This is VM-Host soft anti-affinity and means the VM group should not be run on the defined host group. It is a soft rule and can be violated.

VM/Host Groups and VM/Host Rules can be created, deleted, and edited when vSphere DRS is not enabled.

A screenshot of a computerDescription automatically generated with medium confidence

Figure 1 shows management of VM/Host Groups.

A screenshot of a computerDescription automatically generated with medium confidence

Figure 2 shows management of VM/Host Rules.

The interface to manage VM/Host Groups and VM/Host Rules exists outside of the vSphere DRS configuration.

vSphere HA Failover

In the event of a vSphere HA failover of virtual machines, affinity rules will be respected. This is true for rule types Keep Virtual Machines Together and Separate Virtual Machines, as well as, hard (must and must not) Virtual Machine to Hosts rule types. This means that vSphere HA is unable to failover virtual machines if a rule would be violated.

For example, we have a 2-node cluster and a Separate Virtual Machines rule defined to place VM-1 on ESX-01 and VM-2 on ESX-02. ESX-01 experiences a failure and vSphere HA is initiated. vSphere HA is unable to power on VM-1 on ESX-02 as it would violate the rule to keep each virtual machine separate.

When using soft (should and should not) Virtual Machine to Hosts rule types, vSphere HA operations succeed even if the rule is violated. This is expected because soft rules allow for violation of their definitions.

Virtual Machine Power On

Virtual machine power on operations do not allow affinity rules to be violated. This is true for rule types Keep Virtual Machines Together and Separate Virtual Machines, as well as, hard (must and must not) Virtual Machine to Hosts rule types.

For example, if a rule is defined to Keep Virtual Machines Together (affinity) on VM-1 and VM-2 and VM-1 is currently already powered on, an attempt to power on VM-2 will fail if it is registered to a different host. Since vSphere DRS is not enabled, the user must manually migrate the VMs to the same host to be able to power on the VM.

A screenshot of a computer errorDescription automatically generated with medium confidence

Figure 3 shows the error message when a power on operation violates a rule.

When using soft (should and should not) Virtual Machine to Hosts rule types, power on operations succeed even if the rule is violated. This is expected because soft rules allow for violation of their definitions.

User Initiated VM Migration Operations

In this scenario, since vSphere DRS is not enabled and therefore not automatically migrating virtual machines, we will discuss the results of user-initiated migrations, using vSphere vMotion, on virtual machines with affinity rules defined.

Both rule types Keep Virtual Machines Together and Separate Virtual Machines can be violated by a migrating using vSphere vMotion. For example, if a rule is defined to Separate Virtual Machines (anti-affinity) on VM-1 and VM-2, an attempt to migrate the virtual machines to the same host will not be blocked. The operation will succeed even though it would violate the rule.

Screens screenshot of a computerDescription automatically generated with medium confidence

Figure 4 shows VM-VM rules can be violated.

Any hard (must and must not) Virtual Machine to Hosts rule type cannot be violated by a user-initiated migration. For example, if a rule is defined that VM-1 and VM-2 (VM Group) must run on hosts ESX-01 and ESX-02 (Host Group), an attempt to migrate the virtual machines to hosts outside of the Host Group will be blocked.

Screens screenshot of a computerDescription automatically generated with medium confidence

Figure 5 shows hard (must or must not) VM to Hosts rules cannot be violated.

 Soft (should and should not) Virtual Machine to Hosts rule types can be violated by a user-initiated migration. This is expected because soft rules allow for violation of their definitions. For example, if a rule is defined that VM-1 and VM-2 (VM Group) should not run on hosts ESX-03 and ESX-04 (Host Group), an attempt to migrate the virtual machines to either ESX-03 or ESX-04 will not be blocked.

Screens screenshot of a computerDescription automatically generated with medium confidence

Figure 6 shows soft (should or should not) VM to Hosts rules can be violated.

What Happens if Rules are Violated?

In these scenarios, when vSphere DRS is not enabled, there will be no automatic remediation of virtual machine placement. This includes violations because of manual migrations, explained above, and violations that might occur if new rules are defined that would violate current virtual machine placement. Without vSphere DRS, users must correct virtual machine placement to comply with rules.

Learn More

For more on using VM/Host groups and affinity rules see the vSphere documentation about Using Affinity Rules.

Filter Tags

vSphere vSphere 7 vSphere 8 Document