During the vSphere 4.1 beta period, two of my clients were very interested in the new Host Affinity Rules for issues they were having.  The day vSphere 4.1 was released I had a call to discuss Host Affinity Rules with another client to explore issues they were having that host affinity rules could solve.  Each of these global enterprise clients are running 1000’s of VMs in production and each have different uses for Host Affinity Rules that the average user may overlook.

I was planning on providing a quick overview of the Host Affinity Rules in this post, but Frank Denneman already provided a great overview that I can’t really improve on.  Start with his post to to understand the basics of the new Host Affinity Rules.

A few Host Affinity Rule use cases:

• Physical server based software licensing:  As hard as it is to believe, some software vendors still tie their software to physical computers.  Using Host Affinity rules allow you to purchase licenses for a subset of your physical servers in your vSphere cluster. (typically 2 so you have HA).  By forcing the VMs running the software in question to run on specific servers, you can ensure compliance with the software licensing.
• Isolation for troublesome VMs: as with most troubleshooting processes, the newest thing in an environment usually gets the blame.  For one of my clients this means that new workloads moved into the vSphere environment that have performance issues result in the application owners blaming vSphere for the performance issues.  Even after using something like vCenter AppSpeed to show the user where the performance problem exists in their application, app owners still won’t believe it until their VM is running by itself.  With Host Affinity Rules, you can force the problem-some VM to run on a server that has nothing else on it.  (Take that non-believer app owner!)
• Another approach to host pinning and reservations:  Some clients use pinning and reservations to help ensure certain levels of performance for some of their end users.  Like any over-riding control, you can eventually end up with more of these rules than can be realistically managed.  Host Affinity rules could be used in their place by forcing a more large grained control.  Of course, the same rule sprawl can occur with host affinity rules.  So it’s best to use them sparingly at first and really make sure the end users really need them before using them.  After all, cloud computing is supposed to make things easier for both end users and IT administrators…fight the gravitational pull of end user special needs.  More often than not these needs don’t really exist.