A vCPU, or virtual CPU, is a virtual processor that a hypervisor presents to a virtual machine, which the guest operating system sees and uses exactly like a physical processor core. In virtualization, a vCPU is not a fixed piece of silicon: it is a schedulable execution context that the hypervisor runs on whichever physical core or hardware thread is available at each moment.
In public cloud offerings, the vCPU is also the unit in which compute capacity is sold. On most x86 instance types, one vCPU corresponds to one hardware thread, meaning half of a physical core with simultaneous multithreading enabled. This convention varies between providers and processor families, so comparing instance sizes by vCPU count alone can be misleading.
How a vCPU runs on physical hardware
Each vCPU is represented in the hypervisor as a thread or schedulable entity. When the guest wants to execute code, the hypervisor’s scheduler places that vCPU on a free logical processor of the host, and hardware virtualization extensions such as Intel VT-x and AMD-V let the guest run its instructions directly on the processor at near-native speed. Only privileged operations cause a VM exit, in which control passes briefly to the hypervisor.
Because vCPUs are scheduled rather than permanently assigned, a host can run more vCPUs than it has logical processors. When all vCPUs want to run at the same time, some must wait. That waiting time is visible inside Linux guests as steal time, the share of time a vCPU was ready but the hypervisor was running something else.
| Layer | What it is | Typical count on one server |
|---|---|---|
| Socket | Physical processor package | 1 to 2, sometimes 4 |
| Physical core | Independent execution unit | 8 to 128 per socket |
| Hardware thread | Logical processor via simultaneous multithreading | Usually 2 per core |
| vCPU | Virtual processor seen by a guest | From one up to hundreds per host |
Overcommitment and the vCPU-to-core ratio
The vCPU-to-physical-core ratio describes how heavily a host is overcommitted. Most virtual machines are idle much of the time, so allocating more vCPUs than cores is normal and economical. The acceptable ratio depends on how busy and how latency-sensitive the workloads are.
| Workload type | Common ratio | Reason |
|---|---|---|
| Latency-critical databases | 1:1, often with pinning | Predictable response times |
| General production servers | 2:1 to 4:1 | Moderate load with headroom |
| Virtual desktops | 4:1 to 10:1 | Interactive, mostly idle users |
| Development and test | Up to 10:1 or more | Low utilization, cost matters most |
These ratios are starting points. The deciding metric is CPU ready or steal time: values that stay above a few percent indicate that vCPUs are waiting too often and that the host is overcommitted for its actual load.
vCPU compared with related processor terms
Different terms describe processing capacity at different layers, and confusing them leads to incorrect sizing. The table summarizes how a vCPU relates to its neighbors in virtualization.
| Term | Definition | Relation to vCPU |
|---|---|---|
| Physical core | Hardware execution unit | Hosts one or more vCPUs over time |
| Hardware thread | Logical processor sharing a core | Commonly equal to one cloud vCPU |
| Virtual machine | Complete virtual computer | Contains one or more vCPUs |
| Hypervisor | Software that runs virtual machines | Schedules vCPUs onto hardware |
| Burstable vCPU | vCPU with a baseline share and credits | Full speed only for limited periods |
Two virtual machines with four vCPUs each can therefore perform very differently. One may run on dedicated cores of a modern processor, while the other shares hardware threads on an older or heavily loaded host, or uses a burstable instance that falls back to a low baseline when its credits run out.
Sizing virtual machines by vCPU
The common instinct is to give a virtual machine many vCPUs to be safe. With hypervisors that schedule all vCPUs of a machine in close coordination, this can backfire: a large virtual machine must wait for enough free logical processors, and idle vCPUs still consume scheduling overhead. Right-sizing usually means starting small and adding vCPUs when measurements justify it.
| Observation | Likely meaning | Action |
|---|---|---|
| Guest CPU constantly near 100% | Too few vCPUs for the load | Add vCPUs or optimize the code |
| Guest CPU low, high steal time | Host contention | Move the VM or reduce host overcommit |
| Many vCPUs, low average use | Oversized machine | Reduce vCPUs to improve scheduling |
| Licensing billed per core | Each vCPU may count | Size to the minimum the workload needs |
- Keep large virtual machines within one NUMA node where possible, so memory access stays local.
- Use CPU pinning only for workloads that truly need it, because it reduces scheduling flexibility.
- Check whether an application scales across cores at all; a single-threaded process gains nothing from extra vCPUs.
Limitations and common misunderstandings
The most frequent misunderstanding is that a vCPU equals a core. On many platforms it equals a hardware thread, and two threads on one core share execution resources, so two vCPUs usually deliver less than twice the throughput of one full core for compute-heavy work.
Performance also depends on the processor generation, clock speed and cache of the host, which the vCPU count does not reveal. Security considerations matter too: side-channel vulnerabilities in shared cores have led some platforms to avoid placing vCPUs of different tenants on sibling threads of the same core.
Understanding it simply
A vCPU is like a seat at a shared desk in an office. The company rents a certain number of seats, and the building manager makes sure there is somewhere to sit whenever work needs doing.
Most people are not at their desks all the time, so the building can rent out more seats than it physically has. That works well until everyone shows up at once and some must wait. More seats do not always mean more work done, because the speed of each desk and how crowded the building is matter just as much.
Applied in practice
A company runs a virtualization cluster of hosts with 32 physical cores and 64 hardware threads each. Its application servers were given 16 vCPUs each “for safety”, yet monitoring showed they averaged only 15% CPU usage while the hosts reported steal time of 8 to 10% during business hours.
The administrators reduced the application servers to 6 vCPUs, kept the database virtual machines at 8 vCPUs on dedicated cores within one NUMA node, and limited the overall ratio to 3 vCPUs per physical core. Steal time dropped below 2%, response times of the application became more consistent, and the same hosts could accommodate several additional virtual machines. Fewer, well-sized vCPUs delivered better performance than many oversized ones.