There is no fixed VM count for a host. Calculate CPU capacity from reserved physical cores and an explicit vCPU ratio, calculate memory after reserves and headroom, then use the lowest result after checking storage, network, licensing and N+1 failover capacity.
There is no fixed or generally defensible number of virtual machines that fit on one host. The usable count is the lowest capacity allowed by CPU, memory, storage, network, accelerators, licensing and availability requirements after all reserves have been deducted. A host may support dozens or hundreds of small virtual machines, but that does not make either figure suitable for a tender or deployment plan. VM density has to be calculated against a defined workload profile. Start with a standard VM profile Define the workload before selecting the host. A useful profile includes: Configured vCPUs per VM Configured and peak memory per VM Usable storage capacity Required read and write IOPS Expected throughput and latency Network traffic, including backup and replication GPU, SR-IOV, PCIe passthrough or other placement requirements Operating system and application licensing constraints Separate profiles are normally required for infrastructure services, databases, application servers, VDI sessions and development machines. Averaging unlike workloads into one notional VM can conceal the actual constraint. Calculate CPU capacity from physical cores Host vCPU capacity equals available physical cores multiplied by the selected vCPU-to-physical-core ratio. Use physical cores as the conservative sizing base rather than counting SMT or Hyper-Threading threads as additional cores. First deduct cores reserved for the hypervisor, storage services, security software, backup agents and management functions. Available physical cores = installed physical cores − reserved physical cores. CPU-limited VM count = available physical cores × vCPU ratio ÷ vCPUs per VM. The result must be rounded down to a whole VM. Broadcom defines CPU oversubscription using assigned vCPUs and physical cores, and recommends physical cores as the conservative basis where predictable performance is required. Broadcom CPU oversubscription guidance provides further context. Select the vCPU ratio deliberately A 1:1 ratio is appropriate for highly CPU-sensitive or consistently busy workloads. Ratios such as 2:1, 4:1 or 5:1 may be suitable where many VMs spend substantial time below peak CPU demand. The ratio is a workload assumption, not an attribute guaranteed by the processor. Red Hat identifies 5:1 as a generally safe starting point for workloads that do not continuously consume CPU, advises against allocating more than 10 vCPUs per physical core, and requires testing for production overcommitment. These figures are guidance rather than universal limits. See the RHEL virtual machine performance guidance . For an existing environment, derive the ratio from measured utilisation. Review peak periods, CPU ready or steal time, application response time and batch windows. A monthly average is not sufficient where payroll, reporting, simulation or backup activity creates concentrated demand. Calculate memory after reserves and headroom Assignable VM memory equals installed RAM minus host reserve, platform reserve and chosen operational headroom. Memory-limited VM count = assignable VM memory ÷ configured memory per VM. A first-pass design should use a 1.0 configured-vRAM-to-physical-RAM commitment ratio. In other words, 1 GB of configured VM memory consumes 1 GB from the assignable physical-memory pool. This prevents an optimistic memory-overcommit figure from silently increasing the quoted VM density. The host reserve covers the hypervisor or management operating system. The platform reserve accounts for cluster services, storage functions, monitoring, endpoint security and backup components. Operational headroom is additional unallocated memory retained for workload growth, migration activity and demand variation. These deductions should be shown separately in the sizing schedule. Dynamic Memory, ballooning and other memory-overcommit mechanisms can improve utilisation for suitable workloads, including some VDI pools. They should be treated as advanced design inputs and validated under load. Frequent swapping or reclaim activity can make a technically running VM unacceptably slow. Use the lower CPU or memory result Consider a dual-socket host with the following configuration: Two 32-core processors, giving 64 physical cores Four physical cores reserved for host and platform functions A selected 4:1 vCPU-to-physical-core ratio 512 GB installed RAM 32 GB reserved for host and platform functions 32 GB retained as operational memory headroom A standard VM profile of 4 vCPUs and 16 GB RAM CPU result The host has 60 available physical cores. At 4:1, it provides a planning capacity of 240 assigned vCPUs. Dividing by 4 vCPUs per VM gives a CPU limit of 60 VMs. Memory result After deducting 64 GB for reserves and headroom, 448 GB remains assignable. Dividing by 16 GB per VM gives a memory limit of 28 VMs. The preliminary answer for this host is 28 VMs because memory is the lower result. This count remains subject to storage performance, network capacity, device placement, licensing and availability checks. Check storage by capacity and performance Usable terabytes alone do not establish storage density. A datastore can have sufficient free capacity while failing to meet latency or IOPS requirements during boot storms, patching, database activity or backup. Deduct RAID or erasure-coding overhead, hot spares, snapshots, metadata, replication and the required free-space floor. Then validate the storage system against aggregate workload demand. Storage-limited VM count is the lower result from usable-capacity sizing and IOPS or throughput sizing. The calculation should identify the media and path used, such as SAS SSD, NVMe, NFS, iSCSI, Fibre Channel or NVMe/TCP. Queue depth, controller limits and network path redundancy can matter as much as the nominal drive specification. Check network and placement constraints Network calculations should include application traffic, storage traffic, live migration, cluster heartbeat, backup and replication. A host fitted with 10 GbE or 25 GbE interfaces does not automatically provide the full port rate to every VM. Redundancy, protocol overhead and concurrent operations reduce usable bandwidth. GPU and passthrough workloads require a placement check rather than a simple host-wide average. A VM needing a complete GPU, a specific vGPU profile, SR-IOV virtual function or PCIe device can only run where that resource is available. NUMA boundaries and large-memory VM placement can also reduce the count obtained from aggregate CPU and RAM arithmetic. A platform maximum is not a sizing figure Windows Server 2025 Hyper-V supports up to 1,024 running VMs on one host and does not prescribe a fixed virtual-processor-to-logical-processor ratio. Microsoft still requires workload capacity planning and sufficient clustered capacity for failover. The supported maximum therefore indicates platform scale, not the number of production VMs that a particular host should carry. See the Microsoft Hyper-V maximum scale limits . Licensing must be assessed separately. Products licensed by physical core, socket, host or VM can change the commercial optimum even where the hardware has spare capacity. Virtualisation rights, subscription terms and mobility rules should be checked against the exact software edition being procured. What N+1 costs in usable capacity In a cluster of N identical hosts designed to survive one host failure, the committed capacity must fit on N minus 1 hosts. N+1 does not necessarily require one powered-off standby server. The reserve can be distributed across all active nodes, but one host-equivalent of capacity cannot be committed if every VM must restart or migrate after a host failure. A two-host N+1 cluster provides 50 per cent of its aggregate capacity for committed workloads. A three-host N+1 cluster provides approximately 66.7 per cent. A four-host N+1 cluster provides 75 per cent. A five-host N+1 cluster provides 80 per cent. These percentages assume identical hosts and one-host failure tolerance. Maintenance, multiple failures, rack-level fault domains and storage-controller failures may require additional reserve. Applying N+1 to the worked example Each example host has a preliminary capacity of 28 standard VMs. Three hosts therefore have an apparent aggregate capacity of 84 VMs. With one host reserved through N+1 planning, only two host-equivalents can be committed: Usable N+1 cluster capacity = 28 × (3 − 1) = 56 VMs. During normal operation, those 56 VMs can be spread across all three hosts, averaging about 18 or 19 VMs per host. If one host becomes unavailable, the remaining two hosts can carry up to 28 VMs each. Anti-affinity rules, large VMs and device-bound workloads can reduce this figure. In a mixed-hardware cluster, model the loss of the largest relevant host or fault domain rather than subtracting an average node. Specify VM density properly in a tender A requirement such as “minimum 100 VMs per host” is incomplete unless the VM profile and acceptance conditions are stated. A technically useful specification should ask the bidder to provide: Processor model, socket count, physical cores per socket and reserved cores Proposed vCPU-to-physical-core ratio with workload justification Installed RAM, each reserve deduction and the resulting assignable RAM Configured vCPU and memory for every VM profile Usable storage after protection and spare capacity Storage latency, IOPS and throughput assumptions Network interfaces, redundancy and traffic separation Host count and usable cluster capacity with one node unavailable Licensing assumptions and exclusions Performance acceptance criteria under normal and failover conditions The acceptance test should include representative concurrency rather than confirming only that the VMs can boot. CPU scheduling delay, memory pressure, storage latency, application response time and failover behaviour should be observed during the test window. Calculate a first-pass configuration Use the VM sizing tool to compare CPU oversubscription, memory headroom and N+1 cluster capacity. The result should then be checked against measured workload data and application-specific requirements. NetBytes virtualisation appliances are available in rack configurations with host, storage and cluster options sized for the required workload profile. For a configuration against a tender schedule or existing VM inventory, share the details through contact .