Hi everyone, my name is Stephen Baron (VMM Program Manager) and I want to take a minute to tell you about a couple exciting new features in SCVMM 2012 – Dynamic Optimization and Power Optimization.
System Center Virtual Machine Manager (VMM) 2008 R2 leveraged the Performance and Resource Optimization (PRO) feature along with System Center Operations Manager integration in order to recommend virtual machine migration when resource usage - such as CPU or memory - on a host exceeded a specific threshold. Subsequent PRO remediation actions could migrate the virtual machine which had the highest resource usage on the host to the most suitable host in the same host group or host cluster by using automatic placement in VMM. These PRO tips for hosts could be implemented automatically or manually.
In VMM 2012, we’ve introduced a new feature called Dynamic Optimization (DO) which enables built-in support for optimizing host clusters. DO is built into the SCVMM 2012 product itself and does not rely on PRO or Operations Manager integration. What’s more, we’ve also built support for Power Optimization (PO), whereby VMM can automatically power down and power on cluster nodes based on user configurable settings and a user-defined schedule.
While reading through this post, do keep in mind that our Dynamic Optimization and Power Optimization features work across all of our supported hypervisors – Hyper-V, VMware and Citrix XenServer!
Dynamic Optimization and Power Optimization Configuration
VMM 2008 R2 had the notion of Host Reserves, whereby users could set aside resources for the host operating system on hosts. Our Intelligent Placement feature enforced the host reserves by ensuring virtual machine creation or migration did not violate the user-specified levels:
With VMM 2012, we’ve kept the Host Reserve feature and augmented it by providing two new levels of configuration: Dynamic Optimization levels and Power Optimization levels. As with Host Reserves, thresholds can be set for CPU, Memory, Disk I/O and Network I/O. While we’ve provided sensible defaults, all of these settings are user-configurable so you can specify how DO and PO must operate in your various environments. What’s more, you can configure these levels on a per-host group level to enable different DO and PO behavior in your varied environments (production and pre-production, for example).
We’ve also enabled fine grained control over DO behavior. In addition to resource threshold levels, you can specify:
- How aggressive DO should be when optimizing host clusters - Whether or not DO should run automatically - The interval at which DO should run - Whether or not PO should be enabled - The schedule within which PO should operate
For example, in my Seattle Pre-Production Host Group, I’ve specified that DO should use the default (medium) aggressiveness when calculating potential optimizations, that it should run every 10 minutes and that it should automatically migrate virtual machines to optimize the host clusters within this Host Group.
I’ve also gone ahead and enabled Power Optimization and set a schedule during which VMM may consolidate workloads and power off unused cluster nodes. At the end of a PO window, VMM will automatically power on the unused cluster nodes and DO will automatically re-balance any running workloads. Of course, should a spike in activity occur during a PO window, VMM will power on cluster nodes as necessary. In my Seattle Pre-Production Host Group, I’ve specified that Power Optimization should occur between midnight and 7:00am:
Finally, hosts can be subject to Power Optimization only if they have been configured to support OOB power management:
Dynamic Optimization Example
Let’s take the case of CPU as a basic example (please do, however, keep in mind that DO works across multiple resource dimensions such as Memory, Network I/O and Disk I/O, including Hyper-V Dynamic Memory enabled environments). By default, we have the following CPU levels defined:
Host Reserve Threshold – 10% Dynamic Optimization Threshold – 30% Power Optimization Threshold – 40%
When DO runs, it will actively try to migrate VMs off hosts which have exceeded the DO level (in this case, hosts which have less than 30% CPU available). The target host of the migration could be any host. It could even cause a host to rise above the DO level, as long as the new level is significantly better than was the old one. The amount of improvement required to trigger a migration is dictated by the aggressiveness setting.
Here are a couple of scenarios to consider:
· Host A running at 75% load migrates one or more virtual machine to Host B with 50% load. After the migration their loads are A: 65% and B: 60%. (Both healthy)
· Host A running at 90% load migrates one or more virtual machines to Host B with 65% load. After the migration their loads are A: 80% and B: 75%. (B has actually risen above the DO level, which is a valid operation given an aggressiveness setting of Medium.
Power Optimization Example
PO considers the theoretical effect of evacuating each host. If any host, or set of hosts can be powered off and all the target hosts would remain under the PO level, then VMM will consolidate workloads and power off the appropriate hosts.
Continuing with our default levels from above:
· Host A running with 20% CPU load evacuates to Host B which is currently running 30% CPU load. After the evacuation, host B is at 50% (meaning it has over 40% available CPU resources) and A is powered off.
· Same as above, but host C is running at 65% CPU load. DO does nothing (because the DO threshold of 30% has not been violated). PO notices that host A can evacuate to host B and keep it below 60%. It does so. C has no bearing on that evacuation and A is powered off.
Manually Running Dynamic Optimization
So you’re interested in taking advantage of DO, but you’re not quite ready to have your clusters automatically optimized. No problem, simply use our defaults or configure your DO settings (resource threshold levels and aggressiveness) to meet your requirements and manually execute an optimization of a host cluster. Simply right click the cluster and select the “Optimize Hosts” option:
DO will generate an Action Plan and you can then decide whether or not to have VMM implement the resulting migrations:
So you’re taking advantage of DO and PO to optimize your virtualized environment and dynamically respond to changes in resource usage. You want to inform management as to the resulting power savings you’re seeing throughout the data center. Great idea! By leveraging our System Center Operations Manager integration, we’ll be providing Power Savings reports to enable this exact scenario. You specify a date range and host group and we’ll generate a report of the total compute hours saved as well as detailed information for each host in the host group.
We hope you agree that our new Dynamic Optimization and Power Optimization features are valuable and that we are going a long way toward helping you realize the benefits of a Dynamic Datacenter. Please feel free to submit feedback through the Connect site and ask questions on the VMM forums. Also, make sure to visit the VMM 2012 TechNet Library!
Stephen Baron | VMM Program Manager
The App-V Team blog: http://blogs.technet.com/appv/ The WSUS Support Team blog: http://blogs.technet.com/sus/ The SCMDM Support Team blog: http://blogs.technet.com/mdm/ The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/ The SCOM 2007 Support Team blog: http://blogs.technet.com/operationsmgr/ The SCVMM Team blog: http://blogs.technet.com/scvmm/ The MED-V Team blog: http://blogs.technet.com/medv/ The DPM Team blog: http://blogs.technet.com/dpm/ The OOB Support Team blog: http://blogs.technet.com/oob/ The Opalis Team blog: http://blogs.technet.com/opalis The Service Manager Team blog: http: http://blogs.technet.com/b/servicemanager The AVIcode Team blog: http: http://blogs.technet.com/b/avicode The System Center Essentials Team blog: http: http://blogs.technet.com/b/systemcenteressentials The Server App-V Team blog: http: http://blogs.technet.com/b/serverappv
Interesting indeed. What about a Pareto based approach? ... like in this paper: