The KVM hypervisor supports vCPU overcommitment. vCPU overcommitment means assigning more virtual CPUs to virtual machines than are physically available on the host.
The goal of vCPU overcommitment is to optimize resource utilization, as most processes in virtual machines rarely require continuous use of all allocated resources. If each VM uses only a portion of its allocated resources and resource demands vary over time, it is safe to redistribute available physical cores among a larger number of VMs.
Excessive overcommitment can negatively impact performance. If running VMs simultaneously attempt to use all their allocated resources, those VMs start competing for physical cores — causing high latency and reduced performance. Therefore, carefully evaluate workloads and consider potential risks before applying overcommitment.
Allocating more vCPUs to a single VM than physical cores available on the host will also decline performance, as applications in the guest OS receive less CPU time than required. For better performance, assign each VM only the number of vCPUs needed to run its workloads.
Using SMP (Symmetric Multi-Processing)-enabled virtual machines causes additional CPU overhead. CPU overcommitment increases this overhead, as time slot slicing to share physical resources among guest OSes slows down inter-processor communication within each guest OS. This extra overhead grows with the number of vCPUs per guest or with higher overcommitment ratios.
vCPU overcommitment is more effective when multiple VMs with a small number of vCPUs each (compared to the amount of host’s physical cores) are deployed on a single host. The KVM hypervisor can safely run guest workloads under 100% load at a ratio of 5 vCPUs per physical core (5:1 overcommitment ratio). The hypervisor evenly distributes load by switching between VMs.
Do not use more than 10 vCPUs per each physical core (10:1 overcommitment ratio).
|
Warning
|
Application stability decreases in overcommitted environments for workloads that consume 100% of available memory or CPU resources. Do not use memory or vCPU overcommitment in production without prior thorough testing, as the optimal vCPU overcommitment ratio and SMP configuration depend on the specific workload type. |
Virtual machines running on the KVM hypervisor do not have dedicated blocks of physical RAM. Instead, each guest VM operates as a Linux process, and the Linux kernel on the host allocates memory on demand. The host’s memory manager moves VM memory between physical RAM and swap space.
To use memory overcommitment, ensure sufficient swap space is allocated on the host to accommodate all VMs — along with enough memory for host processes. The host OS requires a minimum of 4 GB of RAM plus 4 GB of swap space.
Overcommitment does not work with all virtual machines but can be effective when running multiple identical VMs with KSM (Kernel Same-page Merging).
Overcommitment is not a solution for general memory shortages. To avoid memory exhaustion, consider allocating less memory per VM, adding more physical RAM to the host, or using swap space.
A VM will run slower if it frequently uses swap. Additionally, overcommitment can lead to out-of-memory (OOM) conditions, causing the Linux kernel to terminate critical system processes. Test everything thoroughly before enabling overcommitment.
|
Warning
|
Memory overcommitment is not supported when host devices are assigned directly to a virtual machine. This is because device assignment requires all VM memory to be statically pre-allocated to ensure direct memory access (DMA) with the assigned device. |