MB Networks
TOOL-25 · Infrastructure
VM & container sizing planner
List your guests' vCPU and RAM allocation, set your overcommit ratios, and see whether the host can actually back what you've promised it.
vCPU allocated / allowed
0 / 0
RAM allocated / available
0 / 0 GB
CPU is safe to overcommit because guests rarely peak simultaneously — RAM overcommit is riskier and this tool defaults to a 1:1 ratio (no overcommit) unless you deliberately change it.
Why vCPU overcommit works but RAM overcommit is riskier
CPU scheduling is time-sliced — a host can hand out more vCPUs than it has physical cores because guests rarely all demand 100% CPU at the same instant, and the hypervisor just schedules around the peaks. A 4:1 vCPU:pCPU ratio is a common conservative default for general-purpose workloads. RAM doesn't work the same way: unlike CPU cycles, allocated memory is harder to reclaim instantly when a guest actually uses it, so overcommitting RAM risks a guest hitting a hard out-of-memory wall rather than just running slower.
Leave something for the host itself
The hypervisor, its management stack, and any host-level services (storage, networking, monitoring agents) need their own RAM — allocating literally 100% of host RAM to guests leaves nothing for the host and risks instability under load. A reserved buffer (this tool defaults to 8GB, adjust for your actual host) keeps that overhead from silently eating into guest performance.
What's a safe vCPU:pCPU ratio?
3:1 to 4:1 is a common conservative default for general-purpose virtualization; latency-sensitive workloads (databases, real-time applications) often run closer to 1:1 or 2:1. There's no universal safe number — it depends on how CPU-hungry your actual guests are and whether their peak usage overlaps.
Why shouldn't I overcommit RAM the same way I overcommit CPU?
A CPU cycle not used this millisecond is simply available next millisecond — nothing is lost. Memory a guest has already written to has to stay resident (or be swapped, which is slow) — there's no equivalent "time-slicing" for RAM, so overcommitting it risks a guest actually running out rather than just running slower.
Does container sizing work the same way as VM sizing?
The concepts are the same — CPU limits/requests and memory limits map onto the same host-capacity math — but containers share the host kernel and typically have less isolation overhead than a full VM, so the same host can usually run more containers than equivalently-sized VMs.
Related tools
Infrastructure
Rack Unit & Weight Planner
Plan a rack layout — track U space used, total weight against rack load rating, and catch mixed front-to-back/side-to-side airflow before it becomes a heat problem.
Open →Infrastructure
Server & Homelab Power Cost Calculator
Add up your server, rack, and homelab gear, set your electricity rate, and see the real daily, monthly, and yearly cost of running it 24/7.
Open →Infrastructure
Data Size Converter
Convert between bits, bytes, KB, MB, GB, TB, PB and their binary equivalents (KiB, MiB, GiB). Instant browser-side conversion with common size presets.
Open →Infrastructure
SLA Uptime Calculator
Calculate allowed downtime from any SLA percentage. See downtime per year, month, week, day, and hour for any availability target.
Open →Infrastructure
Network Speed Converter
Convert between Mbps, Gbps, MB/s, GB/s and all common network and storage throughput units. Common interface presets for USB, Ethernet, Wi-Fi, NVMe, and more.
Open →Infrastructure
Network Transfer Time Calculator
Enter a file size and link speed to see how long a transfer will take. Includes real-world estimates for wired and Wi-Fi connections.
Open →