vCPU overcommit vs dedicated vCPU and RAM: what an IaaS offer guarantees and how to check it

Guaranteed vs overcommitted vCPU and RAM in an IaaS offer

Guaranteed vCPU and RAM in an IaaS offer means that the CPU capacity and memory you order are held for your VMs, so other tenants’ load cannot take them away. Overcommitted means the provider places more vCPUs on a host than it has physical cores, or more VM memory than the host has RAM, on the expectation that the VMs do not all peak at the same time. When they do, the hypervisor divides the cores between the waiting vCPUs and reclaims memory from the VMs, and another tenant’s load on the same host, the noisy neighbour, slows your VMs.

Shared and dedicated vCPU are terms from hosting offers; vSphere has no setting by either name. On a vSphere platform what you get depends on the hosts’ vCPU-to-core ratio, on reservations, limits and shares, and on how far the hosts have to reclaim memory. Our comparison of IaaS, private cloud and hybrid covers when hosts dedicated to one organisation fit better, and our guide to vSphere as a service in the EU what a hosted service includes.

Our IaaS gives you guaranteed vCPU, RAM and storage on vSphere, with CPU and RAM not shared with other clients, at a fixed monthly cost invoiced in euros. Send us the VMs you would move, with vCPU and RAM per VM.

vCPU overcommitment and the vCPU-to-core ratio

When CPU is overcommitted, an ESXi host, called ESX in the version 9 documentation, time-slices its physical processors so that each VM runs as if it had its configured vCPUs. With default settings every VM receives an equal share of CPU per vCPU (Broadcom’s vSphere 8.0 and 9.1 documentation, as of September 2026). A vCPU is therefore scheduled time on a physical processor rather than a processor of its own, and the vCPU-to-core ratio, the vCPUs of the powered-on VMs divided by the host’s physical cores, gives the average number of vCPUs that share each core.

We found no Broadcom document that sets a general target ratio. Broadcom’s Performance Best Practices for vSphere 9.0 (revision 20250731) say that in most environments ESX allows significant CPU overcommitment without impacting VM performance, while a CPU-saturated host can slow some or all of its VMs significantly. For its GemFire product, Broadcom’s KB 376609 advises one physical core per vCPU to reduce or eliminate steal time. Measuring on the host whether a ratio is too high is covered in our guide to CPU ready and the vCPU ratio.

Ask whether the provider counts physical cores or hyper-threads. Per Broadcom’s vSphere 8.0 documentation, an application on one logical processor of a busy core can expect “slightly more than half of the throughput” it would get alone on a core without hyper-threading, and with two threads per core a ratio counted against threads reads half as high as the same load counted against cores. Where an offer calls a vCPU dedicated, ask whether that means reserved capacity, a host without other tenants or a vCPU pinned to a core; Broadcom advises against manual CPU affinity, which can interfere with the host’s ability to meet a VM’s reservations and shares.

Memory overcommitment: page sharing, ballooning, compression, swapping

Broadcom’s vSphere 8.0 and 9.1 documentation (September 2026) uses the term in two ways. Its example calls a host with 2 GB of RAM and four 1 GB VMs overcommitted, as this article does, while its definition ties overcommitment to the VMs’ “combined working memory footprint” exceeding the host’s memory. The Performance Best Practices for vSphere 9.0 describe five mechanisms that reduce the physical memory each VM needs: page sharing, ballooning, compression, swapping to a host cache and regular swapping, the last four used in turn as host memory runs short.

Transparent page sharing removes duplicate memory pages, but since vSphere 6.0, and in patches to some earlier releases, only within each VM by default. Broadcom’s KB 323624 explains that each VM’s salt defaults to its unique vc.uuid, so VMs share pages only if an administrator gives them a common salt or changes the host setting Mem.ShareForceSalting. The vSphere 8.0 and 9.1 documentation cites security concerns. The 9.0 best practices add that ESX does not share large pages, so with large pages, sharing might not start until memory is overcommitted far enough for ESX to break them into small pages.

The balloon driver vmmemctl makes the guest operating system give up the pages it values least and, if necessary, swap them to its own virtual disk, so where memory is overcommitted Broadcom asks for guest swap space at least as large as the VM’s configured memory minus its reservation. Before the host swaps a page, it tries to compress it and keeps pages that compress to 2 KB or less in a cache in memory; compression is on by default. Host swapping then happens without the guest’s involvement. The 9.0 best practices advise against overcommitting memory to the point where host swapping swaps out active pages, and note that reserving a VM’s entire memory eliminates host swapping for that VM.

The vSphere 9 documentation also describes Memory Tiering over NVMe, which uses local NVMe devices as a slower memory tier behind DRAM. It is deactivated by default, and the vSphere 9.1 documentation (29 September 2026) limits the NVMe tier by default to the size of DRAM, up to 4 TB. On such a host, reservations can be split between DRAM and NVMe when the reserved VMs consume more memory than DRAM holds, so a reservation alone does not mean DRAM.

Reservations, limits and shares in vSphere

A reservation is the “guaranteed minimum allocation” for a VM, set in MHz and MB. vCenter Server or ESXi powers a VM on only if enough unreserved capacity covers its reservation, and the host keeps that amount available under heavy load. Reserved capacity that a VM does not use stays available to others.

When memory is overcommitted, each VM receives an amount between its reservation and its limit, set by its shares and its recent working set, so only the reservation is held for it. Broadcom’s 9.0 best practices add that reservations reduce the number of VMs a system can run.

Broadcom TechDocs: vSphere 8.0 Resource Management (updated 2 to 16 September 2026) and vSphere 9.1 Resource Management (29 September 2026).

Broadcom says that in most cases no limit is needed, and esxtop counts the time a VM is held at its CPU limit as part of its ready time.

Resource pools, expandable reservations and admission control

A provider running several tenants on one cluster can give each a resource pool, a partition of the cluster’s CPU and memory with its own reservation, limit and shares, which Broadcom says keeps allocation changes in one pool from unfairly affecting unrelated pools. A pool reservation holds capacity for the tenant as a whole rather than for any one VM, and the VMs inside compete for it by their shares.

With the default reservation type, Expandable, admission control checks the pool and its parent and can borrow recursively from expandable ancestors, which Broadcom says offers more flexibility but “provides less protection”. A Fixed pool admits a VM only from its own unreserved capacity. Each power-on is checked against unreserved capacity, overhead memory included, and if that falls short, vSphere shows an Insufficient Resources warning instead of starting the VM. vSphere HA admission control, a separate cluster setting that holds capacity for restarting VMs after a host failure, is explained in our guide to host consolidation.

Steal time: how a tenant sees contention inside a Linux VM

Linux reports CPU time that the hypervisor takes from a guest as steal time. The kernel’s /proc/stat documentation calls it “involuntary wait”, and the procps tools top and vmstat show it as st.

For vSphere, Broadcom’s KB 376609, written for its GemFire product, says that steal time reporting “is not enabled automatically” and names the VM option stealclock.enable = "TRUE". Unless the provider confirms the option, a zero in the st column does not show that your VMs never waited. The same KB treats CPU ready as vSphere’s name for steal time, so ask the provider for the host’s ready figures.

Ballooning can make the guest swap to its own disk, which vmstat shows in its si and so columns, while host swapping does not appear there. Broadcom’s KB 438023 for ESXi 8.0 reads non-zero ballooning as host memory pressure and host swapping as contention usually severe enough to impact performance, and notes that ESXi cannot see the guest’s own swapping. Where the host makes these statistics available, VMware Tools shows them in the guest: per VMware’s open-vm-tools source, vmware-toolbox-cmd stat balloon and vmware-toolbox-cmd stat swap print the VM’s ballooned memory and the memory the host has swapped out. Broadcom’s KB 375842 uses vmware-toolbox-cmd stat memres and vmware-toolbox-cmd stat cpures to print a VM’s memory and CPU reservation. A zero reservation does not prove overcommitment, since a provider can also keep spare capacity by sizing its hosts.

What to ask an IaaS provider about vCPU and RAM

Broadcom TechDocs for vSphere 8.0 and 9.1 (August and September 2026); Performance Best Practices for VMware vSphere 9.0 (revision 20250731); Broadcom KB 323624, 376609 and 438023; VMware’s open-vm-tools source; Linux kernel and procps-ng documentation (October 2026).

To check an offer before you sign:

1. Ask for the vCPU-to-core ratio of your hosts, counted against physical cores, and their configured memory against RAM.
2. Ask whether reservations per VM or per pool hold your vCPU and RAM, how many MHz per vCPU they cover, whether the pool is Fixed or Expandable, and whether limits apply.
3. On vSphere 9 hosts, ask whether Memory Tiering is active and whether the offer’s RAM is DRAM.
4. Ask which contention figures you will see, such as ready time per vCPU and ballooned and swapped memory per VM, at what interval, whether stealclock is set and whether VMware Tools statistics reach the guest.
5. Read whether the service level agreement covers only availability or also CPU and memory allocation, and how a shortfall is measured.
6. Before migration, run a representative system at peak load on the platform and compare steal time where it is reported, guest swapping and response times with your current platform.

Capacity is ordered per VM, so an oversized VM keeps its excess vCPU and RAM after the move; our guide to waste in a vSphere estate shows how to find such VMs.

We provide test access to the platform before migration. Tell us which systems you would test first and which figures you compare today.

What we do

Under our EU Cloud service we host guaranteed compute or a private cloud in Baltneta’s Tier-3 data centres in Lithuania, and data and backups stay in the EU. The IaaS option runs on the VMware vSphere platform with CPU and RAM guaranteed and not shared with other clients, a self-service portal, snapshots and Veeam backup. A configuration with guaranteed resources has a fixed monthly cost, invoiced in euros, that changes only when you change the configuration yourself. Our engineering partner Vixen.UNO moves systems step by step, in agreed maintenance windows with a rollback plan, and support runs under an SLA. The first call is free of charge, and the price of the technical assessment is fixed before work begins.

FAQ