Red Hat documents guest CPU topology as sockets × cores × threads; total vCPU count is not the same concept as physical host cores.
Understand vCPU, physical cores and threads together with topology, oversubscription, pinning and single-core performance.
Red Hat documents guest CPU topology as sockets × cores × threads; total vCPU count is not the same concept as physical host cores.
The same 4 vCPU label does not guarantee identical performance across providers because host CPU, frequency policy, overcommit and scheduling can differ.
A physical core is real silicon execution capacity. SMT/Hyper-Threading exposes multiple logical CPUs per core. A vCPU is the scheduler-visible processor unit exposed by the hypervisor to a guest VM.
Do not assume 1 vCPU equals 1 physical core unless the service contract explicitly states it. A vCPU can be scheduled onto logical host processors; dedicated or pinned CPU products can provide stricter mapping.
On Linux, `lscpu` shows sockets, cores per socket, threads per core and model name. Hypervisors can mask CPU models or present virtual topology, so this does not prove the full physical host architecture.
On Windows, `Get-CimInstance Win32_Processor` and Task Manager show the topology exposed to the guest, not necessarily raw host topology.
lscpu
nproc
grep -E 'model name|cpu MHz' /proc/cpuinfo | head
Get-CimInstance Win32_Processor | Select-Object Name,NumberOfCores,NumberOfLogicalProcessors,MaxClockSpeed
vCPU count is capacity potential, not per-core speed. Four shared vCPUs on an old low-frequency host can lose in request latency to two faster vCPUs. WordPress/PHP and some game-server threads are sensitive to single-core latency.
Compilation, encoding, many workers and parallel containers can benefit from additional vCPUs. The workload's parallelism determines value.
A host can expose more guest vCPUs than physical logical CPUs. This is not automatically bad because most VMs are not saturated all the time. Problems appear when many guests demand CPU simultaneously and scheduling delays rise.
On Linux, %steal is one useful signal; the dedicated CPU-steal guide covers it in depth.
If a provider says dedicated CPU, ask what is guaranteed: a physical core, logical thread, pinned pCPU or just scheduler quota. Without a technical definition the term is not a universal standard.
Ask the CPU model/generation, shared vs dedicated policy, quota/burst policy, fair-use/steal expectations, nested virtualization, CPU masking and scaling behavior. These answers are more useful than the 4 vCPU label alone.
| Term | Meaning | Wrong assumption |
|---|---|---|
| Physical Core | Physical execution core | Every vCPU equals one |
| SMT Thread | Logical CPU on a core | Same as another physical core |
| vCPU | Virtual CPU exposed to guest | Performance is provider-independent |
Do not buy based on one benchmark, port label or CPU brand. Repeat tests at different times, avoid destructive storage tests on production data, and verify provider resource/fair-use policies in writing.
It depends on the provider's hypervisor and resource policy; 4 vCPU alone does not guarantee four physical cores.
No. SMT threads share core resources and gains depend on workload.
Share your software stack, concurrency, storage/database load and target region; size the server around the real bottleneck rather than RAM/core labels alone.