ResourceQuota is used to limit the usage of resources within a namespace. It helps administrators control and restrict the allocation of cluster resources to ensure fairness and controlled resource distribution among namespaces.
In Harvester, ResourceQuota can define usage limits for the following resources:
- CPU: Limits compute resource usage, including CPU cores and CPU time.
- Memory: Limits the usage of memory resources in bytes or other recognizable memory units.
Set ResourceQuota via Rancher
In the Rancher UI, administrators can configure resource quotas for namespaces through the following steps:
- Click the hamburger menu and choose the Virtualization Management tab.
- Choose one of the clusters and go to Projects/Namespaces > Create Project.
- Specify the desired project Name. Next, go to the Resource Quotas tab and select the Add Resource option. Within the Resource Type field, select either CPU Limit or Memory Limit and define the Project Limit and Namespace Default Limit values.
You can configure the Namespace limits as follows:
- Find the newly created project, and select Create Namespace.
- Specify the desired namespace Name, and adjust the limits.
- Complete the process by selecting Create.
Overhead memory of virtual machine
Upon creating a virtual machine (VM), the VM controller seamlessly incorporates overhead resources into the VM's configuration. These additional resources intend to guarantee the consistent and uninterrupted functioning of the VM. It's important to note that configuring memory limits requires a higher memory reservation due to the inclusion of these overhead resources.
For example, consider the creation of a new VM with the following configuration:
- CPU: 8 cores
- Memory: 16Gi
The operating system, either Linux or Windows, does not affect overhead calculations.
Memory Overhead is calculated in the following sections:
- Memory PageTables Overhead: This accounts for one bit for every 512b RAM size. For instance, a memory of 16Gi requires an overhead of 32Mi.
- VM Fixed Overhead: This consists of several components:
VirtLauncherMonitorOverhead: 25Mi (the
psRSS for virt-launcher-monitor)
VirtLauncherOverhead: 75Mi (the
psRSS for the virt-launcher process)
VirtlogdOverhead: 17Mi (the
psRSS for virtlogd)
LibvirtdOverhead: 33Mi (the
psRSS for libvirtd)
QemuOverhead: 30Mi (the
psRSS for qemu, minus the RAM of its (stressed) guest, minus the virtual page table)
- 8Mi per CPU (vCPU) Overhead: Additionally, 8Mi of overhead per vCPU is added, along with a fixed 8Mi overhead for IOThread.
- Extra Added Overhead: This encompasses various factors like video RAM overhead and architecture overhead. Refer to Additional Overhead for further details.
This calculation demonstrates that the VM instance necessitates an additional memory overhead of approximately 276Mi.
For more information, see Memory Overhead.
For more information on how the memory overhead is calculated in Kubevirt, refer to kubevirt/pkg/virt-controller/services/template.go.
Automatic adjustment of ResourceQuota during migration
When the allocated resource quota controlled by the
ResourceQuota object reaches its limit, migrating a VM becomes unfeasible. The migration process automatically creates a new pod mirroring the resource requirements of the source VM. If these pod creation prerequisites surpass the defined quota, the migration operation cannot proceed.
Available as of v1.2.0
In Harvester, the
ResourceQuota values will dynamically expand ahead of migration to accommodate the resource needs of the target virtual machine. After migration, the ResourceQuotas will be reinstated to their prior configurations.
Please be aware of the following constrains of the automatic resizing of
ResourceQuotacannot be changed during VM migration.
- When raising the
ResourceQuotavalue, if you create, start, or restore other VMs, Harvester will verify if the resources are sufficient based on the original
ResourceQuota. If the conditions are not met, the system will alert that the migration process is not feasible.
- After expanding
ResourceQuota, potential resource contention may occur between non-VM pods and VM pods, leading to migration failures. Therefore, deploying custom container workloads and VMs to the same namespace is not recommended.
- Due to the concurrent limitation of the webhook validator, the VM controller will execute a secondary validation to confirm resource sufficiency. If the resource is insufficient, it will auto config the VM's
Halted, and a new annotation
harvesterhci.io/insufficient-resource-quotawill be added to the VM object, informing you that the VM was shut down due to insufficient resources.