You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Adds an operator-configurable data transfer rate for a VPC's public/internet-facing gateway, independent of the per-tier rates that network offerings already control.
In addition to vpc, there is a change in precedence order for network rate for NIC and VRs being added in this PR.
For NICs:
Default used to select network rate based on below:
Bandwidth from compute offering > "vm.network.throttling.rate" config
Other NICs use:
Bandwidth from Network offering > "network.throttling.rate" config
Going forward Default NIC precedence will be used for all NICs
For VR's guest interface:
Old precendence:
Bandwidth from Network offering > "network.throttling.rate" config
New one:
Bandwidth from System offering > Network offering > "network.throttling.rate" config
Also persists the effective network rate per NIC and Network and exposes the effective network rate (bandwidth throttling) configured for NICs and guest networks in the API responses and UI.
Types of changes
Breaking change (fix or feature that would cause existing functionality to change)
New feature (non-breaking change which adds functionality)
Bug fix (non-breaking change which fixes an issue)
Enhancement (improves an existing feature and functionality)
Cleanup (Code refactoring and cleanup, that may add test cases)
Build/CI
Test (unit or integration test code)
Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale
Major
Minor
Bug Severity
BLOCKER
Critical
Major
Minor
Trivial
Screenshots (if appropriate):
How Has This Been Tested?
Verified end-to-end in a lab: API responses, the actual libvirt bandwidth configuration on the router, and measured live throughput across a multi-tier VPC confirming tiers correctly share one capped public-gateway.
How did you try to break this feature and the system with this change?
sudo87
changed the title
persist and expose effective network rate for NIC, Network and compute offering
Persist and expose effective network rate for NIC, Network and compute offering
Jun 3, 2026
- Add network_rate column to nics table (schema-42300to42400.sql)
- Add DB upgrade path: Upgrade42300to42400 registered in DatabaseUpgradeChecker
- Add network_rate field and getter/setter to NicVO
- Set network_rate on NicVO in NetworkOrchestrator.allocateNic() where rate
is already computed, eliminating secondary per-NIC update calls
- Add getNetworkRate() to Nic interface so ApiResponseHelper.createNicResponse
can call result.getNetworkRate() without casting or extra DB queries
- Add nic_network_rate to user_vm_view and UserVmJoinVO so listVirtualMachines
reads rate from the join without extra per-NIC findNicById calls
- Update UserVmJoinDaoImpl to use uvo.getNicNetworkRate() directly
- Expose network_rate in NicResponse as Integer (null = unlimited)
- Refresh NIC rates on VM start via refreshNicNetworkRates in UserVmManagerImpl
Copilot code review flagged this: newVpcOfferingResponse normalizes an
unset/zero public network rate to -1 for display, but UpdateVPCOfferingCmd
only accepts 0 as the unlimited sentinel and rejects any negative value.
The generic edit form pre-fills from the resource and resubmits unchanged
fields, so editing any VPC offering with an unlimited public rate failed.
Map -1 back to 0 before submitting an updateVPCOffering edit.
…entry is missing
createNetworkResponse only set networkRate when the 'networkrate'
network_details row existed. If it's missing (e.g. NetworkRateBackfill
failed for that network during upgrade), the field was left null and
silently omitted from the API response instead of falling back to -1,
unlike the equivalent NIC and VPC rate fields.
When a network offering changes, this refreshes only the network-level snapshot. Existing NIC rows keep their previous network_rate, while the replug path is limited to running VMware user VMs; other attached VMs/routers can therefore continue to expose the old rate through the new NIC API (and retain it until a later allocate/prepare). Recompute and persist the effective rate for each attached NIC as part of the offering update.
Pass explicit zero rate when creating VPC offerings
ui/src/views/offering/AddVpcOffering.vue:735
A value of 0 is the documented explicit unlimited setting, but this truthiness check omits it from createVPCOffering. On a zone with a nonzero vpc.public.network.throttling.rate, entering 0 therefore applies the zone cap instead of the requested unlimited offering. Test for presence rather than truthiness so zero is sent.
Document -1 representation for unset offering values
The response mapper now normalizes both an unset offering value and explicit 0 to -1, but this description still promises null for an unset value. That contradicts the actual API payload and the UI's -1 handling; document the -1 representation and clarify that an unset value may fall back to the zone/global default.
- importNic: persist the computed effective network rate on the NIC
instead of leaving network_rate NULL for imported NICs.
- restartVpc: only refresh the persisted public network rate snapshot
after a restart actually succeeds, not before either restart path
runs, so a failed restart can't leave a stale/premature snapshot.
- VpcOfferingResponse: fix stale doc string; the response normalizes
unset/unlimited to -1, not null.
Updating the network offering changes the persisted network-level rate here, but it never recomputes nics.network_rate for NICs already attached to this network. This leaves API responses and the applied VR bandwidth stale; in particular, a router guest NIC whose system offering has no rate should now fall back to the new network-offering rate, but will continue to expose/use its old persisted value. Update the affected NICs as part of the offering change or make the reconfiguration path persist the recomputed rate.
@Parameter(name = ApiConstants.PUBLIC_NETWORK_RATE, type = CommandType.INTEGER,
since = "4.24.0",
description = "Data transfer rate in megabits per second allowed for a VPC's public gateway (internet-facing network), created with this offering. Use 0 for unlimited")
The reason will be displayed to describe this comment to others. Learn more.
normally we do not change the properties of existing offerings, for example cpu/memor of service offering, size of disk offering, supported network services of network offering,
This branch has not been deployed
No deployments
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
sudo87
changed the title
DaanHoogland
moved this from Backlog
to conflict/waiting for author
in CloudStack Testing
Description
Adds an operator-configurable data transfer rate for a VPC's public/internet-facing gateway, independent of the per-tier rates that network offerings already control.
Precedence:
In addition to vpc, there is a change in precedence order for network rate for NIC and VRs being added in this PR.
For NICs:
Default used to select network rate based on below:
Other NICs use:
Going forward Default NIC precedence will be used for all NICs
For VR's guest interface:
Old precendence:
New one:
Also persists the effective network rate per NIC and Network and exposes the effective network rate (bandwidth throttling) configured for NICs and guest networks in the API responses and UI.
Types of changes
Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale
Bug Severity
Screenshots (if appropriate):
How Has This Been Tested?
Verified end-to-end in a lab: API responses, the actual libvirt bandwidth configuration on the router, and measured live throughput across a multi-tier VPC confirming tiers correctly share one capped public-gateway.
How did you try to break this feature and the system with this change?