Sizing a Proxmox Host: vCPU, RAM, Storage and IOPS for SMB Workloads
How to turn a list of workloads you already run into a specification you can actually order, and which of the four numbers is the one that will bite you.
By William Bradshaw | September 21, 2026 | 11 min read
Every consolidation project reaches the same moment. The decision is made, the workloads are chosen, and somebody has to write down what to buy. Our guide to deciding which workloads belong back on-prem ends at exactly this point, with the instruction to size what survives as a single hypervisor host. This article is how you do that.
The failure mode is not usually buying too little. It is buying the wrong shape: a host with generous core count and thin memory, or plenty of terabytes behind a disk layout that cannot serve them quickly enough. Both specifications look defensible on paper and both produce a system that feels slow from the first week, with no obvious culprit.
So this is organized around the four resources in the order they tend to cause trouble, which is roughly the reverse of the order people think about them. Storage performance first in importance, memory second, CPU third, network last. Everything below assumes Proxmox VE, but only the ZFS and ballooning specifics are particular to it. The arithmetic applies to any hypervisor.
Start From an Inventory, Not a Budget
Before any of the four numbers means anything, you need a row per workload. Not per server, per workload, because part of the value of consolidating is that some of those servers should not survive the move as separate machines.
For each one, record six things: assigned vCPU, assigned RAM, used disk, total disk, observed peak CPU, and observed peak IOPS. The first four are inventory and take an afternoon. The last two require measurement, which is the step most specifications skip, and the reason most of them are wrong.
Measure over a business cycle, not an afternoon. Sample at least a full week, and prefer one that includes month-end. The figure you size against is the peak sustained load, not the average and not the single highest spike. An average hides the only period that matters; a one-second spike sizes you for something that never recurs.
On Linux, iostat -x 5 gives you per-device reads and writes per second, queue depth and service time. On Windows, the PhysicalDisk counters in Performance Monitor expose the same figures, logged to a file over the same period. Both are already installed. Neither needs a licence or an agent.
If a workload is currently in public cloud, the provider's own monitoring already holds this data and it is usually easier to export than to instrument. That is the one genuine advantage of sizing a repatriation over sizing a greenfield build: you are describing something that already exists, with a year of telemetry behind it.
Storage: Size for IOPS, Then Check Capacity
This is the one that gets written backwards most often. A specification lists twelve terabytes of usable capacity, the drives are chosen to reach twelve terabytes as economically as possible, and the result cannot keep up with ten concurrent guests.
The reason is consolidation itself. Each of those workloads, on its own physical server, produced a mostly sequential access pattern that a spinning disk handled comfortably. Run ten of them against one pool and their streams interleave. From the storage layer's point of view, the combined pattern is effectively random, and random is where spinning disks collapse. A 7,200 RPM drive delivers on the order of 75 to 100 random IOPS. A consumer SSD delivers tens of thousands. That is not a gap you close by adding spindles.
The practical conclusion for a small-business host is short: put every running guest on SSD, and use spinning disks only for bulk storage and backup targets, where the access pattern really is sequential and the cost per terabyte is the point.
Endurance, not just speed
Hypervisor storage is write-amplified. Copy-on-write filesystems, guest filesystems layered on virtual disks, and snapshots all multiply the writes reaching the drive. Consumer SSDs rated for a few hundred terabytes written will wear out years before the host is due for replacement, and they tend to do it quietly until they do not.
Specify drives by their endurance rating, expressed as drive writes per day or total terabytes written, and check it against the write rate you measured. This is also where power loss protection matters: enterprise SSDs carry capacitors that let an in-flight write complete during a power failure, which is what makes a synchronous write safe to acknowledge. Drives without it either lose the write or lie about having completed it.
Mirrors versus RAIDZ
For ZFS specifically, the layout choice is a performance decision disguised as a capacity decision. A RAIDZ group delivers roughly the random IOPS of a single member drive, no matter how many drives are in it, because every read has to touch the whole stripe. Striped mirrors multiply IOPS with each pair added, at the cost of half the raw capacity.
For guest storage, use mirrors. For a backup or archive pool, RAIDZ is the right tool and the capacity saving is real. Putting running virtual machines on RAIDZ to save disks is the single most common storage regret we are called in to unwind. Our notes on what production VMware migrations actually need cover the benchmarking step that should follow once the pool is built.
Memory: The One You Cannot Oversubscribe
CPU overcommit is safe because it degrades gracefully. A guest that wants a core it cannot have waits a moment longer, and the symptom is mild slowness spread across everything.
Memory does not behave that way. When a host exhausts RAM, it starts swapping, which destroys performance far out of proportion to the shortfall, or the out-of-memory killer terminates a guest outright. There is no graceful middle. Treat the guest memory total as a hard floor.
Host RAM = sum of guest allocations + hypervisor overhead + ZFS ARC + headroom. All four terms, added, not averaged. Ballooning and kernel same-page merging can reclaim some of the first term in practice, but neither is a reason to buy less. They are a margin of safety, not a line item you get to subtract.
The ZFS ARC trap
ZFS treats unused memory as a read cache and will claim a large share of the host by default. On a file server that is exactly right. On a hypervisor it is not, because the memory it is claiming is not spare, it is the memory your guests are going to want.
Set the ARC maximum explicitly at build time rather than discovering the default under load. As a working figure, budget roughly 1 GB of ARC per terabyte of pool for a general-purpose workload, then treat that as host overhead in the equation above. A host with 64 GB of RAM, 48 GB of guests and an uncapped ARC over a 20 TB pool is a host that will start swapping, and the cause is rarely obvious from inside the guests.
Buy the slots, not just the sticks
Memory is the resource most likely to need expanding mid-life, and the expansion is cheap only if you left room. Populating every slot on day one to hit a number means the only upgrade path is replacing modules you already own. Reaching the same total with larger modules and half the slots filled costs a little more up front and makes the eventual expansion a purchase order instead of a project. Use ECC memory, which on a consolidated host is not an optional refinement: a single-bit error on a hypervisor is not one application's problem.
CPU: Count What Is Used, Not What Is Assigned
Add up the vCPUs assigned across your inventory and the total will alarm you. It should not. An assigned vCPU that sits idle consumes no host cycles, and most small-business servers are idle most of the time. A domain controller assigned four vCPUs may average two percent of one.
So the useful arithmetic is the sum of observed peak utilization, not the sum of allocations. In practice, for a typical mix of file, print, directory, line-of-business and utility servers, 4 vCPU per physical core is comfortable and 6 to 1 is achievable. Ratios above that are possible but stop being predictable.
The exception is any workload that genuinely runs hot: a busy database, a build agent, a reporting server that pins cores for an hour every night. Count those close to their assigned size and apply the ratio only to the rest. One misclassified workload of this kind will make a correctly sized host feel wrong.
Cores or clock speed
Given a choice between more cores at a lower clock and fewer at a higher one, consolidation generally favours cores, because the work is many independent small tasks rather than one large one. The exception is again the hot workload, and specifically any application whose performance is bound by a single thread. Legacy line-of-business software is full of these, and no amount of core count helps them.
One practical warning on the number of sockets: a two-socket host introduces NUMA, where memory attached to one processor is slower to reach from the other. A guest sized larger than a single socket's core count or memory will straddle both and pay for it. For most small-business consolidations a single socket with enough cores is simpler, cheaper, and faster in the cases that matter.
Network: Separate the Roles Before Adding Bandwidth
Network is last because it is rarely the constraint on a single-host build. Guest-to-guest traffic never leaves the host at all, and most small-business workloads do not saturate a gigabit link.
What does cause problems is role collision. Backup traffic on the same interface as production will make the working day slow for as long as the backup runs, and the backup window is exactly when you are least likely to be watching. Management traffic sharing with guest traffic means a saturated link is also the link you need to log in and fix it.
Plan a minimum of two physical interfaces, one for management and one for guests, with backup traffic either on its own interface or on a tagged VLAN with a bandwidth limit. That is a configuration decision rather than a purchase, and it does more for perceived performance than upgrading to faster links.
If you are also designing the bridge and VLAN layout, our guide to vmbr0, VLAN-aware bridges and bonds covers the configuration side in detail.
A Worked Example
A township office consolidating eight workloads. The inventory, after measurement:
| Workload | vCPU assigned | Peak CPU used | RAM | Peak IOPS |
|---|---|---|---|---|
| Domain controller | 2 | 0.1 | 4 GB | 40 |
| File server | 4 | 0.8 | 8 GB | 600 |
| Finance application | 4 | 2.5 | 16 GB | 1,800 |
| Application database | 4 | 3.0 | 16 GB | 2,400 |
| Print and scan | 2 | 0.2 | 4 GB | 50 |
| GIS and mapping | 4 | 1.2 | 12 GB | 500 |
| Monitoring and logging | 2 | 0.6 | 6 GB | 700 |
| Utility and jump host | 2 | 0.1 | 4 GB | 30 |
| Total | 24 | 8.5 | 70 GB | 6,120 |
CPU. 24 vCPU assigned but 8.5 cores of real peak demand. The finance application and its database are the hot pair and get counted near full size; the rest divide comfortably. Sixteen physical cores covers it at better than 60 percent headroom, and a single socket avoids the NUMA question entirely.
Memory. 70 GB of guests, plus about 4 GB of hypervisor overhead, plus a capped 16 GB ARC over a 16 TB pool, is 90 GB before headroom. 128 GB is the sensible purchase, and on a board with eight slots it can be reached with four modules, leaving four open for a later expansion.
Storage. 6,120 peak IOPS is the number that decides the shape of the build. It rules out spinning disks for guest storage without further discussion, and it is comfortably inside what a pool of mirrored enterprise SSDs delivers. Capacity turns out to be the easy half.
The point of the exercise. Note that the first number anyone would have quoted, 24 vCPU, was nearly three times the real requirement, while the number nobody usually measures, 6,120 IOPS, is the one that actually determined what to buy. That inversion is the normal case, not a contrived example.
What a Sizing Exercise Does Not Answer
A correctly sized host is a machine that can run the workload. It is not yet a system you can depend on, and the gap between those two is where consolidation projects tend to disappoint.
- One host is one failure domain. Eight services that used to fail independently now fail together. Whether that is acceptable is a business question, and the honest answers are a second host, a documented rebuild procedure with a tested restore, or an explicit decision to accept the outage.
- Backups need their own capacity. The backup target is not part of the pool you just sized, and an on-host snapshot is not a backup. It shares every failure mode with the thing it is protecting.
- Power and cooling are real constraints. A closet that held three low-power servers may not tolerate one dense one, and a host on an undersized battery will not shut down cleanly.
- Somebody has to operate it. Patching, monitoring, capacity review and restore testing are recurring work. Consolidation reduces the number of machines, not the amount of operations.
For regulated environments, note that hardware consolidation also concentrates your control evidence. If you are working to a framework, size the host and review the control mapping in the same exercise rather than discovering the overlap at audit. Our notes on backup and disaster recovery for public entities cover the retention and recovery side of the same decision.
The Short Version
- Build a row per workload, and measure peak CPU and peak IOPS over a full business cycle before specifying anything.
- Size storage for IOPS first. SSD for everything that runs, spinning disks only for bulk and backup.
- Use mirrors for guest storage. RAIDZ gives you the IOPS of one drive, whatever its width.
- Treat guest RAM as a hard floor, add hypervisor overhead and a capped ZFS ARC, then add headroom. Do not overcommit it.
- Apply an overcommit ratio of 4 to 1 on CPU for ordinary workloads, and count the hot ones close to full size.
- Separate management, guest and backup network roles before buying faster links.
- Target 60 to 70 percent utilization on day one, across a five-year life.
- Size the backup target, the power budget and the operating routine in the same exercise, not afterwards.
Want a Second Opinion on a Host Specification?
Bullium sizes and builds consolidated hypervisor hosts for SMB, mid-market and Ohio public-sector environments. We take your workload inventory, measure what it actually consumes, and produce a specification with the reasoning attached so you can take it to any vendor. No commitment to engage further.
Related Reading
Cloud Repatriation for SMBs
Which workloads move back on-prem profitably, and the cost model that makes the comparison honest.
Migrating from VMware to Proxmox
What production environments actually need, including the storage benchmarking step.
Proxmox Networking
vmbr0, VLAN-aware bridges and bonds, once the host is specified and racked.
Securing Proxmox VE After a Migration
A practical hardening checklist for the host you just built.
Proxmox vs VMware
An open-source virtualization comparison, if the platform is still undecided.
Backup and Disaster Recovery
Sizing the backup target and the recovery objectives that drive it.
Related Services
Virtualization Consulting
Sizing, hypervisor selection and high availability for the host your workloads land on.
vCIO Practice
Budget planning and replacement cycles across a five-year infrastructure horizon.
Business Continuity
Backup design and tested recovery for a consolidated failure domain.
Managed IT Services
Patching, monitoring and capacity review for the host once it is in production.