Uniqcli

Virtual machine host capacity ledger

Compare configured VM memory and an explicit vCPU policy with surviving hosts, without predicting application performance.

Compute & memory

Virtual machine host capacity ledger

Compare configured VM memory and an explicit vCPU policy with surviving hosts, without predicting application performance.

Example inputs · Replace these with your measurements to build your plan.

Configured allocations are not measured consumption. Use compatible hypervisor/version overhead.

Method, example and sources
  1. Reserve host/hypervisor memory on every surviving identical host.
  2. Sum VM configured RAM plus explicit per-VM overhead, and count assigned vCPUs.
  3. Compare aggregate demand and largest-VM memory with the failure scenario and the user’s vCPU policy.
  4. Treat aggregate host count as a lower bound and validate placement, NUMA and workload performance separately.

Worked example. Three 256 GiB hosts with 32 GiB reserved each leave 448 GiB when one host is unavailable. Twelve 16 GiB VMs plus two 32 GiB VMs total 256 GiB configured; 256 MiB overhead for each of fourteen VMs adds 3.5 GiB.

Planning result · confirm model details

Configured demand against surviving host resources

Aggregate headroom does not prove VM placement, NUMA fit, restart speed or workload performance.

VM count
14
Configured memory plus entered overhead
259.5GiB
Surviving usable memory
448GiB
Memory remaining
188.5GiB
vCPU per surviving physical core
1
Aggregate host-count lower bound incl. unavailable hosts
3
Virtual machine host capacity ledger: detailed result
Resource checkResult
Aggregate configured RAMWithin entered limits
Entered vCPU policyWithin entered limits
Largest VM memory on one hostWithin entered limits
  • Configured, committed and measured memory are distinct. Dynamic memory and overcommit need the exact hypervisor policy; no generic deduplication savings are assumed.
  • The host-count result is an aggregate lower bound, not a bin-packing solution. Storage/IOPS, NUMA, CPU contention, networking and acceptance tests remain required.

From the catalog

Servers

Explore related listings, then confirm the exact model requirements against your plan. These listings are not an automatic compatibility or capacity verdict.

Browse servers Browse ram modules Browse hard drives/solid state drives Get help with the specification

What the result means

A virtualization capacity ledger needs to distinguish physical RAM, host reserve, configured VM allocation and measured workload use. Failure scenarios reduce the resources actually available for restart. This worksheet keeps the entered overhead and vCPU policy visible rather than assuming that every nominal gigabyte or a universal consolidation ratio can be sold to virtual machines.

Before choosing a product

Aggregate capacity is necessary but not sufficient for placement. One large VM can exceed a host even when the cluster total has spare memory, and NUMA boundaries, storage latency or CPU scheduling can dominate performance. Dynamic memory and overcommit behavior depend on the exact hypervisor/version and workload. Validate restart and representative applications under the intended failure state before committing a server or RAM configuration.

Worked example

Three 256 GiB hosts with 32 GiB reserved each leave 448 GiB when one host is unavailable. Twelve 16 GiB VMs plus two 32 GiB VMs total 256 GiB configured; 256 MiB overhead for each of fourteen VMs adds 3.5 GiB.

Virtual machine host capacity ledger — Uniqcli