You can use affinity rules without using vSphere DRS.

VM affinity rules allow you to control the placement of VMs within a vSphere cluster. VM-VM affinity means the VMs must be run on the same host within a cluster. Workloads are comprised of multiple VMs that have dependencies on each other. Using Keep Virtual Machines Together rules ensure that all selected VMs run on the same host.

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

VM-Host affinity rules control the VM to Host relationship and has 4 sub-rules. Use cases for VM-Host rules would include making sure workloads run (or do not run) on specific 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 VM-Host rules leverage VM-Host groups. A VM group is a user-defined group of one or more VMs. A host group is a user-defined group of one or more hosts.
Rule Description Persistence
Must run on hosts in group The VM group must be run on the defined host group. A hard rule that cannot be violated.
Must not run on hosts in group The VM group must not be run on the defined host group. A hard rule that cannot be violated.
Should run on hosts in group The VM group should be run on the defined host group. A soft rule that can be violated.
Should not run on hosts in group The VM group should not be run on the defined host group. A soft rule that can be violated.

VM-Host groups and VM-Host rules can be created, deleted, and edited when vSphere DRS is not activated. The interface to manage VM-Host groups and VM-Host rules exists outside of the vSphere DRS configuration.

In the event of a vSphere HA failover of VMs, affinity rules are respected. This is true for rule types Keep Virtual Machines Together and Separate Virtual Machines, as well as hard VM-Host rule types. vSphere HA is unable to failover VMs if a hard rule would be violated. When using soft VM-Host rules, vSphere HA operations succeed even if the rule is violated. Soft rules allow for violation of their definitions.

For example, 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.

VM 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 VM-Host rules. When using soft VM-Host rules, power on operations succeed even if the rule is violated. Soft rules allow for violation of their definitions.

For example, if a rule is defined to Keep Virtual Machines Together 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 activated, the user must manually migrate the VMs to the same host to be able to power on the VM.

When vSphere DRS is not activated and therefore not automatically migrating VMs, you can initiate migrations using vSphere vMotion on VMs with affinity rules defined. Both rule types Keep Virtual Machines Together and Separate Virtual Machines can be violated by migrating using vSphere vMotion. For example, if a rule is defined to Separate Virtual Machines on VM-1 and VM-2, an attempt to migrate the VMs to the same host will not be blocked. The operation will succeed even though it would violate the rule.

Any hard VM-Host rule cannot be violated by a user-initiated migration. For example, if a rule is defined that VM-1 and VM-2 must run on hosts ESX-01 and ESX-02, an attempt to migrate the VMs to hosts outside of the host group is blocked.

Soft VM-Host rules can be violated by a user-initiated migration. Soft rules allow for violation of their definitions. For example, if a rule is defined that VM-1 and VM-2 should not run on hosts ESX-03 and ESX-04, an attempt to migrate the VMs to either ESX-03 or ESX-04 is not blocked.

When vSphere DRS is not activated, there is no automatic remediation of VM placement. This includes violations because of manual migrations and violations that occur if new rules are defined that would violate current VM placement. Without vSphere DRS, you must correct VM placement to comply with rules.