Skip to content

Explain the details to quota compensation #981

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
w13915984028 wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Explain the details to quota compensation #981

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
28 changes: 28 additions & 0 deletions docs/rancher/resource-quota.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -118,3 +118,31 @@ When a `ResourceQuota` object has the annotation `harvesterhci.io/skipResourceQu
You must set the annotation before the migration starts. If the annotation is set while the values are already being adjusted, Harvester is unable to automatically restore the previous configuration.

:::

## ResourceQuota Compensation During Migration
Copy link
Copy Markdown
Contributor

@ihcsim ihcsim May 11, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
## ResourceQuota Compensation During Migration
## ResourceQuota Automatic Adjustment During Migration

here and elsewhere, consider using "adjustment" instead of "compensation"; the latter is more commonly used in the context of employment, insurance, lawsuit etc.


_Available as of v1.8.0_

If you adjust the [VM Overhead Memory](#overhead-memory-of-virtual-machine) cluster settings while a Virtual Machine (VM) is already running, the VM's memory footprint may increase. This can cause issues during Live Migration, as the target node must instantiate a new VM instance that requires more memory than the original.
Copy link
Copy Markdown
Contributor

@ihcsim ihcsim May 11, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
If you adjust the [VM Overhead Memory](#overhead-memory-of-virtual-machine) cluster settings while a Virtual Machine (VM) is already running, the VM's memory footprint may increase. This can cause issues during Live Migration, as the target node must instantiate a new VM instance that requires more memory than the original.
If you adjust the [VM Overhead Memory](#overhead-memory-of-virtual-machine) cluster settings while a Virtual Machine (VM) is already running, the VM's memory footprint may increase. This can cause issues during live migration, as the target node must instantiate a new VM instance that requires more memory than the original.


When the destination Namespace has a strict ResourceQuota, the migration may be blocked because the cumulative memory usage of both the source and target VMs temporarily exceeds the quota even when the quota has already been scaled up automatically.
Copy link
Copy Markdown
Contributor

@ihcsim ihcsim May 11, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
When the destination Namespace has a strict ResourceQuota, the migration may be blocked because the cumulative memory usage of both the source and target VMs temporarily exceeds the quota even when the quota has already been scaled up automatically.
When the destination namespace has a strict ResourceQuota, the migration may be blocked because the cumulative memory usage of both the source and target VMs temporarily exceeds the quota even when the quota has already been scaled up automatically.


### Automatic Resolution
Copy link
Copy Markdown
Contributor

@ihcsim ihcsim May 11, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
### Automatic Resolution

probably don't need this title if you just add the word "Automatic" to the main heading as suggested above


Harvester automatically manages this bottleneck through the following workflow:

**Detection**: Harvester identifies when a migration is specifically blocked by ResourceQuota limitations.

**Delta Compensation**: The system automatically injects a temporary "quota compensation" (the delta between the current limit and current usage plus the migration requirements) to allow the migration to proceed.
Copy link
Copy Markdown
Contributor

@ihcsim ihcsim May 11, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
**Delta Compensation**: The system automatically injects a temporary "quota compensation" (the delta between the current limit and current usage plus the migration requirements) to allow the migration to proceed.
**Delta Compensation**: The system automatically calculates a temporary "quota compensation" (the delta between the current limit and current usage plus the migration requirements) to allow the migration to proceed.


**Cleanup**: Once the migration is complete (whether it succeeded or failed), Harvester removes the temporary compensation, returning the ResourceQuota to its original state.
Copy link
Copy Markdown
Contributor

@ihcsim ihcsim May 11, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
**Cleanup**: Once the migration is complete (whether it succeeded or failed), Harvester removes the temporary compensation, returning the ResourceQuota to its original state.
**Cleanup**: Once the migration is completed (whether it succeeded or failed), Harvester removes the temporary compensation, returning the ResourceQuota to its original state.


:::info important

- This feature acts as an automatic workaround, ensuring that global policy changes (like memory overhead adjustments) do not accidentally "lock" your VMs to their current nodes.
Copy link
Copy Markdown
Contributor

@ihcsim ihcsim May 11, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- This feature acts as an automatic workaround, ensuring that global policy changes (like memory overhead adjustments) do not accidentally "lock" your VMs to their current nodes.
- This automated feature prevents global policy changes like memory overhead adjustments from accidentally blocking VMs live migration.


- The compensation applies only to already running VMs. If a running VM is stopped and then restarted, its resource allocation is strictly governed by the original quota. As a result, a VM that was previously running may fail to "cold boot" if the overhead is increased while the ResourceQuota remains unchanged.
Copy link
Copy Markdown
Contributor

@ihcsim ihcsim May 11, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- The compensation applies only to already running VMs. If a running VM is stopped and then restarted, its resource allocation is strictly governed by the original quota. As a result, a VM that was previously running may fail to "cold boot" if the overhead is increased while the ResourceQuota remains unchanged.
- The compensation applies only to already running VMs. If a running VM is stopped and then restarted, no automatic quota adjustment will be triggered. As a result, the VM may fail to start if its overhead requirement exceeds the associated ResourceQuota.


- To avoid reliance on this automatic compensation, the best practice is to adjust overhead settings and ResourceQuotas simultaneously. Ultimately, there is no difference between a live migration and a "cold reboot" regarding final quota control; both must eventually fit within the defined namespace limits.
Comment on lines +128 to +146

:::
Loading