The maximum number of tiers per VPC is set by the global setting vpc.max.networks, and changing it requires a management server restart.
Further, the error message that is returned when a user hits their limit is uninformative:
Request failed (530): Internal error executing command.
The error in the event list is:
Error while creating network
The error in the logs on the management servers are:
WARN [c.c.n.v.VpcManagerImpl] Failed to create a new VPC Guest Network because the number of
networks per VPC has reached its maximum capacity of [3]. Increase it by modifying global
config [vpc.max.networks].
ERROR [c.c.a.ApiServer] unhandled exception executing api command: ...
CloudRuntimeException: Number of networks per VPC cannot surpass [3].
This is a feature request to make the per-VPC tier (network) limit configurable at the domain/account level instead of only as the global setting vpc.max.networks, and to improve the generic/uninformative API error returned when the limit is hit.
📊 Assessment
Dimension
Value
Reasoning
Type
type:new-feature
Requests new configurability (per-domain/account limit) plus an improved error message, not a fix to existing broken behavior.
Component
component:vpc, component:networking
Directly relates to VPC tier/network creation limits (VpcManagerImpl, vpc.max.networks).
The error-message improvement (propagate CloudRuntimeException message instead of generic "Internal error executing command") is fairly self-contained and could be tackled by an agent. However, making the VPC tier limit per-domain/account configurable is a larger design change (new setting scope, API params, UI, docs) requiring maintainer/architecture input before implementation.
🔗 Similar issues
No similar open issues were found in a search for related terms (vpc.max.networks, VPC tier limit).
💡 Notes and suggestions
Two distinct asks are bundled here; maintainers may want to split them:
Configurability: Promote vpc.max.networks from a global-only setting to one overridable per domain/account, similar to how VPC count limits already work (max.account.vpcs style per-domain/account overrides).
Error UX: The API currently surfaces a generic Request failed (530): Internal error executing command to the caller while the real cause (CloudRuntimeException: Number of networks per VPC cannot surpass [3]) is only visible in management server logs. This should be a quick win — propagate the specific exception message to the API response, similar to other resource-limit checks in VpcManagerImpl.
Relevant code: VpcManagerImpl (network/tier creation path) and the vpc.max.networks global config definition.
Suggest confirming with the reporter whether they need both items or primarily the error-message fix, which is lower risk and could be a good first contribution.
changed the title [-]Feature: Allow per-Domain/Account VPC tier limits[/-][+]Feature: Make vpc.max.networks dynamic and improve the limit-reached error[/+]on Oct 10, 2026
I've changed the scope of this issue. Per-account/domain values aren't needed: the cap exists to handle the VR's NIC capacity which is the same for every tenant, and VPC tiers already count toward the account and domain guest network limits. This now covers making the setting dynamic and improving the error. See #14373.
Activity
github-actions commented on Oct 9, 2026
🎯 Triage report
This is a feature request to make the per-VPC tier (network) limit configurable at the domain/account level instead of only as the global setting vpc.max.networks, and to improve the generic/uninformative API error returned when the limit is hit.
📊 Assessment
🔗 Similar issues
No similar open issues were found in a search for related terms (vpc.max.networks, VPC tier limit).
💡 Notes and suggestions- Two distinct asks are bundled here; maintainers may want to split them:
- Configurability: Promote vpc.max.networks from a global-only setting to one overridable per domain/account, similar to how VPC count limits already work (max.account.vpcs style per-domain/account overrides).
- Error UX: The API currently surfaces a generic Request failed (530): Internal error executing command to the caller while the real cause (CloudRuntimeException: Number of networks per VPC cannot surpass [3]) is only visible in management server logs. This should be a quick win — propagate the specific exception message to the API response, similar to other resource-limit checks in VpcManagerImpl.
- Relevant code: VpcManagerImpl (network/tier creation path) and the vpc.max.networks global config definition.
- Suggest confirming with the reporter whether they need both items or primarily the error-message fix, which is lower risk and could be a good first contribution.
Add this agentic workflows to your repoTo install this agentic workflow, run
MitchDrage commented on Oct 10, 2026
I've changed the scope of this issue. Per-account/domain values aren't needed: the cap exists to handle the VR's NIC capacity which is the same for every tenant, and VPC tiers already count toward the account and domain guest network limits. This now covers making the setting dynamic and improving the error. See #14373.