CPU GHz to vCPU Calculator
Convert physical CPU clock capacity into safe VM vCPU capacity using all-core GHz, core count, SMT gain, IPC adjustment, workload demand, host reserve, and oversubscription limits for home servers and small clusters.
GHz to vCPU Results
The formula intentionally avoids counting single-core turbo or SMT threads as full extra cores. That keeps the output useful for Proxmox, ESXi, Hyper-V, XCP-ng, and KVM hosts that carry steady background services.
| Workload profile | GHz per active vCPU | Default ratio | Planning behavior |
|---|---|---|---|
| Idle lab VMs and appliances | 0.20 GHz | 6:1 | Good for DNS, small Linux appliances, test VMs, and mostly idle guests. |
| Web apps, DNS, monitoring | 0.35 GHz | 5:1 | Small services run well when scheduled jobs and scans are staggered. |
| Mixed home server VMs | 0.45 GHz | 4:1 | Balanced default for Home Assistant, dashboards, file services, and utilities. |
| VDI or interactive desktops | 0.65 GHz | 3:1 | Interactive users notice ready time sooner than background service VMs. |
| Database or storage services | 0.75 GHz | 2:1 | CPU wait and IO wait can stack, so leave stronger host headroom. |
| Media transcode and app bursts | 1.00 GHz | 3:1 | Hardware encoding lowers CPU load, but software transcodes need margin. |
| CI builds and compile jobs | 1.25 GHz | 2:1 | Build workers often become all-core workloads during short windows. |
| Firewall or low-latency VM | 1.50 GHz | 1:1 | Routers, PBX, IDS, and packet capture VMs need low scheduling delay. |
| CPU class | IPC index | Typical homelab example | Use in calculator |
|---|---|---|---|
| Older Xeon E5 / DDR3 era | 0.70 | E5 v2 or similar rack servers | Discounts GHz for older per-clock performance and slower platform IO. |
| Skylake or Zen 1 class | 0.85 | Early Ryzen, Xeon Scalable, Coffee Lake | Useful for older mini PCs and second-hand workstation hosts. |
| Modern baseline CPU | 1.00 | Recent Core i5, Ryzen, Xeon E, N100 | Default when you only know cores and observed all-core clock. |
| Zen 3 / Alder Lake class | 1.12 | Ryzen 5000, 12th gen Core | Credits newer cores with stronger work per GHz for mixed services. |
| Zen 4 / newer server class | 1.22 | EPYC 9004, Ryzen 7000, newer Core | Best for dense VM hosts where per-core throughput is high. |
| Configuration | Usable hosts | Best fit | GHz sizing impact |
|---|---|---|---|
| Single host | All hosts | NAS, apps, one-box lab | Uses full CPU GHz but has no failover margin. |
| N+1 high availability | Hosts minus one | Small Proxmox or VMware cluster | Leaves enough GHz to survive one host offline. |
| Maintenance drain | Hosts minus one | Patch and reboot windows | Checks whether guests fit during node evacuation. |
| Development lab | All hosts | Temporary VMs and tests | Can tolerate higher ratios and brief CPU wait. |
| Always-on services | All hosts | Core household infrastructure | Keep target CPU lower for backups, alerts, and updates. |
| Project size | CPU shape | GHz planning result | Practical note |
|---|---|---|---|
| N100 NAS with app stack | 4 cores around 2.7 GHz | Light 8 to 14 vCPU plan | Works best when media transcode is hardware accelerated. |
| Ryzen all-in-one server | 8 cores, 16 threads, high clocks | Mixed 28 to 45 vCPU plan | Good balance for storage, apps, monitoring, and a few test guests. |
| Three mini PC cluster | 3 hosts with 6 to 8 cores each | HA capacity depends on two hosts | N+1 mode usually matters more than raw total cluster GHz. |
| Dual Xeon rack host | 24 older cores, lower IPC | Many idle VMs, less burst speed | Large core count helps density, but IPC adjustment prevents overrating it. |
| EPYC dense VM host | 32 or more modern cores | High vCPU count with guardrails | Great for labs, CI, and tenants when memory and IO keep pace. |
When assigning virtual CPU (vCPUs) to virtual machines (VMs), it is important to understand the difference between physical CPU and virtual CPU capacity. Physical CPU capacity refer to the processing power of the hardware that is contained within the server. Virtual CPU capacity, however, refer to the number of virtual CPUs that is assigned to the guest machines within the VM.
If you assigns virtual CPUs to VMs that contain more virtual CPUs than the physical CPU of the host server can provide to those VMs, the VMs will experience performance issue. Thus, to avoid these performance issues, the physical CPU capacity should be translated into the number of virtual CPUs that will be assigned to the VMs. To determine the number of virtual CPUs that should be assigned to each virtual machine, the person who perform such an assignment must consider the clock speed of the physical CPUs and the generation of those CPUs.
How to Assign vCPUs to Virtual Machines
A CPU that has a clock speed of three gigahertz (GHz) but that is of an older generation will perform less work per cycle than a CPU that has the same clock speed but that is of a newer generation. Thus, the person should assign virtual CPUs based on the number of physical CPUs of each generation that will be perform, since each generation can perform a different amount of work. If the number of virtual CPUs is not adjusted for the generational difference, the older hardware will appear to have more virtual CPUs than the physical hardware can provide.
Another factor to consider in determining the number of virtual CPUs that each machine will contain is the feature known as Simultaneous Multithreading (SMT). SMT allow for virtual machines to have additional threads that are assigned to each of the physical CPUs cores. However, the additional threads do not double the work that each physical CPU core can perform.
Instead, most virtual machines that use SMT experience only a twenty to forty percent performance increase when SMT is enabled. Thus, the virtual CPUs should not be calculated with these additional threads as they can lead to overcommitment of the physical CPUs. If the virtual CPUs is overcommitted to the physical CPUs, the performance of the VMs will drop when the VMs perform intensive task.
The type of work that each virtual machine will perform should be considered in determining the number of virtual CPUs to assign to each VM. Some types of work are idle most of the time, whereas other types of work require the physical CPUs of the host server to be dedicated to those virtual machines. The virtual CPUs should be assigned according to the heaviest workload of each virtual machine, not the lightest workload.
Thus, ensuring that the virtual CPUs are assigned according to the heaviest workload will ensure that the virtual machines have enough processing power to perform their work when they are active. Another factor to consider when assigning virtual CPUs to virtual machines is to provide a reserve of the physical CPUs for the hypervisor and the host machine. The hypervisor require some of the physical CPUs to dedicate to tasks like managing storage processes and virtual machines.
If not provided with a reserve of physical CPUs, the host machine may experience slowdowns during routine maintenance. Thus, providing a reserve of CPUs from the beginning will allow for better management of the virtual machines and avoid any slowdowns. The cluster in which the virtual machines is established will also impact the physical CPU capacity that can be provided to the virtual machines.
If one or more nodes within the cluster is to be reserved for maintenance or testing, the total physical CPU capacity of that cluster will be reduced. Thus, if the number of virtual machines within the cluster is to be determined, those factor should be considered within the calculations of the physical CPUs that each virtual machine will receive. By using a calculator, the number of virtual CPUs that can be provided to the virtual machines can be calculated.
The calculator will provide the physical CPUs, the guest virtual machines, and the oversubscription ratios of the virtual CPUs to the physical CPUs. The calculator will provide a ceiling for the number of virtual CPUs that can be provided to the virtual machines, but will not provide any guarantee of the performance of those virtual CPUs. The calculated number of virtual CPUs will help the server administrator to determine the actual limits of the virtual machines, as the limit may be reached in relation to the memory and storage of the virtual machines before the physical CPUs become the limiting factor.
Both the virtual CPUs that are calculated through the gigahertz speeds of the physical CPUs and the virtual CPUs calculated through the ratio of virtual CPUs to physical CPUs should be considered by the administrator. When calculating the number of virtual CPUs that will be assigned to each virtual machine, a person should focus upon the physical CPUs and the work that they can perform under heavy loads. The physical CPUs can be evaluated through the work that each core is able to perform and not through the advertised boost clock speed of those physical CPUs.
By determining the physical CPUs’ capacity to perform work under heavy loads, the person who is assigning those CPUs can adjust the workload of the virtual machines, the number of physical CPUs that will be reserved, and the oversubscription ratios of virtual CPUs to physical CPUs. Overall, calculating the number of virtual CPUs that will be assigned to each virtual machine will ensure that each virtual machine will run smooth when there are updates, backups, or new virtual machines adding to the data center at the same time.
