- VMware vSphere Tanzu: Basic vs. Standard vs. Advanced edition - Fri, Sep 17 2021
- Containers and VMware vSphere - Fri, Sep 10 2021
- How to install ESXi 7.0 U2 directly from an HTTP server via a UEFI HTTP boot - Fri, Sep 3 2021
VMware Distributed Resource Scheduler (DRS) balances and optimizes the VM's performance and DRS score (the DRS score is a measure of the resources available for consumption by the VM). The higher the DRS score for a VM, the better the resource availability for that VM. VMware DRS moves a VM from one host to another to improve this VM DRS score; however, it respects VM-to-VM affinity and anti-affinity rules.
Affinity rules are also respected by VMware High Availability (HA), which does the initial placement of VMs to a host. VM affinity/anti-affinity rules force specified virtual machines to remain together (or apart) during failover actions. If you create a DRS affinity rule for your cluster, you can specify how vSphere HA applies that rule during a VM failover.
Additionally, when your DRS is configured in fully automated mode, the system can misposition some VMs that you would not like to have placed there, as you might have a special requirement (separation or keeping together).
For example, if you have an application comprising multiple VMs (web frontend, application server, and database backend), there is likely strong network traffic among these three VMs. So the backend traffic would be quite significant if you allow those VMs to run on different hosts.
Common use cases for VM-to-VM affinity and anti-affinity rules ^
- Multi-node VMs—You need to improve the application and communication performance of multi-node VMs, which are also called vApps. You can use VM-to-VM affinity rules to make sure that the VMs transferring files between them stay on the same host and that the data does not traverse the physical network.
- Disaster recovery—When you need to improve or ensure DR for your multi-VM application, you want to make sure that you separate them so they each execute on a different host. You can have a database server on one host and a front-end web server on another host.
How to create VM-to-VM affinity or anti-affinity rules ^
Connect via vSphere client and browse to the cluster level. Then select Configure > VM/Host Rules > Add.
There, you'll see the Create VM/Host Rule dialog box. Type a name for the rule.
From the Type drop-down menu, select either Keep Virtual Machines Together (affinity) or Separate Virtual Machines (anti-affinity).
Then you'll need to select at least two virtual machines to which the rule will apply and click OK.
VM–Host rules ^
We saw a VM–VM affinity rule that specifies the affinity between individual VMs. However, a VM–Host affinity rule can define an affinity relationship between a group of VMs and a group of hosts.
There are 'required' rules (must) and 'preferential' rules (should).
A VM–Host affinity rule basically has three different parts:
- One VM DRS group
- One host DRS group
- A specification if the rule is a requirement (must) or a preference (should), and if it creates an affinity (run on this host) or an anti-affinity (do not run on this host).
These types of rules are usually used when setting up storage appliances, where each one must be attached to a single host. These types of Virtual Storage Appliances (VSAs) are not meant to be migrated or started on other hosts within a cluster.
In the example below, we have three VSA VMs (VSA01, VSA02, and VSA03) that run on three different hosts (ESXi01, ESXi02, and ESXi03). We will make sure that each VM always starts and executes on particular hosts.
Select your Cluster. Then select VM/Host Groups > Add.
Create two groups in separate steps: a VM group and a host group.
Then go back to the UI VM/Host rules and add a new rule.
For our case, where we need VSA01 to run on ESXi01, we simply pick the VSA01 group and the Host01 group that we previously created from the drop-down menu.
Click Validate and repeat these steps for the two other VSAs. You should end up with three different rules, like this:
The specification for the rule is as follows:
- Must run on hosts in group. Virtual machines in VM Group 1 must run on hosts in Host Group A.
- Should run on hosts in group. Virtual machines in VM Group 1 should, but are not required, to run on hosts in Host Group A.
- Must not run on hosts in group. Virtual machines in VM Group 1 must never run on hosts in Host Group A.
- Should not run on hosts in group. Virtual machines in VM Group 1 should not, but might, run on hosts in Host Group A.
VM–VM affinity rule conflicts ^
vSphere 7 is able to handle conflicts between rules. There are two different cases or scenarios.
There is no possibility of enabling both if in conflict—If two VM–VM affinity rules are in conflict, you cannot simply enable both. As an example, you can have one rule that keeps two VMs together and another rule that keeps the same two VMs apart on two different hosts; you cannot enable both rules. The system does not allow you to. You must select one of the rules to apply, and you must disable or remove the other, which causes the conflict. Smart, if you ask me.
One rule is older than the other one—When two VM–VM affinity rules conflict, the older one takes precedence and the newer rule is disabled. vSphere 7 DRS only tries to satisfy enabled rules. The disabled rules are ignored. DRS is able to recognize and prevent the violation of anti-affinity rules.
Final words ^
As you can see, the two types of rules we can create are perfect and fit most scenarios. As I said, these types of rules are usually needed for storage appliances or backup appliances that work together tightly with the host. Those VMs are not meant to move, as they usually use the host's physical disks.
Many new admins that are starting to use VMware technology do not know how to properly use affinity and anti-affinity VM/Host rules. We hope that this article has helped to clear some doubts.