Network Section not showing the VLANS

[DRO34]

Hello, not sure if this is a bug or an enhancement that will be coming but i have noticed the network section in the inventory view does not show the VLANs properly..

Here is whats currently on the nodes

[adminsyspro]

Hi @DRO34, thanks for the detailed report and screenshots, they make the situation very clear.

This is expected behaviour today rather than a defect, so I'd classify it as an enhancement. Here is what is happening:

The Network view in the inventory builds its "VLANs" grouping from the VLAN tag carried by each guest's virtual NIC (the net0: ...,tag=N setting, i.e. the VLAN-aware-bridge model). Your cluster segments VLANs the traditional way instead, with VLAN sub-interfaces on the bonds (bond0.5, bond0.10, bond1.7), each feeding its own bridge. The guests attach to those bridges without a per-NIC tag, so ProxCenter sees them all as Untagged, and the VLANs counter only reflects the one guest that happens to carry a NIC-level tag.

The good news: the host-level VLAN interfaces are already detected correctly. You can see bond0.5 / bond0.10 / bond1.7 typed as vlan in the node's Network tab (your first screenshot). The gap is purely that the inventory VLAN grouping does not yet cross-reference that host networking, it only looks at guest NIC tags.

Plan: we will enhance the Network view to also recognise host-level VLAN interfaces (VLAN sub-interfaces such as bondX.N, and the bridges built on top of them), so traditional per-bridge VLAN layouts are grouped under their real VLAN instead of Untagged.

One thing to confirm so we map it correctly: which bridges do your guests actually attach to? For example, do you have a dedicated bridge per VLAN (something like vmbrX with bridge_ports bond0.10), or are the guests on a single VLAN-aware bridge? A snippet of /etc/network/interfaces from one node would be perfect to validate our mapping.

Thanks again, we will keep this thread updated.

[DRO34]

VM network goes on vmbr0V10 = vlan 10 , VLAN5 = mgmt and VLAN7 = CEPH Cluster. All labeled below.

auto bond0
iface bond0 inet manual
bond-slaves nic4 nic5
bond-miimon 100
bond-mode 802.3ad
bond-xmit-hash-policy layer2+3

auto bond0.5
iface bond0.5 inet manual
#MGMT/CEPH-P

auto bond0.10
iface bond0.10 inet manual
#VM

auto bond1
iface bond1 inet manual
bond-slaves nic2 nic3
bond-miimon 100
bond-mode 802.3ad
bond-xmit-hash-policy layer2+3

auto bond1.7
iface bond1.7 inet manual
#CEPH/Cluster

auto vmbr0V5
iface vmbr0V5 inet static
address IP/24
gateway IP
bridge-ports bond0.5
bridge-stp off
bridge-fd 0
bridge-vlan-aware yes
bridge-vids 2-4094
#20 GB MGMT/CEPH-P

auto vmbr0V10
iface vmbr0V10 inet manual
bridge-ports bond0.10
bridge-stp off
bridge-fd 0
bridge-vlan-aware yes
bridge-vids 2-4094

#20 GB VM Network

auto vmbr1V7
iface vmbr1V7 inet static
address IP/24
bridge-ports bond1.7
bridge-stp off
bridge-fd 0
bridge-vlan-aware yes
bridge-vids 2-4094
#20 GB Ceph Cluster Network

[adminsyspro]

Thanks for the /etc/network/interfaces snippet, that confirmed it exactly. Your layout is the clean "one bridge per VLAN over a bond sub-interface" case:

• vmbr0V5 uses bond0.5 (VLAN 5, MGMT/CEPH-P)
• vmbr0V10 uses bond0.10 (VLAN 10, VM network)
• vmbr1V7 uses bond1.7 (VLAN 7, CEPH cluster)

The guests attach to those bridges with no per-NIC tag, which is exactly why the Network view bucketed them all as Untagged.

The fix is in (PR #391): the Network view now cross-references the host networking. For each bridge it inspects the uplink port, and when that port is a VLAN sub-interface (bondX.N) it groups the guests on that bridge under VLAN N. So your guests will now show up under VLAN 5 / 7 / 10 instead of Untagged, and the VLAN counter, the tree, the dashboard and the detail panel all follow.

One deliberate nuance: if a bridge trunks a whole bond directly (bridge_ports bond0, no sub-interface) it genuinely carries many VLANs at once, so untagged guests there stay Untagged, which is the correct behaviour.

This will land on the next latest build. If you can validate it on your cluster once it is out, that would be much appreciated. Thanks again for the detailed report.

[DRO34]

Perfect. Thanks