Red Hat Bugzilla – Bug 1355907
Unable to use / create existing NetworkManager bridge
Last modified: 2017-05-24 13:00:11 EDT
Description of problem: - At install time, create a bridge with Anaconda managed by NetworkManager - choose group Virtualization - when installed, start virt-manager; only network is NAT and only interface is lo - unable to add existing Bridge Version-Release number of selected component (if applicable): 24 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: - virt-manager should see existing bridge; or - virt-manager should allow creation of "virt bridge" referencing real bridge Additional info: Resolved by creating a virt net definition cd /etc/libvirt/qemu/networks cat > newbridge.xml <<EOF > <network> > <name>bridge0</name> > <forward mode='bridge'/> > <bridge name='bridge0' /> > </network> > EOF systemctl stop libvirtd.services virt-net define newbridge.xml systemctl start libvirtd.service run virt-manager and there is a new network "bridge0" that I can select for guest networking and I get a routed network over my NetworkManager controlled bridge
Thanks for the report. What's the output of 'sudo virsh iface-list --all' ? Note, as another workaround, virt-manager also has an option for 'Specify shared device name' that you can pass 'bridge0'
[hatfield.a@page27 anz-storage-tech-series-demo]$ sudo virsh iface-list --all Name State MAC Address --------------------------------------------------- lo active 00:00:00:00:00:00 [hatfield.a@page27 anz-storage-tech-series-demo]$ sudo virsh net-list --all Name State Autostart Persistent ---------------------------------------------------------- bridge0 inactive no yes default active yes yes
So netcf isn't noticing the bridge config. NetworkManager typically creates a ifcfg file for its interfaces, so not sure what's going wrong.
Anaconda / Network Manager did create ifcfg files; root@page27 network-scripts]# cat ifcfg-br0 DEVICE=bridge0 STP=yes BRIDGING_OPTS=priority=32768 TYPE=Bridge BOOTPROTO=none IPADDR=10.1.1.109 PREFIX=24 GATEWAY=10.1.1.1 DNS1=10.1.1.1 DEFROUTE=yes IPV4_FAILURE_FATAL=no IPV6INIT=yes IPV6_AUTOCONF=yes IPV6_DEFROUTE=yes IPV6_PEERDNS=yes IPV6_PEERROUTES=yes IPV6_FAILURE_FATAL=no IPV6_PRIVACY=no IPV6_ADDR_GEN_MODE=stable-privacy NAME=br0 UUID=8c04a8eb-68f2-44b6-9a03-123332b020cb ONBOOT=yes [root@page27 network-scripts]# cat ifcfg-bridge0_slave_1 HWADDR=68:05:CA:18:0E:5B TYPE=Ethernet NAME="bridge0 slave 1" UUID=f5ce5b03-8577-4c1e-aaed-e3aeaeef50cc DEVICE=enp4s0 ONBOOT=yes BRIDGE=bridge0
When I put the two files, as named above, into ~/tmp/etc/sysconfig/network-scripts, and run: ncftool -r ~/tmp list --all I get the output: bridge0 as expected. This is the result on F24 and F25, which both have with netcf-0.2.8-4. Can you retry virsh iface-list --all as well as trying ncftool list --all and see if thesituation persists?
I've since inplace upgraded to Fedora 25 [root@page27 ~]# mkdir /tmp/ifcfg [root@page27 ~]# cd /tmp/ifcfg [root@page27 ifcfg]# virsh iface-list --all Name State MAC Address --------------------------------------------------- lo active 00:00:00:00:00:00 [root@page27 ifcfg]# ncftool list --all lo [root@page27 ifcfg]# cp /etc/sysconfig/network-scripts/ifcfg-br0 . [root@page27 ifcfg]# cp /etc/sysconfig/network-scripts/ifcfg-bridge0_slave_1 . [root@page27 ifcfg]# ll total 8 -rw-------. 1 root root 416 Apr 19 14:14 ifcfg-br0 -rw-------. 1 root root 167 Apr 19 14:15 ifcfg-bridge0_slave_1 [root@page27 ifcfg]# ncftool -r /tmp/ifcfg list --all [root@page27 ifcfg]# echo $? 0 [root@page27 ifcfg]# rpm -qf /usr/bin/ncftool netcf-0.2.8-4.fc24.x86_64 [root@page27 ifcfg]# rpm -qv NetworkManager NetworkManager-1.4.4-3.fc25.x86_64
Are there other ifcfg-* files in /etc/sysconfig/network-scripts? Could you maybe make a tarball of all of them so I can try it on F25 locally? Although in general netcf expects the DEVICE attribute of an ifcfg file to match the filename (minus "ifcfg-"), it in general is able to read them. There is a similar bug reported on RHEL7: Bug 1437603. I don't have the time to dig in without a local reproducer (their ifcfg files worked for me too), but if I can manage to get a set of files that reproduces the problem on my machines then maybe I can do something about it.
hrm, I'm sure I posted an update saying I fixed this. Odd. I deleted the Ethernet and Bridge devices from the gnome NM GUI and recreated them using nm-cli and it all works great now. Picked up by libvirt and works a dream. Apologies, I only have .bash_history now; 249 nmcli connection add type bridge autoconnect yes con-name bridge0 ifname bridge0 250 nmcli con mod bridge0 ipv4.addresses 10.1.1.109/24 ipv4.method manual 251 nmcli conn mod bridge0 ipv4.gateway 10.1.1.1 252 cat /etc/resolv.conf 253 systemctl status named 254 nmcli conn mod bridge0 ipv4.dns 10.1.1.1 255 nmcli conn del enp4s0 256 nmcli conn add type bridge-slave autoconnect yes con-name enp4s0 ifname enp4s0 master bridge0 I do note that I used to have config files bridge interface br0 and slave interface bridge0_slave1 whereas now I have bridge0 and bridge0_slave1. Not sure if this makes a difference.
Strange, and unreproducible here. Since it's working for you now, I'll close this, but feel free to re-open if you come up with a simple reproducible example of "it works when the config files are [this], but fails when they are [that]" (still may be unable to do anything about it.... :-)