I’m Hilton Lange, a Software Development Engineer on the VMM team. I want to conclude my series of placement blogs by talking about the custom rules that you can configure on your VMM server to give you more control over where your VMs are deployed.
In VMM 2012, we’ve given you some fairly broad tools to enable you to guide VMM’s placement decisions, while still leveraging the new Intelligent Placement engine to automatically manage and balance your environment. In VMM 2012 SP1 we’re adding even more ability for you to enhance a service’s availability by keeping specific sets of VMs on different hosts whenever possible.
Custom Properties
Custom properties form the basis for customizing placement. You’ll see our default ones, “Custom1” to “Custom10” on many VMM objects: Hosts, Host Groups, VMs, VM templates etc. We allow you to add your own properties (Cost Center, Owner, Division, Make/Model, whatever you want). After a new property has been created, you can associate it with any applicable VMM object, and that custom property will show up in the properties dialog for those objects in the admin console.
Using custom properties to create placement rules
If you create a new custom property such as “Cost Center”, and you apply that property to both VM and Host objects, you can configure VMM to ensure that the property is used to guide Intelligent Placement’s decisions. Let’s suppose that you only want VMs to be placed on hosts with a matching “Cost Center” value.
- Add the “Cost Center” custom property.
- Associate it with VMs, Hosts and VMTemplates.
- Fill in the Cost Center value for all hosts in a specific host group
- Fill in the Cost Center for all VMs in that host group
- Fill in the Cost Center for all VM Templates that may be deployed to that host group.
- In the host group properties, choose “Custom Placement Rules”. Add a new entry that “Cost Center” has a rule that it “Must Match”.
![image]( "image")
When you try to migrate any of your existing VMs, hosts cost centers values that don’t match the VM being placed will get 0 stars and a blocked deployment. When you create a new VM from a VMTemplate, only hosts with the same cost center as the VMTemplate will get positive star ratings.
Using the “Must not match” or “Should not match” rules will allow you to configure a specific VM or set of VMs which will not be placed on a specific set of hosts.
Custom placement rules - the full details
There are a number of permutations in behavior, which I’ll detail here.
Rule | Behavior | If host property is blank |
Must match | 0 stars and blocking if VM property doesn’t match host property | No VMs will match. No VMs will be allowed to place. |
Should match | Placement warning if VM property doesn’t match host property | No VMs will match. Host will always get a warning in placement. |
Must not match | 0 stars and blocking if VM property is identical to host property | No VMs will match. All VMs will place successfully. |
Should not match | Placement warning if VM property is identical to host property | No VMs will match. All VMs will place without warnings. |
Preferred and Possible Owner nodes
If your VMs are placed on a Hyper-V cluster, VMM 2012 SP1 allows you fine-grained control over what hosts each VM should run on. In the VM properties you can set preferences for which cluster nodes each VM is allowed on (Possible Owners), and which nodes you would prefer each VM to be on (Preferred Owners). During Dynamic Optimization, patching or cluster failover, your preferences will be taken into account and your specified target nodes will be preferred. The detailed behavior is shown below.
Rule | VMM behavior | Failover cluster behavior |
Preferred owner | Preferred hosts will be selected first. Other hosts will show a warning in placement and appear at the bottom of the list of hosts. | During failover, cluster manager will try to start VM on preferred nodes, in order of preference. If no preferred owners are available, any host will be used. |
Possible owner | VM can only be migrated to possible owners. Other hosts will get 0 stars and a blocking error, preventing migration. | During failover, only possible owner nodes will be considered. VM will never fail to a host that is not a possible owner. |
Note: Preferred and possible owner nodes are configurable only for existing highly available VMs running on a Hyper-V cluster.
VMM Availability sets
In VMM 2012 SP1, we have added Availability Sets. Failover Cluster Manager users will be familiar with AntiAffinityClassNames, and Availability Sets are a very similar concept. We allow the user to specify a set of VMs which they would prefer to keep on separate hosts, and the Intelligent Placement engine works hard to make sure that all our features respect that preference.
- Attempting to place multiple VMs with the same Availability Set onto a single host will generate a placement warning, meaning that the host will be prioritized last in the placement dialog
- When placing a VM with an Availability Set into a cloud placement or as part of a service will avoid hosts with another VM from the same Availability Set, and warn the user if that was the only choice.
- Dynamic Optimization will never move 2 VMs from the same Availability Set onto the same host. It will also actively attempt to separate any VMs with the same Availability Set that are on the same host.
- Power Optimization will never power off a host that would lead to 2 VMs with the same Availability Set sharing a host.
- Putting a host in maintenance mode will attempt to spread VMs with the same availability set to different target hosts.
- If your VMs are highly available and hosted on a Hyper-V failover cluster, we create AntiAffinityClassNames on the VMs with an Availability Set, so that even during cluster failover, we opt to failover to different hosts, if possible.
Creating Availability Sets
Availability sets can be created in three ways.
Existing AntiAffinityClassNames in Failover Cluster Manager
After you upgrade to VMM 2012 SP1, all your VMs with AntiAffinityClassNames will automatically have the corresponding Availability Sets added by the VMM VM refresher, so that Intelligent Placement can be informed of the rule that FCM was already enforcing.
Manually adding Availability Sets to new or existing VMs
In a VM’s properties, look at Hardware Configuration, under “Availability”. A button and dialog have been added there to create Availability Sets per-VM. A list of previously used Availability Sets is presented to you to make it simple to add multiple VMs into the same Availability Set.
Automatically applying an Availability Set to a Service Tier
You can choose for VMM to automatically create an Availability Set for a specific tier in a service. In the service designer, just check the “Enable Availability Set” checkbox for each tier you would like to have this feature. During service deployment, every VM in that tier will get put into an Availability Set, and Intelligent Placement will place each VM from that tier on a different host, whenever possible.
Conclusion
Availability Sets are configurable on all hypervisors, and on both HA and non-HA VMs. Intelligent Placement will attempt to keep the Availability Set spread between hosts in all of its various functions throughout VMM. On Hyper-V clusters you have the added feature that the hypervisor is given the Availability Set name for HA VMs, so it can attempt to keep them apart during failover.
I hope you’ve enjoyed learning more about Intelligent Placement’s features in VMM 2012, as well as the new features added in SP1. If there are any other aspects of VMM’s placement behavior that you are interested in hearing more in depth about, please leave feedback here.