Description of problem: I have tried to use "virsh ifcace-bridge em1 brem1" to create a bridge for use with a virtual machine, but this command destroys important parameters in the network config file (previous file /etc/sysconfig/network-scripts/ifcfg-em1). The original file /etc/sysconfig/network-scripts/ifcfg-em1 have contained the following lines: # Generated by parse-kickstart UUID=457b1046-b4e9-45c9-a16f-8be04ffe16e6 DNS3=198.51.100.234 DNS2=198.51.100.235 DNS1=203.0.113.100 BOOTPROTO=none DEVICE=em1 ONBOOT=yes IPV6INIT=yes HWADDR=00:25:90:A8:1F:E7 TYPE=Ethernet IPADDR0=192.0.2.10 PREFIX0=24 GATEWAY0=192.0.2.254 DEFROUTE=yes IPV4_FAILURE_FATAL=no IPV6_AUTOCONF=yes IPV6_DEFROUTE=yes IPV6_PEERDNS=yes IPV6_PEERROUTES=yes IPV6_FAILURE_FATAL=no NAME="System em1" DOMAIN="my.exampledomain.com other.exampledomain.com" ZONE="work" After running "virsh iface-bridge em1 brem1", the new generated files contain: File /etc/sysconfig/network-scripts/ifcfg-em1: DEVICE=em1 HWADDR=00:25:90:A8:1F:E7 ONBOOT=yes BRIDGE=brem1 File /etc/sysconfig/network-scripts/ifcfg-brem1: DEVICE=brem1 ONBOOT=yes TYPE=Bridge IPV6INIT=yes IPV6_AUTOCONF=yes DHCPV6=no HWADDR=00:25:90:E8:3F:D8 STP=on DELAY=0 That means, that the following configuration data is lost: - interface configuration type: BOOTPROTO=none - configuration method: BOOTPROTO=none - ip address: IPADDR0=192.0.2.10 - network prefix: PREFIX0=24 - default router: GATEWAY0=192.0.2.254 - default route: DEFROUTE=yes - dns servers: DNS3=198.51.100.234 DNS2=198.51.100.235 DNS1=203.0.113.100 - dns search domains: DOMAIN="my.exampledomain.com other.exampledomain.com" - zone name for firewalld: ZONE="work" - other config information from the old network device config file: IPV4_FAILURE_FATAL=no IPV6_AUTOCONF=yes IPV6_DEFROUTE=yes IPV6_PEERDNS=yes IPV6_PEERROUTES=yes IPV6_FAILURE_FATAL=no I think all of these data should be preserved and put into the bridge interface configuration file (ifcfg-brem1). The network of the host will be configured wrong if that generated files would be used. This means that "virsh iface-bridge" command must not be used for other network configuration mode than dhcp. We have to create the new config files for bridging manually to preserve the important data. Also note that in the new file em1 the parameter "TYPE=Ethernet" is missing - but I don't know if it is neccessary. The "NAME=" and "UUID=" parameters are missing in both new files too, but I don't know if they are used by any program. An analogous problem appears with the command "virsh iface-unbridge": The command sequence "virsh iface-bridge em1 brem1" followed "virsh iface-unbridge brem1" creates a file ifcfg-em1 that have lost many config parameters (see above). But iface-unbridge should undo the effects of iface-bridge, which is not true. As a temporay solution I have created the network interface files manually. Version-Release number of selected component (if applicable): libvirt-client-1.1.3.5-2.fc20.x86_64 How reproducible: Always. Steps to Reproduce: 1. Use or configure a network interface with static configuration, using the parameters as in the example above. 2. Save a copy of the interface config file to a save place (e.g. "cp -a /etc/sysconfig/network-scripts/ifcfg-em1 /root/ifcfg-em1.original") 3. Run "virsh iface-bridge em1 brem1" (use the right interface name of your testing host) 4. Check the created network interface config files ifcfg-em1 and ifcfg-brem1 and compare it with the saved ifcfg-em1.original file. 5. Run "virsh iface-unbridge brem1" 6. Check the created network interface config file ifcfg-em1 and compare it with the saved ifcfg-em1.original file. Actual results: Step 4: ifcfg-brem1 is missing important config parameters. Step 6: ifcfg-em1 is missing important config parameters. Expected results: Step 4: ifcfg-brem1 contains the same config parameters als ifcfg-em1.original, except those that must not be in a bridge config file, and some parameter values have changed to conform to the requirements of the bridge (e.g. DEVICE=, TYPE=, and so on). Step 6: ifcfg-em1 contains the same config parameters als ifcfg-em1.original. Additional info: I use NetworkManager to start the network devices, but I think this doesn't affect the behavior of "virsh iface-bridge" command. But eventually NetworkManager should be forced to restart the modified network interfaces - a reload doesn't seam to work (because em1 must be changed to slave mode for the bridge device). The described problem exists since several fedora versions.
Here my manual commands to convert a simple ethernet interface to bridge. Assume the network interface is em1, and NetworkManager is running. cp -a /etc/sysconfig/network-scripts/ifcfg-em1 /root cp -a /root/ifcfg-em1 /root/ifcfg-em1.orig cp -a /root/ifcfg-em1 /root/ifcfg-brem1 sed -n -e ' /DEVICE=/ { p ; s/DEVICE=/BRIDGE=br/ ; p } /HWADDR=/ p /ONBOOT=/ p /TYPE=/ p /UUID=/ p /NAME=/ p ' /root/ifcfg-em1.orig > /root/ifcfg-em1 sed -e ' /DEVICE=/ { s/DEVICE=/DEVICE=br/ } /TYPE=/ { s/TYPE=Ethernet/TYPE=Bridge/} /NAME=/ { s/NAME="System /NAME="System br/ } /HWADDR=/ { s/^/# / } /UUID=/ { s/^/# / } ' /root/ifcfg-em1.orig > /root/ifcfg-brem1 /bin/cp -af /root/ifcfg-brem1 /root/ifcfg-em1 /etc/sysconfig/network-scripts/ & systemctl restart NetworkManager.service & Notes: The background commands (the "&" char) is neccessary when doing this while connected over ssh, because otherwise the command may loose network connection and "hang". I use "cp -a" to keep the selinux file context. /root/ifcfg-brem1 and /root/ifcfg-em1 must be copied "at the same time", because NetworkManager will detect the change of the files (new file, modified file) and will (re)read them and change the network interfaces according to the new values. But it cannot change the interface from Type Ethernet to Type Bridge on the fly - this is the reason for restarting NetworkManager. I am not sure if this will always work (sometimes I got the message "NetworkManager[13298]: <warn> (brem1): cannot use existing bridge for 'System brem1'"). You should have access to the console if the network connection is lost. You may alternativly reboot the system. I assume that virsh will use other mechanisms than sed, but the script demonstrate what "virsh iface-bridge" should do.
virsh iface-bridge uses the netcf library to read the netdev configuration as an XML document, then modifies that XML document and defines the new bridge based on that. The problem is that there are several settings in the ifcfg file that aren't recognized by netcf when it is translating between ifcfg and xml. I'm moving this BZ to netcf to remind me to add recognition for more fields (I recently added recognition of IPADDR0/PREFIX0/NETMASK0/GATEWAY0)
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.