The memory optimization mechanism that was added in Windows Server 2008 R2 Service Pack 1 Hyper-V, Dynamic Memory (DM), improves with WS2012.
Windows 8/WS2012 are doing some really clever things; you might have heard of MinWin. That was an effort by Microsoft to reduce the footprint of Windows 8. The primary beneficiary was Windows On ARM (WOA) where tablets may have lesser resources than a normal PC. A second beneficiary is virtualisation; memory is a bottleneck in dense virtualisation, such as VDI or VM hosting, and being able to squeeze down the run-size of Windows 8 so we can squeeze even more running Windows 8 VMs onto a host. That means that Windows 8 can actually use less than 512 MB RAM that is listed as a system requirement. In fact, when idle, it can drop well below 512 MB RAM. In the lab at work, I’ve observed Windows Server 2012 VMs with requiring as little as 312 MB RAM without being manually squeezed.
But there’s a catch: Windows boot requires 512 MB RAM. If we set Startup Memory to 512 MB then how could we get those savings if we couldn’t balloon down?
A “new” feature of DM is Minimum Memory. I say “new” because it actually existed under the covers in W2008 R2 SP1 but Microsoft really didn’t want us to use it. And that’s why the majority of us never knew it was there. Minimum Memory allows you to specify an amount of memory, which is smaller than Startup Memory, and allows an idle VM to balloon down to at least the Minimum Memory amount if there is unused memory in the VM. For example, a VM would start with 512 MB RAM. Once it is booted, and the integration components are started, if the VM is idle, it might balloon down from 512 MB to whatever it requires plus the buffer (20% by default).
Using Minimum Memory, we can allow idle VMs to throttle back their memory consumption to below their Startup Memory requirement. In a small farm, this might never happen. But in a large farm, such as VDI, hosting, or in a large private cloud, there very well may be many VMs that do little 90% of the time. Their freed up RAM can be used to service the needs of other VMs that do need the memory or to increase VM density on a host.
Let’s get this clear before the FUD starts and the VMware fanboys wet themselves: Hyper-V does not do second level paging (like VMware does because it overcommits memory) for VMs. Second level paging is considered inefficient because no hypervisor can have no vision into a VMs memory use and prioritise/page it effectively.
But … there is a situation where Hyper-V could do with a little bit more memory. Let’s consider those idle VMs that have ballooned down to their minimum memory. What if we had a host with a LOT of RAM, and we patched/rebooted a large percentage of VDI VMs, maybe even all of them. We’d go from a situation where we had lots of VMs using their Minimum Memory to a lot of VMs using their Startup Memory. What if we had to reset a lot of those VMs? Or what if we rebooted a host and the VMs set to auto-start required their Startup Memory and it wasn’t available?
There are very rare occasions where Hyper-V will need to provide more memory than is available. How rare will these occasions be? Very: if a host is running happily along with VMs idled down to their Minimum Memory, and they only reason they need more than that is to start up, then you actually have a pretty healthy host with a very brief requirement for more memory. In the real world, things like Failover Clustering, VMM Dynamic Optimization, VMM/OpsMgr PRO, and Live Migration will mitigate this squeeze on memory by moving running VMs. But Hyper-V must do something for those rare occasions where a normally non-contended host temporarily requires memory to service boot up for those otherwise idle VMs.
That’s where Smart Paging comes in. Smart Paging is engaged in one of these, and only one of these scenarios if there is not enough host memory for a VM to meet its Startup Memory requirement:
- A host reboot
- A VM reboot
- A VM reset
A Smart Paging file is created (by default) in each VMs’ storage location. This paging file will temporarily provide additional memory to the VMs. I stress “temporarily” because you will get alert if a VM is still using the Smart Paging file after 30 minutes. Eventually each previously idle VM will balloon back down below their Startup Memory and alleviate the temporary pressure.
If you’ve read my Dynamic Memory paper or heard me speak on the topic then you know that I’ve advised you to consider the amount of available physical memory when sizing VM storage because of the need for varying sized BIN files. This could be complicated by having many CSVs in a cluster and require some conservative estimates.
We are seeing some changes with the BIN file. You will only need to reserve disk space now if your VMs are set to automatically save their state during a clean host shutdown. This save state action is exactly why the BIN file was required. No auto-save state, no need for BIN file.
Another thing you should know about after hearing me speak or reading my guide is MemoryReserve. This is the automatically calculated setting that conserves memory for the parent partition so it has enough resources for its own operations, e.g. doing a backup of VMs, monitoring, AV scans, servicing administrator logons, etc. In Windows Server 2012, Microsoft has changed this automatic calculation so that more memory is reserved for the parent partition, thus better enabling management components to work more effectively with less memory pressure caused by expanding VMs. I don’t know the details of the algorithm, and I’m still in favour of manually configuring this setting to something that I know, control, and can change if required (registry or custom GPO).
3 thoughts on “Windows Server 2012 Hyper-V Dynamic Memory Changes”
Do these new memory management filter their way down to Windows Workstation 8 Hyper-V or are they Server only?
Thanks Matt, it looks to me like they do.
Really interesting paper about the dynamic memory, it’s very useful.