(→How To Test)
|Line 43:||Line 43:|
== How To Test ==
== How To Test ==
Ensure that a bridge interface created by libvirt/netcf or the system initscripts is recognized by NetworkManager but not
Ensure that a bridge interface created by libvirt/netcf or the system initscripts is recognized by NetworkManager but not by 'nmcli' or the network applet is used to change connections or deactivate bridge port interfaces.
== User Experience ==
== User Experience ==
Revision as of 15:59, 17 July 2013
NetworkManager Bridging Support
NetworkManager should be able to configure bridge interfaces with commonly used options and recognize their existing configuration on startup without disrupting their operation.
- Name: Dan Williams
- Email: dcbw at redhat dot com
- Name: Pavel Šimerda
- Email: psimerda at redhat dot com
- Release notes owner:
- Targeted release: Fedora 20
- Last updated: 2013-07-17
- Tracker bug: <will be assigned by the Wrangler>
A bridge connects two or more physical or virtual network interfaces to allow network traffic to flow between the two interfaces at a low level. Bridging is commonly used to connect Virtual Machines to the outside world; a bridge interface is created, to which a physical interface (typically ethernet) is assigned as a slave, and a virtual interface (typically TAP) is created and also assigned to the bridge as a slave, and then given to the Virtual Machine. Thus traffic from one or more VMs can be combined and sent out of the machine via the physical interface.
This setup is currently done either manually using ifcfg files and ifup/ifdown, or by a tool like libvirt/netcf. NetworkManager should be able to configure bridge interfaces and their slaves with the same functionality as provided by libvirt, and should recognize and not disrupt existing bridge connections when it starts up.
Benefit to Fedora
NetworkManager will provide a unified API for network configuration, giving a more consistent user experience. Users setting up bridged connections who also run NetworkManager will not need to take additional action to determine whether the bridge should be controlled by libvirt or by NetworkManager as the two will cooperate.
- Proposal owners: dcbw
- Other developers: This feature requires changes to nm-applet (done), nm-connection-editor (done), gnome-shell, gnome-control-center (in-progress) and KDE counterparts to expose bridge interfaces and their connection information in the user interface. NetworkManager also needs updates to implement the proposed changes (mostly done).
NetworkManager will begin to manage bridge connections defined by existing ifcfg files, but will pick up these connections as non-destructively as possible. It will not "down" the interface and reconfigure it, but will read the existing configuration of the bridge interface and bridge ports and operate with that configuration.
How To Test
Ensure that a bridge interface created by libvirt/netcf or the system initscripts is recognized by NetworkManager but not changed or taken down until explicit actions by the user are taken (eg, 'nmcli' or the network applet is used to change connections or deactivate bridge port interfaces).
Both the UI tools (applets, connection editors, etc) and the CLI tools (nmcli) will be updated for the bridging configuration options. Users will see bridge interfaces in network indicators and be able to inspect their status through the applets or the command-line tools.
The changes should be limited to NetworkManager and it's associated tools, and should not require changes to libvirt, netcf, initscripts, or other external tools. NetworkManager should be able to cooperate with the configurations set up by these tools.
- Contingency mechanism: Ensure NetworkManager only controls bridge interfaces it is told to control via NM_CONTROLLED in ifcfg files. Tools that need bridging would have to continue to use the same tools as before.
- Contingency deadline: ?
- Blocks release? No
Documentation will be drafted at Networking/Bridging.
NetworkManager now supports bridging functionality and cooperates better with existing bridging tools and configurations.