Smarter VM Placement with Nutanix AHV - Part 1
Overview
In a virtualized environment, how and where your virtual machines (VMs) run isn't just a matter of resource availability. It's a key part of your resiliency, performance, and compliance strategy. That’s where Affinity and Anti-Affinity policies come into play.
With Nutanix AHV, administrators may gain granular control over VM placement through two types of rules:
- VM-Host Affinity Policies: Define where VMs should run in relation to specific physical hosts. This policy checks and enforces where a VM can be hosted when you power on or migrate the VM.
- VM-VM Anti-Affinity Policies: Ensure certain VMs are kept apart for availability or performance isolation. The VM-VM anti-affinity policy keeps the specified virtual machines apart in such a way that when a problem occurs with one host, you should not lose both the virtual machines.
This will be a two part post on Affinity and Anti-Affinity policies. This post will cover the background of when and where to use Affinity and Anti-Affinity policies with Nutanix AHV, and the second post will cover the configuration and validation of each scenario.
Affinity vs. Anti-Affinity: What's the Difference?
These policies allow you to strike a balance between performance, licensing control, and fault tolerance. Use them wisely, and they become a force multiplier for your availability strategy. Misuse them and you may unintentionally reduce your cluster’s flexibility or prevent VMs from powering on during constrained capacity situations.
| Policy Type | Description | Example Use Case |
|---|---|---|
| Affinity | Binds VMs to specific hosts | Limit Database Servers for licensing compliance |
| Anti-Affinity | Ensures VMs are separated across different hosts to avoid single points of failure | Separating domain controllers across hosts |
Real-World Use Cases for Affinity and Anti-Affinity Policies
Let's take a quick look at a few examples of real-world use cases for these policies.
Affinity Rule Examples (Keep VMs Bound to Specific Hosts)
| Scenario | Description |
|---|---|
| Licensing Enforcement | You have per-host licensed applications such as SQL Server or Oracle. To stay compliant, you can pin those VMs to specific licensed nodes using VM-Host Affinity rules. I won't get into the nuance of soft versus hard partitioning as it relates to licensing... |
| Performance Optimization | Application components that generate high east-west traffic, such a web tier and app tier, can be kept on the same host to minimize network latency. |
| Hardware Dependency | Some workloads (e.g., GPU-intensive VMs) require access to specialized hardware only present on specific hosts. Affinity ensures those VMs run where the hardware is available. |
| Dedicated Host Pools | For highly sensitive workloads (e.g., financial apps or regulated data), you may isolate VMs to a dedicated set of hosts to reduce risk and improve auditability. |
Anti-Affinity Rule Examples (Keep VMs Apart)
| Scenario | Description |
|---|---|
| Domain Controllers | To ensure Active Directory availability, configure domain controllers to run on separate hosts using VM-VM Anti-Affinity rules. If one host fails, AD services remain online. |
| Clustered Applications | For apps like Microsoft SQL Always On or clustered file servers, keeping nodes on different hosts improves resiliency and avoids simultaneous failures. |
| Firewall or Load Balancer Pairs | In N+1 HA deployments (like Cisco, Palo Alto, or Fortinet), separate the active/passive pair to ensure the secondary node isn’t taken down with the primary node. |
| Multi-Tenant Isolation | In environments with multiple tenants or departments, you might intentionally separate workloads across hosts to enforce isolation boundaries. |
Benefits and Pitfalls of Affinity Policies
Affinity policies in Nutanix AHV provide administrators with greater control over workload placement, but must be balanced carefully to avoid unintended constraints. When implemented thoughtfully, they enhance resiliency and performance—but overuse can limit flexibility and complicate cluster operations.
Benefits
- High Availability and Fault Domain Separation
- Performance Isolation for high-demand workloads
- Licensing Optimization by pinning licensed apps to licensed hosts
- Predictable Workload Placement
Pitfalls
- Reduced Flexibility: Can limit scheduler options and workload mobility
- Complexity at Scale: Managing many rules increases admin overhead
- Risk of Conflict: Misconfigured rules can prevent VMs from starting
- Overcommitment: Overly strict rules may strand resources
Applying the Policies
Nutanix has always provided a variety of ways to perform configuration, from GUI (Prism Element & Prism Central) to CLI (NCLI, ACLI, etc), and this consistency holds true for the application of Affinity and Anti-Affinity policies. In this post, I will not be covering the configuation and application of them, but will highlight where they can be built.
Prism Element, Prism Central & ACLI
For VM-Host Affinity policies, these can be configured using GUI or CLI methods. Prism Element, these policies are applied at the VM level, and must be done per VM. Prism Central enables the use of Categrories, so a much more flexibile and scal
For VM-VM Anti-Affinity policies, prior to the the AOS 7.0 and pc.2024.3 release, these policies were ACLI only. With the later releases, you can create category based VM-VM anti-affinity policies from Prism Central. VM-VM Anti-Affinity policies **are not **available directly within Prism Element.
Disaster Recovery Considerations
As covered, configuring Affinity and Anti-Affinity policies can be very helpful in ensuring compliance and elevating resiliency of an environment, but how do these policies stay with the VMs as they are failed over and failed back with Disaster Recovery actions. Short answer, sometimes they are, sometimes they aren't! When working across clusters, organizations need to understand how the application of these policies and migrating VMs between clusters has an impact on the policy outcomes. I'll briefly cover the different scenarios of both Affinity and Anti-Affinity policies, and how Prism Central (PC) based DR or Protection Domain (PD) based DR configurations impact these policies.
Affinity Polices with DR
PC-based DR
When using PC-based DR, Affinity policies need to be created on the recover site prior to the failover. This includes creating the host and vm specific categories with the same name as the primary site. It's important to note that if VM-Host affinity policies are defined using Prism element, the VMs never get the affinity after failover, and you need to manually redefine the affinity policies at the recovery site after failover. This is very important, and I recommend always creating the Affinity policies within PC.
Upon failback, the VM categories are synchronized back with the primary site, and the affinity policies created on the primary site (primary AZ) are enabled for the VMs. So, zero-touch on the failback.
PD-based DR
With PD-based DR, the outcomes are much different, and require manual intervention. During either failover or failback, the system clears all the VM-Host affinity policies defined using Prism Element, because PD-based replication is Prism Element specific only. The guest VMs can start using any host at the current (migrated) site. Basically, you lose any benefit of the Affinity policy, and would need to re-establish all Affinity rules set for VMs to hosts, with one exception. If all clusters are registered to one PC instance and the VM-Host affinity policies are defined using PC, the system periodically reconciles the affinity policies and enables you to have consistency in the affinity policies defined at the local site.
Anti-Affinity Policies with DR
PC-based DR
Anti-Affinity policies built using Prism Central categories operate very similar to Affinity polices created PC. The recommendation here is to pre-create all the Anti-Affinity policies ahead of time for those VMs that are protected via replication. After a failback is performed, the VM categories are synchronized back to the primary site, and the anti-affinity policies created on the primary site (primary AZ) are enabled for the VMs.
When using ACLI to create the Anti-Affinity policies, these policies are not replicated during failover, and you need to manually redefine the anti-affinity policies at the recovery site after failover. Notice that specific text, after the failover has occured. Otherwise, the target cluster is not aware of the VMs.
PD-based DR
Much like with Affinity policies, when you perform the failover or failback action, the system clears all the VM-VM anti-affinity policies defined using the CLI method or PC, again because the PD-based protection is locally significant only. The guest VMs can start using any host at the current (migrated) site.
Final Thoughts
This post aimed to take a deep dive into the use of Affinity and Anti-Affinity policies within Nutanix AHV—exploring what they are, when to use them, how they compare to vSphere, and the tools available for implementing them effectively.
In the next post, I will be walking throught the configuration and validation of Affinity and Anti-Affinity policies in a live environment, so stay tuned for that!
Infrastructure design is as much about intention as it is about technology. Affinity and Anti-Affinity rules in Nutanix AHV give the ability to control resilience, performance, and operational clarity.
Whether you’re aligning workloads for compliance, isolating critical systems for availability, or simply optimizing performance through intelligent placement, these policies help bring order to the chaos that can often define a growing virtual environment.
But like all powerful tools, they work best when used with care. Don’t over-architect. Start with your critical workloads, and document your rationale.
Smart policy. Smarter placement. Stronger outcomes.