We can put a man on the moon and we can hot migrate virtual machines with SMP and gigs of RAM, but we can’t create anti-affinity rules with three or more VMs. This has been a thorn in my side since 2006, long before I requested it fixed in February 2007 on the VMTN Product and Feature Suggestions forum.
VMware updated KB article 1006473 on 3/26 outlining anti-affinity rule behavior when using three or more VMs:
“This is expected behavior, as anti affinity rules can be set only for 2 virtual machines.
When a third virtual machine is added any rule becomes disabled (with 2.0.2 or earlier).
There has been a slight change in behavior with VirtualCenter 2.5, wherein input validation occurs, where a third virtual machine added produces a warning message indicating a maximum of two virtual machines only can be added to this rule.
To workaround this, create more rules to cover all of the combinations of virtual machines.
For example, create rules for (VM1 & VM2), then (VM2 & VM3), and (VM1 & VM3).”
That last sentence is what has been burning my cookies for the longest time. In my last environment, I had several NLB VMs which could not be on the same host for load balancing and redundancy purposes. Rather than create a minimum amount of rules to intelligently handle all of the VMs, I was left with no choice but to create several rules for each potentially deadly combination.
Work harder, not smarter. Come on VMware.
Yep; pain in the rear; encountered in the environment I used to support as well; where we had many web servers load balanced behind F5 attached VLANs across and had to create rules for all combination’s; perhaps this is fixed in the upcoming vSphere?? I have not seen the beta yet to confirm….
Totally agree, why hasn’t it been fixed despite numerous upgrades and patches.
BTW the formula for calculating how many affinity rules you require is {n(n-1)/2}, where n is the number of vm’s in the rule.
e.g a rule to seperate 10 vm’s would require 45 seperate rules.
One client of mine had a cluster of 26 citrix vm’s that he wanted in an anti-affinity rule (yes we have more than 26 esx hosts), didn’t end up doing it.
I hope it’s adjusted in the next revision… we ended up splitting our load balanced front end VM’s across multiple clusters (odds in 1; evens in another); still had to setup plenty of anti-affinity rules though which is no fun 🙁