problem
After upgrading KVM hosts from 4.20.1.0 to 4.21.0.0, the KVM agent no longer respects the pre-created Linux bridge defined by the traffic label for Storage traffic when a VLAN is configured. Doesn't work either on a clean install of 4.21.0.0.
Instead, the agent automatically creates/uses a new bridge named br- (e.g. brbond0-33).
On 4.20.1.0 with the exact same host configuration, the agent attaches Storage VLAN NICs to the expected cloudbr2 bridge.
This regression might have been introduced by PR #11245
“kvm, ui: fix interface when using vlan subnet for storage traffic type”
(commit diff)
versions
CloudStack 4.21.0.0 (KVM agent) upgraded from Cloudstack 4.20.1.0
Zone type: Core
Network type: Basic
Hypervisor: KVM x86_64
Hosts: Ubuntu 24.04, systemd-networkd + Netplan
Bonded uplinks (bond0) with VLANs, bridges cloudbr0/1/2
Netplan details
network:
version: 2
renderer: networkd
ethernets:
eno1: {}
eno2: {}
bonds:
bond0:
interfaces: [eno1, eno2]
dhcp4: no
parameters:
mode: 802.3ad
mii-monitor-interval: 100
transmit-hash-policy: layer3+4 # tested layer2 also
vlans:
bond0.56:
id: 56
link: bond0
bond0.33:
id: 33
link: bond0
bridges:
cloudbr0:
interfaces: [bond0]
addresses: [10.16.10.10/24]
parameters: { stp: false, forward-delay: 5 }
routes:
# ..... REDACTED..........
cloudbr1:
interfaces: [bond0.56]
addresses: [10.15.10.10/16]
parameters: { stp: false, forward-delay: 5 }
routes:
# ..... REDACTED..........
cloudbr2:
interfaces: [bond0.33]
addresses: [10.13.10.10/16]
dhcp4: no
parameters: { stp: false, forward-delay: 5 }
The steps to reproduce the bug
Steps to reproduce
- Define a Storage network in CloudStack with VLAN (e.g. VLAN 33).
- On KVM host, create a bridge named cloudbr2 bound to the correct tagged interface (e.g. bond0.33).
- Set the traffic label for Storage to cloudbr2.
- Deploy a System VM or guest VM requiring Storage.
Observed (4.21.0.0 agent):
- KVM agent creates and uses a new bridge brbond0-33.
- VM XML shows NIC source brbond0-33.
- The pre-created cloudbr2 is ignored.
- secondarystoragevm remains stuck in Connecting mode, never reaches the management server, the connection to storage network also fails.
Expected (and actual on 4.20.1.0 agent):
- Agent attaches Storage NIC to the configured cloudbr2 bridge.
- No new bridges are auto-created.
- secondarystoragevm works as expected, storage connection works, the agent connects also the management server.
What to do about it?
Restore pre-4.21 behavior:
- For Storage traffic with VLAN, if the traffic label is a bridge, use that bridge directly.
- Do not unconditionally create br- for Storage VLANs.
- Alternatively, make this behaviour configurable to avoid breaking existing automated setups and keep the default as it used to be in 4.20.1.0.
problem
After upgrading KVM hosts from 4.20.1.0 to 4.21.0.0, the KVM agent no longer respects the pre-created Linux bridge defined by the traffic label for Storage traffic when a VLAN is configured. Doesn't work either on a clean install of 4.21.0.0.
Instead, the agent automatically creates/uses a new bridge named br- (e.g. brbond0-33).
On 4.20.1.0 with the exact same host configuration, the agent attaches Storage VLAN NICs to the expected cloudbr2 bridge.
This regression might have been introduced by PR #11245
“kvm, ui: fix interface when using vlan subnet for storage traffic type”
(commit diff)
versions
CloudStack 4.21.0.0 (KVM agent) upgraded from Cloudstack 4.20.1.0
Zone type: Core
Network type: Basic
Hypervisor: KVM x86_64
Hosts: Ubuntu 24.04, systemd-networkd + Netplan
Bonded uplinks (bond0) with VLANs, bridges cloudbr0/1/2
Netplan details
The steps to reproduce the bug
Steps to reproduce
Observed (4.21.0.0 agent):
Expected (and actual on 4.20.1.0 agent):
What to do about it?
Restore pre-4.21 behavior: