VM Affinity Anti-Affinity Rules

This document describes how to create affinity and anti-affinity rules for your virtual machines, the placement behavior each rule produces, and how those rules interact with other Private Cloud Director operations such as Dynamic Resource Rebalancing (DRR), VM High Availability (VM HA), maintenance mode, and migration.

Overview

Server groups are the mechanism Private Cloud Director uses to apply affinity and anti-affinity rules. A server group is a logical group of virtual machines that shares a single placement policy. Membership in a server group controls how the member VMs are placed across the hypervisor hosts in your virtualized cluster.

Private Cloud Director supports four policies. Two are strict ("hard") and two are best effort ("soft").

Policy	Rule strength	Placement goal	If the goal cannot be met
Affinity	Strict (hard)	All VMs in the group run on the same host	The operation fails
Soft affinity	Best effort	Keep all VMs in the group on the same host	VMs may be placed on different hosts
Anti-affinity	Strict (hard)	No two VMs in the group run on the same host	The operation fails
Soft anti-affinity	Best effort	Spread VMs in the group across different hosts	Two or more VMs may share a host

• Affinity (hard). Restricts all VMs in the group to the same hypervisor host. If no single host can hold every member, the operation fails.
• Soft affinity. Attempts to keep all VMs in the group on the same host, but allows them to run on different hosts when that is not possible.
• Anti-affinity (hard). Restricts the VMs in the group to separate hosts, so that no two members run on the same host. If there are not enough eligible hosts, the operation fails.
• Soft anti-affinity. Attempts to keep the VMs in the group on separate hosts, but allows two or more of them to share a host when that is not possible.

A server group has exactly one policy. You cannot combine affinity and anti-affinity, or hard and soft, within the same group.

Not the same as failure-domain affinity

Server groups govern VM-to-VM placement: which VMs run together or apart. Stretched Clusters introduces a separate VM-to-failure-domain soft affinity, which expresses which site a VM prefers. The two mechanisms are independent and compose: a VM can belong to a server group and also carry a failure-domain preference at the same time.

Prerequisites

• A virtualized cluster with one or more hosts that have the hypervisor role.
• Enough host capacity for the policy you choose. A hard affinity group needs a single host with enough capacity for every member. A hard anti-affinity group needs at least as many eligible hosts as it has VMs. Anti-affinity and soft anti-affinity are only meaningful when the cluster has more than one hypervisor host.
• The server group must exist before you create the VMs that will belong to it.
• The appropriate role. Administrators and self-service users can create and delete server groups. Read-only users cannot.

Create a Server Group

To create a server group from the UI:

1. Navigate to Virtual Machines > Server Groups and click the Create Server Group button.
2. In the Name field, enter a descriptive name for the server group.
3. From the Policy dropdown, select one of Affinity, Soft Affinity, Anti-Affinity, or Soft Anti-Affinity. See Overview for what each policy does.
4. Click the Create Server Group button.

You can now add a VM to this server group as part of the VM creation wizard, or change membership after the VM is created. See Manage Server Group Membership.

Manage Server Group Membership

A VM's server group can be selected when the VM is created, in the VM creation wizard. You can also add an existing VM to a server group, or remove a VM from one, after the VM has been created.

Only VMs in the Active or Stopped state are eligible to be added to or removed from a server group.

Add or Remove a Single VM from the Virtual Machines List

To add or remove one VM at a time:

1. Navigate to Virtual Machines.
2. Select a VM and choose Add to Server Group (for a VM that is not currently in a server group) or Remove from Server Group (for a VM that is a member of one).
3. Complete the dialog to confirm the action.

A VM that already belongs to a server group cannot be added to a different one directly; remove it from its current group first.

Add or Remove Multiple VMs from the Server Groups Page

To add or remove several VMs from a server group in a single action:

1. Navigate to Virtual Machines > Server Groups.
2. Select the server group you want to modify.
3. From Manage Assignment, choose Assign VMs to add eligible VMs to the group, or Unassign VMs to remove one or more current members.
4. In the Assign VMs dialog, click Assign next to each VM you want to add. In the Unassign VMs dialog, select one or more member VMs and click Unassign VMs.

Each server group also has a details page with an Overview tab that shows the group's policy, quota, member count, and current member VMs.

Policy Validation When Assigning a VM

Adding a VM to a server group only updates the group's membership — it does not migrate the VM to a different host to satisfy the policy. Private Cloud Director validates the VM's current placement against the group's policy before completing the assignment:

• Hard affinity or hard anti-affinity conflict. The assignment is blocked. You must adjust the policy, choose a different VM, or select a different server group.
• Soft affinity or soft anti-affinity conflict. A warning explains that the assignment may affect placement, performance, or availability. You can choose to proceed or cancel.
• No conflict. The VM is added immediately.

How Affinity Rules Interact With Private Cloud Director Operations

After a server group is created and its VMs are running, the group's policy continues to govern placement during automated and administrative operations. The table below summarizes the behavior for powered-on VMs.

Policy	DRR	VM HA	Maintenance mode	Live and cold migration
Affinity (hard)	DRR does not rebalance members of a hard affinity group. The Compute Service cannot find a valid target for a single member without breaking the rule, so the VM is skipped.	On host failure, VM HA looks for a single host with enough capacity for the entire group and restarts all members there together. If no such host exists, HA fails for the group and the UI reports the failure.	Entering maintenance mode fails if any powered-on member of a hard affinity group is on the host. The UI reports the policy violation.	Migration fails. The platform cannot move every member together in a single operation, so a single member cannot be relocated without breaking the rule. See Limitations.
Soft affinity	DRR may rebalance members. A member with no explicit migration priority is treated as low priority for rebalancing; a member with a set migration priority is honored at that priority.	VM HA tries to restart all members together on a single host with enough capacity. If none is available, it restarts the members individually, which may place them on different hosts, and the UI reports an affinity policy violation.	Best effort. Private Cloud Director keeps members together where capacity allows and places the remainder on other hosts. The group may end up split across hosts.	Allowed. The UI warns that the move may violate the soft affinity policy but does not block it.
Anti-affinity (hard)	When choosing a migration target, DRR excludes any host that already runs another member of the group.	On host failure, VM HA restarts each VM on a host that is not running another member VM. If no compliant host is available, HA fails for that VM and the UI reports the failure. A member on an offline host is shown as disconnected.	Entering maintenance mode fails if no target host preserves the anti-affinity rule.	Migration fails when the selected target host already runs another member of the group. The UI filters out non-compliant hosts.
Soft anti-affinity	Same rebalancing behavior as soft affinity. Members are honored at their set migration priority, or treated as low priority when none is set.	VM HA tries to restart each member on a host that is not running another member. If none is available, it may restart on a host that already runs a member and reports an anti-affinity policy violation. If it cannot restart the VM at all, HA fails and the VM is shown as disconnected.	Best effort. Members may be co-located on a host when capacity requires it.	Allowed even when the target host runs another member. The UI warns of the membership but does not block the move.

Hot add of CPU or memory does not affect affinity rules. A hot add operation does not move a VM to a different host, so a hot-added VM keeps the same placement and never violates an affinity or anti-affinity rule, regardless of the policy type.

Limitations

• Private Cloud Director cannot move all members of a server group together in a single, atomic operation. As a result:

  • Live or cold migration of a VM in a hard affinity group fails. Moving one member VM on its own would break the rule that all members share a host, and the platform cannot relocate the entire group in one step.
  • Live or cold migration of a VM in a hard anti-affinity group fails when the selected target host already runs another member of the group.
  • Soft affinity and soft anti-affinity groups are not affected, because their rules are best effort and the platform is allowed to break them when necessary.
• Adding a VM to a group does not move the VM. Assigning an existing VM to a server group is a membership change only. If the VM's current placement conflicts with a hard policy, the assignment is blocked; a soft policy conflict only warns you. See Policy Validation When Assigning a VM.
• A VM can belong to only one server group at a time. To move a VM to a different group, remove it from its current group first, then add it to the new one.
• One policy per group. A server group enforces a single policy. Affinity and anti-affinity, or hard and soft, cannot be mixed in the same group.
• Capacity and host count govern strict policies. A hard affinity group needs one host with enough capacity for every member, and a hard anti-affinity group needs at least as many eligible hosts as it has members. When these conditions are not met, VM creation, an HA restart, or a maintenance-mode evacuation can fail because no valid host is available.

VMware Equivalents

If you are coming from VMware, Private Cloud Director affinity rules map to vSphere DRS affinity rules as follows.

Private Cloud Director policy	Closest VMware DRS rule
Affinity	"Keep Virtual Machines Together", or a VM-Host "Must run on hosts in group" rule
Soft affinity	A preferential "should run" affinity rule
Anti-affinity	"Separate Virtual Machines", or a VM-Host "Must not run on hosts in group" rule
Soft anti-affinity	A preferential "should not run" separation rule

As in vSphere, a hard rule blocks an HA restart that would violate it, while a soft rule lets HA restore availability first, even if that temporarily breaks the rule, and rebalances toward compliance afterward.

Stretched Clusters adds a separate VM-to-failure-domain soft affinity. It is closer to a VM-Host "should run on hosts in group" rule in a vSphere Metro Storage Cluster than to any of the VM-to-VM policies above.