I was in a meeting last week with Engineering and a question had come up on whether customers were actively using the Anti-Affinity (AA) VM-Host Rules capability and if so, what are some of the use cases? We know that Anti-Affinity VM-VM Rules are used quite regularly by customers and the use cases are pretty well understood, but what is not clear was the usage and frequency of AA VM-Host rules. I figured I could help Engineering by asking some of my Twitter folllowers, the following question:
Anyone using Anti-Affiity VM-Host Rules today (e.g. VMs should/must not run on specific ESXi hosts)? Had a chat w/Engr the other day, they were curious if customers used this at all compared to Affinity VM-Host Rules & what the use case might be? pic.twitter.com/7EASBAvvt5
— William Lam (@lamw.bsky.social | @*protected email*) (@lamw) June 21, 2018
In an attempt to avoid any confusion, I also included a screenshot of the AA VM-Host Rules in the vSphere UI which you can see above. However, it looks like my attempt had failed and I actually received a number of replies that described AA VM-VM Host Rules (separate certain groups of VMs from each other, regardless of host groups), rather than AA VM-Host Rules (do not run certain groups of VMs on specific host groups). Perhaps the question could have been better phrased or it was just a simple misinterpretation, but overall it was a very useful exercise and it was great learn about all the different use cases for BOTH AA VM-VM and AA VM-Host Rules, so thank you to everyone who shared their feedback.
Just like Engineering, I am sure others would like to know how AA VM-Host Rules are used by other, so I have aggregated all use cases related to AA VM-Host Rules into a single Twitter Moment (never knew what this was until last week) which folks can access by visiting: Anti-Affinity VM-Host Rules Usage
Here are the common use cases from looking at the feedback:
- Licensing
- Non-uniform hardware capabilities (CPU core/sockets, GPUs, etc)
- Stretched/Metro Clustering
- Inconsistency of software configuration generally related to networking or storage
There were actually a few folks who had great point that you can use AA VM-Host rules to easily describe an Affinity VM-Host scenario. Take this example by Darryl Irvine:
This. 👍 Easier to say don’t run on 2 hosts rather than must run on 20.
— Darryl Irvine (@worm_za) June 21, 2018
Again, I want to thank everyone who participated and shared their perspectives, this was not only helpful to Engineer but I think it also helped others (received a number of private messages saying that this helped validate their use or that folks learned about new methods on solving the exact same set of problems). I am sure there are more valid use cases, feel free to leave a comment or better yet, reply back to the original tweet and I can include it in the Twitter Moment for others to benefit from.
common use case is when one or more hosts has a potential issue, don't have a quick resolution, and want to make sure key vms don't run on those hosts.
I did exactly that today because I have one VM that occasionally loses network connectivity but only on a specific host. I'll dig into it more when I have time, but for now it keeps the users from having to reboot it twice a day...
VSAN storage only nodes
Didn't catch the twitter post, but one use case would be to retain vcpu hot-add support without escaping NUMA boundaries on differently sized hosts. IE, the VM with 12 vCPUs should NOT run on the hosts where the NUMA-Node is 10, but any host that's larger than that is fine.
As others stated though, anti-affinity or host-affinity are both flexible enough to be used either way.Combining with VM-VM AA or Affinity rules you can get really granular policy based VM placement to achieve whatever business restrictions you need.
Maybe not 100% relevant but we are looking at aa-vm-cluster. Don't run in same cluster, but not possible with regular affinity so solution is to leverage storage profiles.
If you're having further talks with engineering about this, please ask them to look into adding dynamic groups to the gui. So you can have groups built from tags, names, or other properties. We would love being able to set group DC1 as consisting of all hosts tagged with "Datacenter1" or group Oracle consisting of all hosts tagged with "oraclehost". Today we solve this by running a scheduled powercli script once a day, but it would be smoother to have this right in vCenter. I expect quite a lot of use cases would benefit from dynamic rather than static groups.