Two limits that fail in opposite ways
Processor capacity is elastic. If eight guests each want two vCPU on a host with fourteen free threads, they can have them, because guests spend most of their existence doing nothing and the scheduler hands the thread to whoever wants it. Push it too far and the symptom is queueing: every guest waits a little longer for a slot and everything runs slower in proportion. That is uncomfortable and completely recoverable, and it is why an overcommit ratio of three or four is ordinary on hosts full of idle services.
Memory has no such property. A guest allocated four gigabytes holds four gigabytes whether it is busy or not, and there is no equivalent of waiting your turn for a page that is not there. When memory runs out the host swaps, which is slower by a factor of thousands rather than a few percent, or the kernel terminates a process to reclaim pages, and you find out which guest it chose afterwards. Platforms have reclamation mechanisms that soften this, and how well they work is a question for the platform documentation rather than a number to plan against.
This asymmetry is the reason the guest count almost always comes out limited by memory, and the reason sizing a host by core count is the wrong instinct even though core count is the number on the box.
What the host keeps for itself
Two of the fields here exist because the host is not free, and the amount it takes varies enormously with what it is doing. A bare hypervisor with local disks takes little. A host also running a checksumming, parity-calculating storage layer with a large read cache takes a great deal, and it wants that memory permanently rather than opportunistically. If the same machine is serving files, running containers alongside virtual machines, or holding a database, all of that comes out before the guests get anything.
The per-guest overhead field is the other half. Each running guest costs the host something on top of what it was allocated, for page tables, device emulation and the machinery of keeping it isolated. This is one of the largest practical differences between full virtual machines and containers: a container shares the host kernel and its overhead is a fraction of a virtual machine which brings its own.
Allocating more vCPU than a guest needs
It feels generous and it is counterproductive. A guest allocated eight vCPU that uses one still has to be scheduled as an eight-way machine when it wants to run, which means finding eight free threads at the same moment rather than one. On a busy host that is measurably harder, and the guest can end up waiting longer than a two-vCPU version of itself would have. The instinct to give every guest plenty is the opposite of what makes a packed host feel fast.
| Resource | Behaviour when oversubscribed | How it is recovered |
|---|---|---|
| Processor | Queueing, everything slower in proportion | Stops on its own when load drops |
| Memory | Swapping, or a process terminated | Requires intervention, and something already broke |
| Storage capacity | Writes fail across every guest at once | Requires free space before anything continues |
| Storage throughput | Latency climbs for all guests together | Stops when the noisy guest stops |
| Network | Contention on the shared link | Stops when the transfer finishes |
Thin allocation and the surprise it saves up
Promising each guest a hundred gigabyte disk and only consuming what it writes is efficient, and it converts a capacity problem into a timing problem. The pool does not fill when you plan a new guest; it fills when the guests happen to write, which could be any Tuesday. A thin pool that reaches full does not degrade gracefully either: writes fail for every guest that shares it at the same moment, which is a wider blast radius than a single machine running out of disk.
The thin share field lets you model what is actually consumed rather than what is promised, and the calculator notes the gap between the two. Watching that gap over time is the same problem as any other storage growth question, and the storage growth calculator turns two readings into a date.
What this page cannot see
Capacity is not the same as performance. Two guests can fit comfortably by every number here and still make each other unusable, because one of them is doing something to the disks that the other is waiting behind. Storage throughput and latency under mixed load are where consolidation projects usually come unstuck, not core arithmetic, and the shape of that limit is worked out on the NAS throughput calculator for the network-attached case.
The other things this page does not know about are the physical ones. All of those guests are one machine, so its power draw, its heat and its single power supply are shared by everything running on it. The power supply wattage calculator covers the draw, the case airflow calculator covers the heat, and the UPS sizing calculator covers what happens when the power stops, which on a consolidated host stops everything at once rather than one thing.
Questions people ask
Why is memory the limit and not cores?
Because memory is allocated and cores are scheduled. A guest given four gigabytes holds them whether it is working or idle, so eight such guests need thirty-two gigabytes that physically exist. A guest given two vCPU only occupies threads while it is actually running, which for most services is a small fraction of the time, so the same threads can serve many guests. That difference lets processor overcommit ratios of three or four be ordinary while memory overcommit is something to be careful with. The practical consequence is that the upgrade that increases guest count is nearly always more memory.
What overcommit ratio should I use?
It depends on what the guests do, and the honest answer is that you should measure rather than adopt a figure. Hosts full of small idle services tolerate heavy packing because their peaks do not coincide. Hosts running anything that gets busy on a schedule do not, because everything gets busy at the same moment and the whole point of overcommitting was that they would not. Start conservatively, watch how long guests spend waiting for processor time under real load, and raise it if that number stays small. The field exists as an input rather than a default because there is no correct value.
Do containers change these numbers?
Substantially, on two of the three lines. A container shares the host kernel rather than bringing its own, so per-container overhead is a fraction of what a full virtual machine costs, and the memory line moves accordingly. Storage is usually much smaller too, since containers share image layers rather than each holding a full operating system. The processor side changes least, because the work being done is the same work either way. Model containers here by dropping the per-guest overhead and the disk allocation to realistic figures for your images.
Does simultaneous multithreading double my capacity?
No, and treating threads as cores is one of the more common sizing mistakes. Two threads on one core share the execution resources of that core, so two busy threads deliver considerably less than two busy cores. How much less depends entirely on the workload and there is no general figure worth quoting. The calculator counts logical threads because that is what the scheduler sees, and then applies your overcommit ratio on top, which is where the realism has to come from. If your guests are consistently processor-heavy, set the ratio lower than you would for idle services.
How much memory should I reserve for the host?
Enough that the host never competes with the guests, and how much that is depends on what else the host is doing. A plain hypervisor needs little. A host also running a checksumming storage layer with a read cache can want a large fixed slice and will use more if given it, and file serving, container workloads and monitoring all add to it. Watch the host actual usage under load for a week rather than accepting a default, and reserve above the peak you observe, not the average. Getting this wrong is not a slow degradation; it is the host swapping while trying to manage guests that are also swapping.