Bug 1134569

Summary: virsh iface-bridge throws away static config parameters from the old interface config file
Product: [Fedora] Fedora Reporter: Edgar Hoch <edgar.hoch>
Component: netcfAssignee: Laine Stump <laine>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: unspecified    
Version: 21CC: agedosier, berrange, clalancette, itamar, jforbes, laine, libvirt-maint, veillard, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-12-02 03:33:01 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Edgar Hoch 2014-08-27 19:48:24 UTC
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
NAME="System em1"
DOMAIN="my.exampledomain.com other.exampledomain.com"

After running "virsh iface-bridge em1 brem1", the new generated files contain:

File /etc/sysconfig/network-scripts/ifcfg-em1:


File /etc/sysconfig/network-scripts/ifcfg-brem1:


That means, that the following configuration data is lost:
- interface configuration type:
- configuration method:
- ip address:
- network prefix:
- default router:
- default route:
- dns servers:
- dns search domains:
    DOMAIN="my.exampledomain.com other.exampledomain.com"
- zone name for firewalld:
- other config information from the old network device config file:

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):

How reproducible:

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.

Comment 1 Edgar Hoch 2014-08-27 22:32:59 UTC
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 }
/TYPE=/ p
/UUID=/ p
/NAME=/ p
' /root/ifcfg-em1.orig > /root/ifcfg-em1

sed -e '
/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 &


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.

Comment 2 Laine Stump 2015-02-17 05:27:16 UTC
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)

Comment 3 Fedora End Of Life 2015-11-04 15:40:45 UTC
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.

Comment 4 Fedora End Of Life 2015-12-02 03:33:10 UTC
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

Thank you for reporting this bug and we are sorry it could not be fixed.