3 Misconceptions About Right Sizing Your Virtual Machines

October 20th, 2015 by

In VMTurbo we are fortunate to be exposed to thousands of customers running thousands of different virtual environments. One of the very common ask we get is around right sizing environments. Let me say up front – right sizing is important. However, it might not be as important as you think. Furthermore, you might be able to achieve everything that you are looking for, without sizing a single VM 1 GB down across your entire data center.

So the question is – why do we want to right size our virtual machines? Typically, (1) because people want to get more out of their virtual infrastructure. No reason to give a VM 20 GB of memory if it only needs 1 GB. In addition, (2) sometimes allocating too many resources can cause performance issues (I completely agree with that one). The question is – when?

When you actually go forward with your right sizing initiative you typically find yourself in negotiations. Usually, the application owner thinks they need more. Maybe because they don’t understand virtualization. Many times, it’s because they look at different metrics than the virtualization admin. While one side looks at capacity, active and consumed memory, the other side gets its information from OS and application level metrics.

To summarize, typically one will approach right sizing Virtual Machines with these assumptions:

  1. Right sizing helps increase density
  2. Right sizing helps performance
  3. Right sizing can be achieved by analyzing hypervisor metrics

1. Does right sizing help increase density?


It doesn’t matter if you use VMTurbo, or any other tool in the universe. If you would like to size down resources for a VM, you want to take away resources that are not being used anyway. Otherwise, you will be directly impacting the performance of that VM. Hence, you want to take back non-utilized resources. If those resources are not used anyway, then how does that help?

Simple example, let’s say a host has 8 GB of memory. It hosts 5 VMs. Each one of these VMs has 4 GB of memory. Each one of these VMs is utilizing 25% of its memory (1 GB).
Overall impact on the host:

5 VM * 4 GB of Memory * 25% Utilization = 5 GB of memory utilized on the host level.
= 62.5% Memory Utilization on the host (5/8)

Now, let’s say we size down these VMs. As mentioned, before no reason to give 4 GB of memory to a VM using only 1 GB of memory. So let’s split it in half, to 2 GB of memory per VM. Of course the VM will still be using 1 GB of memory, but the utilization now is much more aligned with the capacity on 50%.
Overall impact on the host:

5 VM * 2 GB of Memory * 50% Utilization = (still) 5 GB of memory utilized on the host level.
= (still) 62.5% Memory Utilization on the host (5/8)


impact of down time

2. Does right sizing help performance?


The most obvious case where right sizing helps performance is when you size resources up due to increasing demand. However, for some reason when I’m approached with the initiative, rarely do I get this question (how can we know which VMs need more resources?). Usually, the exercise is around sizing down VMs.

VMTurbo not only recognizes when you need to give more resources (CPU or Memory for a VM for example), but it will also detect if a VM is configured with hot-add and will automatically give it the resources in real time as the demand increases.

action settings vmturbo

Ironically, this capability makes the sizing down “negotiations” a lot easier. Is taking away resources as painful, if as soon as you need them you get them back? Immediately, without making a phone call? (Of course we will avoid infinite sizing or sizing over an OS limits, etc.)

Right sizing can also solve queuing related performance problems. See more details here: https://turbonomic.com/blog/still-waiting-on-that-cpu-ready-queue-line/. Sizing VMs to the actual number of CPU they need can give them better performance in some environment.

However, going back to the example before. Taking away resources that are not used or waited on anyway will make no difference whatsoever. It will only change the over-provisioning ratios, which do not impact performance. Sometimes you use these as a threshold for capacity in your cluster. If so, you should consider more advanced and easier planning.

3. Can you right size based on Hypervisor metrics only?

No. (Well… you can, but it won’t be good 🙂 )

We’ve mentioned before a typical problem in the virtualized world is right sizing JVMs. Read all about it here. Typically to right size VMs you use Active Memory. In the case of JVMs, this might give you the wrong decisions. Using VMTurbo’s application control, you can understand the actual memory demand of a JVM and make sure you do not undersize your VMs to the point of performance problems, while at the same time you do not overprovision memory and waste resources in the system.

The same goes for databases that use all the available memory giving to them; or for performance issues presented by a too big of a VM running Exchange.

In other words, better sizing recommendations can be achieved by understanding the application running on top of the VMs. Furthermore, if you want to add the elasticity of doing this in real time, you also want to understand the supply from the underlying infrastructure. A JVM might need a bigger heap, however, the VM it is on is sitting on top of a host that is ballooning – sizing it up will make it perform worse.

To summarize, right sizing is important.

  • In some cases right sizing helps performance when done correctly in real time.
  • Right sizing will not help you increase density within your environment.
  • It is very difficult to size correctly without understanding the underlying infrastructure and the actual application demand.
Recommended eBook
Assuring Microsoft Exchange Performance eBook

Did you know that the Microsoft Exchange mail server will experience performance degradation when it’s over-provisioned, and under-provisioned.

Download Now

Leave a Reply

Your email address will not be published. Required fields are marked *