[Bug] Bridge/Vnets visibility

[maxilee]

Describe the bug

On resource - VM , when I want to reconfigure bridge to which VM is connected , on legacy PVE interface I can only choose "vmbr1" and this is good ...

on pegaprox Ican choose "vmbr1" , "mgmt" , "iscsi208" , "iscsi209".

I'm using openVswitch as network backend.

as you can see mgmt, iscsi208 and iscsi209 are not bridges.
they are "access" port in VLANs for mgmt and iscsi traffic for host ...

only vmbr1 should be visible on list to connect VM to it.

Steps to Reproduce

1. default instalation of PVE.
2. install and configure openVswitch
3. example /etc/network/interfaces:

auto lo
iface lo inet loopback

auto enp1s0f1
iface enp1s0f1 inet manual
        mtu 9000

auto enp1s0f0
iface enp1s0f0 inet manual
        mtu 9000


auto mgmt
iface mgmt inet static
        address 10.237.54.52/24
        gateway 10.237.54.254
        ovs_type OVSIntPort
        ovs_bridge vmbr1
        ovs_options tag=237
        mtu 9000


auto iscsi208
iface iscsi208 inet static
        address 10.208.54.52/24
        ovs_type OVSIntPort
        ovs_bridge vmbr1
        ovs_options tag=208
        mtu 9000


auto iscsi209
iface iscsi209 inet static
        address 10.209.54.52/24
        ovs_type OVSIntPort
        ovs_bridge vmbr1
        ovs_options tag=209
        mtu 9000


auto bond0
iface bond0 inet manual
        ovs_bonds enp1s0f0 enp1s0f1
        ovs_type OVSBond
        ovs_bridge vmbr1
        ovs_options bond_mode=balance-slb
        mtu 9000


auto vmbr1
iface vmbr1 inet manual
        ovs_type OVSBridge
        ovs_ports bond0 mgmt iscsi208 iscsi209
        mtu 9000


## Expected behavior
<!-- What should happen instead? -->
only vmbr1 should be visible on list to connect VM to it.

## Environment
- **PegaProx Version: 0.9.9.2
- **Installation Method: doesn't metter 
- **OS: appliance 
- **Browser: firefox 150
- **Behind Reverse Proxy? no
- **UI  Corporate 

## Checklist
- [x] I have searched existing issues to make sure this is not a duplicate
- [x] I am using the latest version of PegaProx

[mkellermann97]

Confirmed and reproducible from your /etc/network/interfaces. Looking at the code path:

The bridge dropdown in "VM → Network → bridge" is populated from PVE's /api2/json/nodes/{node}/network response, which returns all network interfaces — bridges, bonds, OVS internal ports, regular NICs, the lot. The frontend filter needs to keep only entries where type == 'bridge' or type == 'OVSBridge' and drop OVSIntPort, OVSBond, regular eth* etc.

Right now the filter is too wide — anything that PVE thinks is "network-y" passes through. Your mgmt, iscsi208, iscsi209 are type=OVSIntPort (access ports inside vmbr1), and they're slipping through because the filter only checks "isn't a physical NIC" rather than "is a bridge".

Tightening the filter to the exact set:

• bridge (Linux bridge — vmbr*)
• OVSBridge (OVS bridge — what you want here, vmbr1)

…and dropping everything else. Fix is small, localised to the network-config picker.

Workaround for now: just type vmbr1 manually in the bridge field — the backend accepts it and PVE will route via the OVSBridge correctly. The dropdown population is the cosmetic bug; the actual VM creation isn't broken.

Tagging bug and network.

https://opencollective.com/pegaprox

— Marcus

[maxilee]

Hi. I know workaround. But less technial people can be confused with that... :) Br Mark marek czardybon / maxilee +48 697 724 404 http://inbox.eu.org GG:3299479 ***@***.*** http://outbox.eu.org ARP: 00:90:CC:43:D8:0D GCC d? s:- a- C+++ UL++ P++ L++ E--- W+ N+ o K w--- O M- V- PS+ PE+ Y PGP t 5 X+R+ !tv b+ DI- D++ G e h r++ y? pt., 8 maj 2026, 19:01 użytkownik mkellermann97 ***@***.***> napisał:

…

*mkellermann97* left a comment (PegaProx/project-pegaprox#385) <#385 (comment)> Confirmed and reproducible from your /etc/network/interfaces. Looking at the code path: The bridge dropdown in "VM → Network → bridge" is populated from PVE's /api2/json/nodes/{node}/network response, which returns *all* network interfaces — bridges, bonds, OVS internal ports, regular NICs, the lot. The frontend filter needs to keep only entries where type == 'bridge' or type == 'OVSBridge' and drop OVSIntPort, OVSBond, regular eth* etc. Right now the filter is too wide — anything that PVE thinks is "network-y" passes through. Your mgmt, iscsi208, iscsi209 are type=OVSIntPort (access ports inside vmbr1), and they're slipping through because the filter only checks "isn't a physical NIC" rather than "is a bridge". Tightening the filter to the exact set: - bridge (Linux bridge — vmbr*) - OVSBridge (OVS bridge — what you want here, vmbr1) …and dropping everything else. Fix is small, localised to the network-config picker. Workaround for now: just type vmbr1 manually in the bridge field — the backend accepts it and PVE will route via the OVSBridge correctly. The dropdown population is the cosmetic bug; the actual VM creation isn't broken. Tagging bug and network. https://opencollective.com/pegaprox — Marcus — Reply to this email directly, view it on GitHub <#385 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACONGXGCEAFD7KMOIF7A5B34ZYHH7AVCNFSM6AAAAACYVZRVHSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DIMBYGI4DENZVGU> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[mkellermann97]

Hey @maxilee — Saturday-afternoon-patrol fix landed on Testing (commit 5f27a02).

You were right that only actual bridges should show. The backend get_network_list() was filtering on ['bridge', 'OVSBridge', 'OVSIntPort'] — that third entry was wrong. OVS internal ports are L3 host-side attachments (your mgmt, iscsi208, iscsi209), not switches you can plug a VM NIC into. PVE's own web UI doesn't list them in the bridge dropdown either; we were over-listing.

Patch drops OVSIntPort from the filter. After this rolls into a release, your VM Network dropdown should match PVE's behaviour: only vmbr1 from your /etc/network/interfaces (and any other real bridges you add).

Verified:

• Unit-test against your exact interface mix (vmbr1, mgmt, iscsi208, iscsi209, physical ports) → filter returns just vmbr1, the rest are excluded
• Regression check on Linux-bridge clusters (no OVS) → bridges still listed, no regression
• Live API hit against the dev box confirms zero OVSIntPort entries in the response

OVS-side I couldn't reproduce 1:1 — our dev clusters are Linux-bridge — but the change is type-filter narrowing, not new logic, so it shouldn't surprise. If you can re-test once it ships and the dropdown still has spurious entries, ping back and I'll dig further.

Donations at https://opencollective.com/pegaprox keep this kind of paper-cut sweep going — totally optional, helps if it earns its keep for you.

— Marcus

[maxilee]

ACK.
now it is ok - I can see only bridges to which VM could be connected.

thx.