Hyper-V Dynamic Memory Allocation strikes again… I have decided to no longer use Dynamic Memory Allocation on any of my virtual machines. It is a fine idea in theory but it is extremely buggy and I am not sure how it made it into a production OS…

What’s the issue this time around? This is my third article talking about a bug related to Dynamic Memory Allocation. In this case it has to do with the clock sync on the VM. Which is a major ordeal if you happen to be working with a virtualized Domain Controller. Here was the situation… every time power got cut to the host and subsequently the VM was “hard powered” off, upon reboot the clock would be off by several hours.

Because it was a domain controller and all member systems were set to periodically sync their time to it, this resulted in a whole bunch of systems with the wrong time. This is more important than just the clock in the lower-right-hand corner of the desktop being wrong, in part because various protocols (for example, Kerberos) depend on an accurate clock… so the result is a whole bunch of users that can’t login to anything on the network. Yep, it’s a nightmare.

What was the cause of this issue? Well first, this was NOT the result of a time-sync loop. If you are facing time sync and clock issues with a virtualized domain controller you need to go read THAT ARTICLE first. It has nothing to do with black holes and Einstein’s theory of relativity… it rather has more to do with Hyper-V Integration Services… So, after making sure that time synchronization option was turned off in VM integration services list I moved on…

That is when I saw that Dynamic Memory Allocation was being used. What is Dynamic Memory Allocation? Briefly stated… rather than setting a “static” amount of ram (say 4 GB) for a Virtual Machine, you can set a dynamic “range” (say 1 to 4 GB) and then your VM will only use however much it needs. It’s an excellent idea that should allow you to make more efficient use of your hosts resources… That crazy developer that told you he really needed a Web Server with 16 GB of ram… yep, you can just set a range of 2 – 16 GB and more than likely he is never going to get past 5 or 6 GB of use… love the idea but it is very very buggy as I keep finding out.

So on a hunch I set a static amount of RAM for my virtualized domain controller and to my surprise my issues with the clock magically went away. I did a few graceful shutdowns and even forced the machine off several times just to be sure. The machine had the correct time every time it rebooted.

Long story short, avoid Dynamic Memory Allocation like the plague. At least on Server 2012. I haven’t tested this out on any of my Server 2012 R2 Hyper-V hosts so perhaps MS got it fixed, if they were even aware of it…

Somewhat like Azure, although to much less of an extent, Microsoft Hyper-V occasionally feels like one big “beta” test…

1 of 1

This post has no comments. Be the first to leave one!

Leave a Reply