by
Etienne Liebetrau
Running resource intensive applications on a virtual machine is a great way to ensure they do not consume more compute resource than is necessary, and the same physical machine can be used to run multiple discrete workloads.
A great example of this is generating reports in TMG Reporter, Sophos Reporter or WebSpy Vantage. The reporting process will increase the virtual machine's RAM and CPU requirements, but once the reporting workload is complete, the actual requirement drops back down again.
The two major hypervisors (VMWare and Hyper-V) have different ways of dynamically allocating more or less physical RAM to the virtual machines running on top of them. Microsoft Hyper-V’s approach is to let the virtual machine and hypervisor communicate with each other, so that the RAM can be continually adjusted based on the virtual machine’s requirements.
This means that from the virtual machine's perspective, it will have different amounts of RAM depending on the workload. This article will focus on how this dynamic process affects what you see from the both the hypervisor and virtual machine's perspective.
When editing the virtual machine’s hardware configuration, you specify the Startup RAM, and you also have the option of enabling Dynamic Memory. When this is selected you have the option to specify three additional fields.
This is the amount of physical RAM that will be allocated to the virtual machines at startup. Regardless of what the actual RAM demand is, the host will reserve this for the virtual machine.
From the virtual machine's perspective, the amount of visible RAM will never drop below the Startup RAM amount.
As the name implies, Minimum RAM is the minimum amount of physical RAM that the host will reserve for the virtual machine. Once the virtual machine notifies the host that its RAM requirement has decreased, it will start reducing the amount of physical RAM that is allocated, but never below this amount.
From the virtual machine's perspective, it will still see the Startup RAM amount.
Maximum RAM is the maximum amount of physical RAM that the host will allocate to the virtual machine, regardless of what the load is. Even if the virtual machine wants more, the host will never allocate any more RAM than this amount.
From the virtual machine's perspective, the visible amount of RAM will start increasing as the demand grows, but it will never exceed this amount. It is also important to note that the visible amount of RAM to the virtual machine will never drop below the highest amount allocated. In other words, the virtual machine will always see the 'high water mark' of RAM allocated to it.
The Memory buffer allows for instant RAM should the virtual machine need it. This 'excess' RAM is available before additional RAM is allocated by the host to the virtual machine. The Memory buffer is relative to the current RAM allocation.
For example, if the current RAM allocation is 10 GB, a 20% buffer will keep 2GB of 'instant' RAM free. If the current RAM allocation is 5GB, only 1GB will be kept free. For more information, see the MSDN article What is the memory buffer when dynamic memory is enabled.
Note: These Dynamic Memory fields can be changed while a virtual machine is running. Minimum RAM can be decreased, Maximum RAM can be increased and the Memory buffer can be either increased or decreased. The virtual machine will become of aware of the new limits without needing a restart.
Dynamic Memory introduces variable amounts of RAM allocation on both the host and the virtual machines. So lets first take a look at how the RAM allocation looks from the hypervisor's perspective.
SCVMM gives the most complete view of the Dynamic RAM picture.
In this image, you can see there are varying amounts of assigned RAM to the three virtual machines.
The SCVMM view is great because it is complete and provides you with the total picture. It does however lag a little behind. The best place for more 'live statistics' are in the Hyper-V Management Console.
The Hyper-V Management Console provides a simple and convenient real time view of the RAM assignment. It does not however give you the memory demand information. As such, is it not a great tool to determine the minimum baseline for your virtual machines.
By using Performance Monitor (Perfmon) on the host itself, you can get a very detailed live view of the Dynamic Memory picture. The key counters to use are:
Hyper-V Dynamic Memory Balancer
The Hyper-V Dynamic Memory Balancer counter gives you a view of how the host is doing from a memory perspective. In the image below, the host still has 66GB of RAM available to allocate based on demand. The current demand or 'pressure' from the virtual machines is 65. When the pressure gets to 100, the host is essentially out of RAM.
Hyper-V Dynamic Memory VM
The Dynamic Memory VM counter gives you a view very similar to what we have seen from the SCVMM and Hyper-V Management consoles.
One counter that is very useful here is the Guest Visible Physical Memory. This indicates how much RAM the virtual machine has visible, and it also indicates the high water mark for RAM demand. Perfmon also gives us the advantage of being able to track the RAM allocation on a graph.
In a Dynamic Memory scenario, the virtual machine will be in one of three states.
At startup, the virtual machine looks and behaves like a physical server with the Startup amount of RAM installed. The memory usage graph looks normal and from the Hyper-V console we can see that 4GB of RAM has been allocated.
A few minutes after the machine started, we notice a spike in the RAM usage. What has actually happened is not that the RAM usage has gone up, but that Dynamic Memory has started reducing the amount of physical RAM allocated to the machine. Since the virtual machine will never report less than the startup amount of RAM, it still reflects the 4GB.
You will notice however that usage is only at 70%. This is because of the memory buffer, if we increase or decrease the buffer size it will impact this percentage.
To simulate a sudden RAM increase, I am using a utility from Sysinternals called testlimit. When I demand an additional 2GB of RAM, the graph jumps. It then appears to level out even though the additional demand is still present. This is because more RAM has been allocated by the host.
When the additional 2GB demand is removed again, the graph drops.
Once the pressure normalises, the virtual machines goes back to only consuming the usual 2GB of physical RAM.
When I demand an additional 4GB of RAM above the baseline, it exceeds the Startup RAM. The virtual machine is then allocated additional physical memory from the host. At this point the installed memory count also goes up.
Note that even after the load has been removed and Dynamic Memory has released, the physical memory and the installed memory still reports 6GB. As covered earlier, the visible amount of RAM will never drop below the highest allocated amount.
Below is a 20 second interval Perfmon graph showing a trace of both physical memory and pressure from the host's perspective.
You can see that when the pressure is raised, the RAM amount increases almost immediately. Once the RAM is allocated, the pressure drops a little. When the load is removed, the pressure goes way down, and when the pressure stays low for a few minutes, the RAM allocation drops. At this time, the pressure goes back to the standard count of about 60.
This still leaves the question of how much memory is actually allocated and used? For this information, you can use another tool from Sysinternals called RAMMap.
In RAMMap, the counter to look for is called Driver Locked. At startup there is basically no RAM locked. Once Dynamic Memory steps in and releases the physical RAM, you can see the Driver Locked amount increases. At this stage the Total still stays the same.
When we bump the load up again, the Total increases. Once we terminate the process, the RAM moves to being unused.
When Dynamic Memory releases the physical RAM, the unused amount is now moved to Driver Locked.
It is important to remember that the Driver Locked amount is an artificial lock on RAM that does not really exist for the virtual machine since it is not backed by any physical RAM from the host.
Making use of Dynamic RAM in Hyper-V is a great way to maximise the hardware you have available. Having a proper understanding of what the actual demands of your virtual machines are can help you tailor its RAM settings.
Realistic figures should be used when specifying the Startup and Minimum RAM amounts. If these are too low you will inevitably invoke the dynamic addition and removal of RAM all the time. Although this is not a problem, it does carry some overhead.
When looking at memory utilisation on the virtual machine it is important to remember the context in which it exists, just because it indicates a high percentage of RAM utilisation, does not mean it is consuming that amount of physical RAM.
Download our FREE 30-day trial, or schedule a demo and we'll show you how it works.
Understanding Hyper-V CPU Usage (Physical and Virtual)
How to Enable Dark Mode in Fortinet FortiGate (FortiOS 7.0)