none
Setting anti-affinity and affinity in Hyper-V 2012 or SCVMM2012 RRS feed

  • Question

  • I am searching for a method to avoid having multiple virtual machines part of a cluster running on the same Windows Server 2012 Hyper-V server managed by SCVMM 2012. 

    What is the way to do this? The feature is named anti-affinity. I did not find much info on this. In Hyper-V this was done by the cluster using cluster.exe 

    In Hyper-V Windows Server 2012 cluster.exe is not available anymore and replaced by PowerShell.

    I also read something about using custom properties in SCVMM2012 and using Placement Rules.This does not work for me in SCVMM 2012 CTP2.

    I also like to know if it is possible to keep two VM's together on the same Hyper-V host (affinity). And also if there is a way to keep virtual machines running on a subset of cluster nodes. So if the cluster has 10 servers, the VM should only run in node 1 and 2 (for Oracle licensing purposes for example) 

    Thanks!


    Monday, June 25, 2012 10:29 AM

Answers

  • Hi Marcel

    All of these scenarios can be addressed to an extent using features in Hyper-V, Failover clustering and SCVMM at the moment.

    Antiaffinity is still set up through the cluster directly. You can set 2 VMs to have the same AntiAffinityClassName property, and failover cluster manager will ensure that they never start on the same host.

    Keeping virtual machines running on a subset of cluster nodes is also achievable directly in failover cluster manager - you can directly manage the list of possible owner nodes for each VM, they won't even start up if they're placed on another node.

    VM-VM affinity is a trickier case, but can still be accomplished. If you mark VMs in SCVMM as "Exclude from Dynamic Optimization", they will remain on the node on which they're placed.  As long as you deploy these VMs to the same host, they will remain sharing a host unless you manually migrate them. Additionally, you can go directly onto Hyper-V and enable failback, so if there is a node failure, the VMs will automatically move back to their original host.

    Custom placement rules can allow you to achieve some of these scenarios while still having Dynamic Optimization running. The most simple way to get started with Custom Placement Rules is this:

    1. On the parent host group, find the Custom Placement Rules properties. Add a new rule to the property "Custom 1", with the rule "Must not match".
    2. On all of your Oracle VMs, set the property "Custom 1" to "NoOracle"
    3. On all of the hosts you don't want that VM to run on, set the property "Custom 1" to "NoOracle".

    Trying to migrate any of those VMs to the wrong host will now give an error, because the custom property had a "Must not match" rule on it.

    Additionally, I'm excited to tell you that more work is being done in providing a smoother experience around exactly these kinds of scenarios in the near future. Keep an eye on our updates soon.

    I hope this helps, feel free to ask further questions.

    Monday, June 25, 2012 5:47 PM

All replies

  • You can use the failover cluster manager but I do not think there is any way to actually set the vm-host affinity to just limit to a subset of the cluster-nodes..

    here is the cmdlets for the cluster management http://technet.microsoft.com/en-us/library/hh847239.aspx


    • Edited by vNiklasMVP Monday, June 25, 2012 11:55 AM
    Monday, June 25, 2012 10:48 AM
  • Hi Marcel

    All of these scenarios can be addressed to an extent using features in Hyper-V, Failover clustering and SCVMM at the moment.

    Antiaffinity is still set up through the cluster directly. You can set 2 VMs to have the same AntiAffinityClassName property, and failover cluster manager will ensure that they never start on the same host.

    Keeping virtual machines running on a subset of cluster nodes is also achievable directly in failover cluster manager - you can directly manage the list of possible owner nodes for each VM, they won't even start up if they're placed on another node.

    VM-VM affinity is a trickier case, but can still be accomplished. If you mark VMs in SCVMM as "Exclude from Dynamic Optimization", they will remain on the node on which they're placed.  As long as you deploy these VMs to the same host, they will remain sharing a host unless you manually migrate them. Additionally, you can go directly onto Hyper-V and enable failback, so if there is a node failure, the VMs will automatically move back to their original host.

    Custom placement rules can allow you to achieve some of these scenarios while still having Dynamic Optimization running. The most simple way to get started with Custom Placement Rules is this:

    1. On the parent host group, find the Custom Placement Rules properties. Add a new rule to the property "Custom 1", with the rule "Must not match".
    2. On all of your Oracle VMs, set the property "Custom 1" to "NoOracle"
    3. On all of the hosts you don't want that VM to run on, set the property "Custom 1" to "NoOracle".

    Trying to migrate any of those VMs to the wrong host will now give an error, because the custom property had a "Must not match" rule on it.

    Additionally, I'm excited to tell you that more work is being done in providing a smoother experience around exactly these kinds of scenarios in the near future. Keep an eye on our updates soon.

    I hope this helps, feel free to ask further questions.

    Monday, June 25, 2012 5:47 PM
  • Hi Hilton,

    Thanks for the reply! It sure helps me and I believe a lot of others. Did not find much info on the subject.I am going to try this.

    Looking forward to a more easier/smoother way to configure affinity and anti-affinity.

    Monday, June 25, 2012 7:23 PM
  • I've done a lot of thinking around VM affinity. It is something I see requested occasionally, but I don't have a great understanding of why people need it, and if that can be accomplished using other methods.

    The problem with affinity is this: There are a ton of operations and scenarios which are affected by it, and it makes them all substantially less likely to fail.  Want to migrate a VM? Now you have to consider the entire group of affined VMs as a single unit. A single one of them fails to start, to you fail them all back to the source host? During failover, if they can't all be failed over the same host, do you prevent them from starting up? If Dynamic Optimization is managing your cluster, how can it load balance without breaking the affinity group?

    Small units of load (VMs) are flexible in all the above operations, but once they need to stay on the same host, management operations will be far less likely to succeed without potentially breaking the affinity.

    I'd be interested to hear both your requirements and thoughts on these issues.

    Hilton

    Monday, June 25, 2012 7:32 PM
  • I believe VM-VM affinity does not have many use cases.. It's purpose would be to keep two or more virtual machines on the same host. Thus they can communicate with eachother on the highest speed without network traffic leaving the Hyper-V host. While this sounds nice, in practise I believe there will always be traffic for these virtual machines which needs to go outside (clients for example). Also with current network speeds the advantage of internal network traffic will not be much.

    As you describe affinity makes migration and placement a  bit more complex.

    Obviously for anti-affinity there are many use cases. In a lesser extent to a feature which makes sure VM's are running on a subset of hosts (host affinity). Oracle licensing is an example for that.

    If Vm-VM affinity is set I would not prevent the vm's to start up if resources to start BOTH are not available. Prefer to start separated on two hosts.

    Affinity and anti-affintiy are in Hyper-V R2 so hidden that hardly anybody know about it. It is a typical enterprise feature used by admins who know their stuff.

    Hope this feature comes available in VMM2012 in an obvious place of the UI.

    Monday, June 25, 2012 8:38 PM
  • Sorry for dragging this out of the dark, but as I am looking into this myself and there is not a lot of information out there.

    What would have been good in the context of using VMM, would be that the cluster settings for preferred owners, and failover policy could be surfaced through VMM.
    Even going to the length of enabling policies through VMM that trigger on different customization criteria.
    i.e virtual clustered SQL servers can only run on specific optimized hosts, and that nodes in the same virtual cluster are not able to run on the same physical hyper-v host  

    :) Wishing it so  

     

    Wednesday, October 10, 2012 2:56 PM
  • What would have been good in the context of using VMM, would be that the cluster settings for preferred owners, and failover policy could be surfaced through VMM.

    In that case, I have good news for you.  VMM 2012 SP1 allows you to control preferred owners, possible owners and availability sets (AntiAffinityClassNames) all directly through VMM!
    Wednesday, October 10, 2012 4:27 PM
  • Nice, thanks for the update. 

    Hope the future will bring policy based targeting of these types of configuration so one can optimize based on performance from applications over multiple servers. Also this would open the door for dynamic scaling of the application based on collected performance data (do I hear a use for pro tips through OpsMgr again?)

    Cheers!

    Thursday, October 11, 2012 8:12 AM
  • Hello Hilton, 

    Since you answered this thread, and if you're still available (or can forward this to whoever can answer this), could someone provide a link or explain the difference between preferred owner in a host cluster, and anti-affinity?   They seem to do the same thing.

    I have a 2 node host cluster built in my lab on R2 test machines, and a 2 VM guest cluster built on R2, and VMM2012 R2 Preview installed.  Currently I merely went to the properties of each VM and set the preferred owner so each VM should stay on it's assigned host.  

    I guess it could get more complicated if I had a 4 node host cluster and wanted to automate the anti-affinity of the two clustered VM's, so I wouldn't have to "choose" preferred nodes for each VM.....

    Hopefully someone has written a blog to explain the difference in more detail.....

    Tuesday, July 9, 2013 1:21 PM
  • Hi Mike

    Good news - somebody HAS written a blog about this - me!

    http://blogs.technet.com/b/scvmm/archive/2013/03/11/custom-placement-rules-and-availability-sets-in-scvmm-2012-sp1.aspx

    To answer in brief:

    - Preferred owners are for when a VM has a specific host or set of hosts that they should remain on.

    - Antiaffinity (availability sets in VMM and Azure) are for when VMs should be kept on different hosts, but you have no preference as to what specific ones they should be.

    I hope this helps!

    Cheers, Hilton

    Tuesday, July 9, 2013 3:38 PM
  • This is the answer I was looking for. Availability sets are super easy to setup and does the job.

    Thanks!

    Tuesday, September 27, 2016 8:25 PM
  • We too wish that you could group Applications to a host. 

    The example we have for this, is we have over a dozen hosts and around 300 VM's which make up say 15 'Applications' 

    What happens is one node fails and since at least 1 VM from each application group is on the failed node the outage list is ALL APPS. 

    If we could say hey all these VM's are part of this application group, please put them close to each other (group them over 1 or 2 nodes) then when we have a node fail, we only lose 1-2 applications for a unplanned outage. 


    Wednesday, June 14, 2017 1:29 AM