Update on VMM refreshers - what has changed and what this means to you

Good day, folks!

Since System Center 2012 SP1 Beta was released last week, we’re super excited to receive raving interests & feedback just over the past few days.


I’d like to briefly talk about one of the major investment areas in System Center 2012 SP1 Virtual Machine Manager - overall system scalability and performance, and what changes you can expect.


To enable your VMM environment to scale up to hundreds of hosts and thousands of VMs, and at the same time, to make our system and your admin console experience “snappy”, we’ve made some significant improvements in how VMM reacts to changes.

  • In the past (System Center 2012 RTM and prior versions), changes that are made outside of VMM (say, if you go to Hyper-V console and stop or start a VM) are discovered through a refresher model, which periodically queries and brings updates to the VMM server and then publish to the admin console.
    • This model implies that out of band changes will show up after a delay.
    • In some cases, it could take up to 30 minutes, before you see the new state of the VM appear in the admin console.
    • However, user can always manually trigger a refresher run against a certain object (VM or host) through our UI or cmdlets. For example, if you click on a VM in VMM console, your “clicking on the VM” action will trigger an on-demand refresh job for the VM object.
  • In SP1, we added eventing channel in our system for business critical events, which include
    • VM state change (start/stop/move,etc.),
    • Cluster node state change (add/remove/pause)
    • Hyper-V service state change.
  • The intent of this new eventing model is to allow critical changes to the system to be propagated up to our users in a much faster manner.
  • This new eventing channel works in concert with the periodic polling model. To take advantage of this new eventing feature, you will need either Windows Server 2012 edition host OS, or Windows Server 2008 R2 SP1 with this WMF 3.0 update. For systems without WMF 3.0, VMM will automatically fall back to the polling refresher model as what’s in System Center 2012.


At the same time, in order to increase our scale support and server performance, we’ve relaxed cadence for some refreshers. For definition and purpose of each refresher, check out this post. Below is a table to show what has changed:


Default Run Frequency


System Center 2012

System Center 2012 SP1

Host Refresher

30 minutes

30 minutes

No change, except change in Hyper-V service will be reflected immediately.

VM “Light” Refresher

2 minutes


This refresher is turned off for Hyper-V hosts that are capable of supporting WMI eventing.

For system that does not support eventing, we fall back to the System Center 2012 behavior (2 minutes refresher model). But the overall VMM scale support will also fall back to System Center 2012 RTM level.

VM “Full” Refresher

30 minutes

24 hours

Relaxed the cadence of this refresher. Users will need to trigger refresh action for VM property changes made outside of VMM, if you need to see those changes in VMM within 24 hours.

For system that does not support eventing, we fall back to the System Center 2012 behavior (30 minutes refresher model). But the overall VMM scale support will also fall back to System Center 2012 RTM level.

Storage “Light” Refresher


2 hours

Refresher reads information in cache instead of performing deep discovery of storage devices.


Note: There is no change in Cluster Refresher, Library Refresher, Perf Refresher, VirtualCenter Refresher, User Role Refresher, PRO Tip Refresher and Storage Full Refresher. Check this post for what they do and how frequent they run.


Now, what does this mean to you and what can you expect from this set of changes?

  • As always, we recommend and hope you perform most of your VM / host operations through VMM (admin console or PowerShell cmdlets).
    • If this is what you do, all changes should be reflected throughout the system immediately and you are not impacted by any of these SP1 changes. However, we hope that you will notice and enjoy the new “snappiness” of the system. :-)
    • If you need to manage VM / host outside of VMM and introduce changes to VMs/host properties, based on the scope of the change, you may need to decide how you want VMM admin console to react to that:
      • If the changes belong to one of those event-monitored changes, you should now be able to see the change updated in VMM system momentarily.
      • If the changes do not fall under those event buckets, you can either expect the changes to be reflected within 24 hours or trigger a refresh job (Read-SCVM or Read-SCVMHost) to pull in the updates on demand.



As always, I’d love to hear your feedback on our SP1 Beta release and hope this information is helpful.