vCPU to pCPU Ratio Calculator

You carefully selected each component when building it out. The RAM matched the CPU. Maybe you debated which RAID level to use for hours before you finally made a decision.

So then you boot into ESXi or Proxmox and begin spinning up your virtual machines. You might spin up a firewall here, a database there, and some home automation containers for good measure. It all feel snappy. Your hosts appear idle on the dashboard so you think you’re safe.

How to Plan Your Virtual Machine Resources

That’s where most virtualization projects go to die. Those hosts aren’t realy idle. In fact, they’re waiting. While they wait, the scheduler juggle context switches. Meanwhile, your guests waits in line for their chance to use the processor.

The key is understanding the distinction between virtual CPUs and physical processing power. Virtual CPUs are often misinterpreted as equivalent to physical cores. You look at task manager and see eight threads; so, you assume you’ve got eight cores to donate. Wrong! That will cost you latency down the line.

Hyper-Threading, or simultaneous multithreading, use shared execution resources inside a single physical core. This boosts throughput on background tasks, but doesn’t double your capacity for responsive workloads. By choosing your CPU platform, the calculator above does the math for you so you don’t need to guess what fraction of a core you should of credit each additional thread. Instead, it assigns a realistic value instead of allowing you to assume that every thread is a whole core.

So what’s your workload profile? Does it matter? Is latency important? Both a database and a firewall care about that. When someone sends them a query, or a packet comes through their firewall, they want instant access to the underlying CPU. Oversubscribe those VMs too heavily, and the guest will has to wait around in the CPU ready queue. A couple of millisecond delays here and there sum to dropped packets, or a sluggish interface later on.

But a test VM, sitting idle half the day, doesn’t much care for waiting five minutes before it runs. Pack more of those onto the same hardware.

Other inputs that trip people up include reserved cores. To get as much value as possible for density, you’d like to use all cores assigned to guests. However, remember the hypervisor require breathing room. Networking on the host, backup daemons, storage threads; they all requires CPU time. Starve the host, and everything (including VMs) will slow down.

A couple of core reserved is not a waste of space; it’s insurance. It makes sure underlying system remains healthy, preventing the guests from starving during a backup window.

Plan for your failover. When you have a cluster, how will this work if you take a node out of rotation for maintenance? How much load does it shift? The calculator accounts for that. Your load will increase on the other hosts, which means your capacity is different than what you were planning for. Run without that cushion and you can get great density numbers on paper, but not in real life. What you’re left with is a cluster that functions perfectly … right up to the point where it has to function perfectly.

And then there’s the reality check: peak demand. Sure, you may have two dozen VMs, but chances are none of them will spike at the same time. This is where oversubscription comes into play. You bank on the fact that, statistically, it is unlikely that all your machines will hit 100% CPU usage at the same time. However, what is peak? Is it a quiet Tuesday afternoon? Or maybe it is a Sunday night when everyone is backing up their photos and gaming? Define what peak means to set a realistic peak demand percentage. Give yourself some breathing room for storms that actualy occur, but do not plan for a ghost load that never occurs.

As you’ll see from the reference tables on the page, they’re nothing more than guidelines; your mileage will vary depending on scaling behavior, cooling, thermal limits, etc. The ratio may work better in some cases then others. A higher ratio may be possible with a Ryzen desktop CPU than an older Xeon due to single-core speed, but it doesn’t matter as much if your workload is completely parallel. It’s a balancing act between scheduling efficiency and raw power.

Don’t chase numbers The whole point of density isn’t density. It’s a means to an end. Your lab should be stable and respond quickly when you need it. You’ve lost the plot if you’re always tweaking things to get one more VM squeezed in. Build for your worst day, not your best. Reserve some resources on hosts. Keep the ready times down. Realize that available doesn’t mean idle.

After the dust has settled, you’ll have a system that actualy works when you turn it on.