One Weird Trick to Virtualize Monster VMs–Consultants Hate This!

We’ve all seen those ads on the Internet that promise to teach us “one weird trick” that “<someone> hates” to do something easily.  Make money fast?  Yep.  Lose belly fat?  Check.  Grow “other” parts of your body?  Easy.

Oneweirdtrick  everyonehateshim

I couldn’t resist stealing the headline for something that I’ve seen come up time and time again when virtualizing large applications or monster VMs.

Raise your virtual hand if you’ve heard, or said, something like this in the past:

All VMs should start out with only 1 vCPU.

Most VMs don’t need more than 1 vCPU.

Giving a VM more than 1 vCPU could hurt performance.

I hear this one all the time.  I even used to say something like it myself.  When I think back to my early days with virtualization I used to say things like, “If a server needs more than 3.6GB of RAM, it probably isn’t a good candidate for virtualization.” (3.6GB was the max RAM supported in a guest OS in ESX 2.x)  But is that the right way to approach sizing all virtual machines?

These days, most of the time I hear something like this as a result of a software vendor’s sizing guidance for their application.

“Why should I give that VM 4 vCPUs and 16GB of RAM? There is no way it really needs it!”

The thing to remember here is this: While starting small when sizing VMs is a good practice, the application’s actual requirements should dictate the sizing.  That’s the “one weird trick” – understand the application’s requirements before rushing to judge the sizing.  Just because you don’t like the idea of giving a VM a lot of resources doesn’t mean it doesn’t actually need them.  Trust me – I’m a big believer in starting small and sizing VMs with fewer resources if the resource requirements are not well known or defined.  That doesn’t apply to all VMs.

I hear it too often – folks who automatically rush to judge the sizing of a virtual machine just because they think it’s “too big.”  We need to get past the mentality of “anything larger than 1 vCPU is bad.”

I’m going to put this ad on other virtualization blogs!

Before you head to the comments and say something like, “Vendor supplied requirements are BS.  Vendor x told me that their application needed y requirements and it doesn’t use even half of that.” hear me out.  Is that true sometimes?  Definitely.  But should that be your default answer?  Definitely not.  If the application you’re trying to virtualize is currently physical, a good way to determine if the sizing is accurate is to simply measure the existing load.  But don’t forget – the current utilization alone is not enough to size the VM.  You need the application’s actual requirements.  I’ll illustrate that point with a story.

I worked with a customer last year to help them virtualize an important Microsoft SharePoint FAST Search implementation.  We ran capacity assessments on the existing physical servers with both VMware Capacity Planner and Microsoft Assessment and Planning Toolkit.  Both tools independently came to the same conclusion: based on the current utilization, these servers likely need 2 vCPUs and 8GB of RAM.

When I worked with the FAST architects, they wanted their servers sized with 8 vCPUs and 24GB of RAM.  Naturally there was confusion as to why the current physical servers were only using a quarter of those resources.  It came down to one thing: requirements.

The customer had a specific requirement to be able to support a certain number of QPS (queries per second) at a certain level of latency.  In order to meet those requirements we needed to size the servers with 8 vCPUs and 24GB of RAM.  We validated that design by running FAST performance tests at different CPU/memory sizing on the FAST VMs.  Each time we were not able to meet the QPS requirements unless it was sized correctly.

What’s the moral of this story?  Don’t be afraid of giving a virtual machine the resources it actually requires.  Remember – there are tools like vCenter Operations that can tell you, over time, how a VM is using its resources.  This provides you the opportunity to right-size the workload if the VM truly doesn’t need the resources.

Understand the vendor stated requirements as well as those of your customer/application owner.  If you get a request for a SQL Server (or similar) and your immediate response is, “I’m not giving it that many vCPUs…” stop and make sure you truly understand the application’s requirements.  Validate the sizing with performance testing and adjust if necessary.  You’ll have happier application owners and better performing applications.

Share This:

6 thoughts on “One Weird Trick to Virtualize Monster VMs–Consultants Hate This!

  1. Have you come across any servers lately that you still believe aren’t good candidates for virtualization, or is that a thing of the past?

    1. Most of the time a server you can’t virtualize is an economic decision rather than a functional limitation of vSphere. In other words – is it worth it to virtualize a VM that would need so many resources? Usually the answer is still yes because of all of the other benefits you get.

      There are other situations where something needs ultra low latency and it isn’t a great candidate but there are fewer and fewer of those.

      Thanks for the comment Danny!

      Matt

  2. Hi Matt,
    totally agree with you, however i have this issue where vendor size his enviroment based on phsyical servers specs and when trying to ask understand the actual requirments the answer is ???? (don’t be surprised ) also i am intersted ti know more information about the FAST case you encountered before and why it required 8 vCPUs while using 2 only cos i have smiliar situtaion

    Marwan

    1. Hi Marwan,

      A lot of the time the best you can do is ask for the requirements, ask for documentation of those requirements, or work with them to determine the requirements based on a POC. If you can’t do any of those things, I’d suggest starting small and scaling up as you see.

      With respect to the FAST environment, the customer’s stated requirements for the project was to support a certain number of queries per second (QP/s). We monitored the current physical FAST servers and determined that they were only using 2 CPUs worth of processing power. However, during performance testing of the FAST environment we pushed the testing to get to the QP/s value the customer stated they wanted to support. In all cases, the testing failed until we raised the configuration to 8 vCPUs and 24GB of RAM. Once we did that, all tests passed.

      That was a great example of customer stated requirements vs. actual resource consumption. At the end of the day, we needed to be able to meet the customer’s stated requirements so we left the vCPUs and RAM and 8 vCPUs and 24GB.

      Hope that helps!

      Matt

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.