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 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.
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.
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.
There are a number of permutations in behavior, which I’ll detail here.
If host property is blank
0 stars and blocking if VM property doesn’t match host property
No VMs will match. No VMs will be allowed to place.
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.
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.
Failover cluster behavior
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.
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.
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.
Availability sets can be created in three ways.
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.
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.
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.
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.
Great post...thanks for sharing!
Hi Hilton, thank you for the nice post. I wonder if any rules inside vmm would allow for folder placement rules, meaning, I wanted to make sure some VMs or disks ended up in certain folders in the CSV structure. I assume Storage Classifications could be used, but to leverage SMI-S providers is quite an effort and maybe not suited for that.
That's a good suggestion Jose. Right now there's no way to automatically manage the folder location of VMs. There are options (such as classification) to manage target volumes, but folder location is currently just a flat structure.