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

• Matt Liebowitz
• April 9, 2014April 9, 2014
• 6
• 2418

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.

 

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.”

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.