Created attachment 1178763 [details]
Description of problem:
Can add more than one bridge on same one NIC via cockpit, and all bridges can get IP from dhcp server, this will cause network unreachable.
Should not permit add more than one bridge on same one NIC via cockpit.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install redhat-virtualization-host-4.0-20160708.0.x86_64 with kickstart file in attachment
2. Login cockpit website hostIP:9090 with root account
3. Select Networking page, create bridge0 on em1.
4. Create another bridge1 on em1.
1. After step4, the second bridge1 is created successful and can also get IP from DHCP server, cockpit disconnected, host network disconnected.
1. After step4, should forbid creating another bridge1 on em1.
Created attachment 1178764 [details]
screenshot of "ip a s" on rhvh
Created attachment 1178765 [details]
screenshot of add second bridge via cockpit
Created attachment 1178767 [details]
My expectation is that creating bridge1 on em1 would cleanly remove em1 from bridge0.
I'll check what's really happening.
Is em1 the main network connection that is also used to serve Cockpit?
If so then wrapping it in a bridge might indeed disconnect the machine completely.
Cockpit has a bug where it doesn not properly clean up the connection settings when a interface changes roles (from a bridge slave to a team slave, say). Instead of doing this cleanly, a error would be shown in the Cockpit UI.
But since you don't mention this error, I think this bug isn't triggered here.
(In reply to Marius Vollmer from comment #6)
> Is em1 the main network connection that is also used to serve Cockpit?
> If so then wrapping it in a bridge might indeed disconnect the machine
I have tried this with a VM with a single network interface. That interface then of course is responsible for the single IP address of the machine and Cockpit connects to that IP address.
I can see what you report:
- Creating a new bridge with the interface keeps the connection alive. The bridge takes over responsibility for the IP address and has the same MAC as the interface.
- Creating a second bridge that steals the interface from the first bridge disconnects the machine. Now both bridges have the IP address of the machine, but no packets go through.
- Deleting the first bridge with "nmcli d del bridge0" causes packets to flow again.
This is just one example how a bad network configuration can disconnect your machine from Cockpit. Another example is simply bringing down the interface.
Instead of trying to know all 'wrong' changes, our general plan for this situation is to have automatic rollback of configuration changes that have not been confirmed within a certain time.
I close this as NOTABUG since the current behavior is actually the expected one.
It's not the desired one, and that is tracked here: https://github.com/cockpit-project/cockpit/issues/1818