Bug 1122729 - virt-manager errors in 'ifup br1' when creating and activating a bridged connection on NetworkManager system
Summary: virt-manager errors in 'ifup br1' when creating and activating a bridged conn...
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: netcf
Version: 22
Hardware: All
OS: All
unspecified
high
Target Milestone: ---
Assignee: Laine Stump
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-23 22:35 UTC by Adam Williamson
Modified: 2016-07-19 19:02 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-07-19 19:02:43 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Adam Williamson 2014-07-23 22:35:22 UTC
To reproduce: start as clean as you can, with a single ethernet connection (in my case, enp0s25) managed by NM. I also left the default virbr0 config intact, as I figured that's the typical case for people who try to set up bridged networking. Tested with 2014-07-23 Rawhide daily compose (Workstation x86_64 live), 'yum groupinstall Virtualization'.

Run virt-manager, open the host's properties, go to Network Interfaces.

click + to create a new interface.

Select Interface Type 'Bridge' and click Forward.

Check 'Activate now', and check the wired interface in the list under 'Choose interface(s) to bridge:'

Click Finish

Result: virt-manager works on it for a bit, then an error dialog appears, reading "Error creating interface: 'Could not create interface: internal error: failed to create (start) interface br1: failed to execute external program - Running 'ifup br1' failed with exit code 3: Error: Device 'br1' is waiting for slaves before proceeding with activation.'"

Further inspection shows that at this point no relevant files exist in /etc/sysconfig/network-scripts (presumably virt-manager wiped them or bailed out of creating them upon encountering the error). However, 'brctl show' shows the bridge 'br1' as existing (with no slave interfaces), and 'nmcli con show' shows "Bridge br1" and "System enp0s25" connections which did not exist before (the latter being the bridge slave profile).

Comment 1 Adam Williamson 2014-07-23 22:49:20 UTC
The same error occurs if you create the bridge but don't activate it, then try and activate it by clicking the Play button (or, well, in that case, the ifcfg files exist, because they aren't 'tested' at creation time).

I believe I may possibly know what's going on here. In the background virt-manager creates /etc/sysconfig/network-scripts/ifcfg-br1 and /etc/sysconfig/network-scripts/ifcfg-enp0s25 , then when you try to activate the bridge it does 'ifup enp0s25', waits for that, and then does 'ifup br1', I'm guessing?

I think if NetworkManager's standard profile for enp0s25 is active at the time this happens, then the 'ifup enp0s25' doesn't do anything, the connection just stays as it is (a 'normal', direct ethernet connection, not a bridge slave connection). 'nmcli con show' shows both profiles exist ("Wired connection 1" being NM's default profile for the interface, and "System connection enp0s25" being the profile backed by the ifcfg-enp0s25 file virt-manager created), but the "Wired connection 1" connection is active. If I do 'nmcli con up (UUID of System connection enp0s25)' or even just 'ifdown enp0s25; ifup enp0s25', the bridge slave profile (the one created by virt-manager) is activated, and the bridge comes up correctly.

Comment 2 Adam Williamson 2014-07-23 22:57:08 UTC
Hrm. If I disable the NetworkManager connection before trying to create the bridge (with 'Active now' checked), the activation fails with a different error:

Error creating interface: 'Could not create interface: internal error: failed to create (start) interface br1: failed to execute external program - Running 'ifup enp0s25' failed with exit code 4: Error: Connection activation failed: Master connection not found or invalid'

Comment 3 Adam Williamson 2014-07-23 23:30:04 UTC
So, hum, in the case where the network is down when you run the creation, there really seems to be some bad behaviour on ifup's part.

So if I boot, install @Virtualization, then turn off the NetworkManager connection, run virt-manager, and create the bridge but don't check 'Activate now', I wind up with the two ifcfg files created and basically looking correct. Now instead of using virt-manager I can try and bring the bridge up myself.

Any number of invocations of 'ifup enp0s25' at this point fail, with the 'Master connection not found or invalid' error. I can fire it off a hundred times and get that error. It really is an error - nothing comes up, nothing works, nothing really changes in the network configuration of the system visible via brctl and nmcli and so forth.

When I fire off 'ifup br1', it returns the 'waiting for slaves before proceeding with activation' "Error". However, I don't think it's right for this to be an Error, because it really isn't. It's more of a warning or status message, because the command has actually done quite a lot behind the scenes. After running it, 'nmcli con show' shows the br1 connection attached to the br1 device, and 'brctl show' shows the br1 bridge is up (it didn't before). So returning an error condition seems a bit off, to me.

And indeed if you now run 'ifup enp0s25', the bridge slave connection comes up successfully, and the bridge works.

So, ifup is causing us a significant problem here, because the correct thing to do to activate a bridge we've just created via ifup is to run 'ifup br1' then 'ifup enp0s25', but 'ifup br1' returns an error. It probably shouldn't do that. The 'waiting for slaves' should just be an informational message.

I also see why 'ifup enp0s25' is basically a no-op if the interface is active via NM. ifup does this:

if [ "$_use_nm" = "true" -a -n "$UUID" ]; then
    if [ "foo$2" = "fooboot" ] && [ "${TYPE}" = "Wireless" ]; then
        exit 0
    fi
    is_nm_handling ${DEVICE} && exit 0
    nmcli con up uuid "$UUID"
    exit $?
fi

is_nm_handling() is in /etc/sysconfig/network-scripts/network-functions , and looks like this:

is_nm_handling ()
{
    LANG=C nmcli -t --fields device,state  dev status 2>/dev/null | grep -q "^\(
${1}:connected\)\|\(${1}:connecting.*\)$"
}

basically, the upshot is that when you run 'ifup enp0s25', if *any* NetworkManager connection is up on that interface, ifup will just exit 0.

For old-school systems, using network.service not NM, it works rather differently: running 'ifup enp0s25' will kind of have the effect of 'refreshing' that device's configuration, if you look at the rest of /usr/sbin/ifup and /etc/sysconfig/network-scripts/ifup-eth there's no "if the device is already up, just bail out" test, it runs through the whole script. In particular, for our purposes, the bit of ifup-eth which starts:

# If the device is part of a bridge, add the device to the bridge

will run even if the device was already up. But with NM, that doesn't happen, ifup just bails out.

We could try and get clever with 'ifup' and NM and have it re-initialize the connection if 'ifup' realizes the configuration it's reading does not match the UUID of the active NM connection on that interface. But I'm not sure that's actually desired behaviour. If it's not, I think there's a couple of changes needed here. The commands virt-manager invokes when initializing a bridged connection should be, I think:

ifdown slave
ifup bridge
ifup slave

(possibly the first two can/should be the other way around, but I  think it should explicitly take the slave down then bring it up again, and it needs to  bring up the bridge before it brings up the slave). And ifup needs to not return an *error* when a bridge is waiting for slaves, only return it as information. I think. (or virt-manager could just ignore that error, but...seems wrong). CCing Lukas.

Comment 4 Adam Williamson 2014-07-23 23:50:18 UTC
The 'waiting for slaves before proceeding' error comes from nmcli, filed as https://bugzilla.gnome.org/show_bug.cgi?id=733641 .

Comment 5 Cole Robinson 2014-07-25 19:09:45 UTC
Damn dude that's some serious sleuthing! I'll admit I've had a long standing todo item to try and understand all the NM bridge + virt-manager interactions, current problems, new NM UI etc... but now the todo item is just read everything you wrote and try to understand it all :)

Comment 6 Adam Williamson 2014-07-25 19:14:46 UTC
haha, it's not really that complicated :)

I filed some bugs on NetworkManager in this area as an offshoot of this investigation, and someone named Thomas Haller (thaller@redhat) picked up on them pretty rapidly, so I guess he'd be a good bet for someone to talk to if you need to confirm/deny/clarify my diagnosis. I'll CC him. Note I didn't actually check precisely what ifup/down commands virt-manager runs in what order, I mostly inferred it from the observed behaviour, so it's possible I didn't get it entirely right - definitely double check my assumptions there :)

Comment 7 Cole Robinson 2014-07-25 19:24:24 UTC
FWIW it's really netcf (via libvirt via virt-manager) that is doing the actual ifup calls here, whatever fixes we end up with will likely be transparent to virt-manager

Comment 8 Adam Williamson 2014-07-25 19:29:46 UTC
Whoops, I forgot to mention one rather important thing. As NetworkManager stands right now I believe you're effectively in an impossible position, because of an NM bug: the one I linked earlier, https://bugzilla.gnome.org/show_bug.cgi?id=733641 .

AFAICS you can't bring up a bridge using ifup commands without at least one of them returning an error, hence virt-manager (or netcf) is stuck until that NM bug is fixed. But you could still implement what *ought* to be the correct behaviour in netcf, and then once that NM bug is fixed, things will work OK.

Comment 9 Laine Stump 2014-07-26 21:18:34 UTC
This explains a lot. netcf's ifup does behave just as you've described - it ifups the ethernets, then ifups the bridge. This *was* the proper thing to do when it was written, and it worked correctly. I guess the initscripts and/or NM people didn't realize the compatibility problems that the change in behavior can cause.

It seems odd that bringing up the slave interfaces first would result in a "waiting for slaves" error message when bringing up the bridge; I had thought that the problem was caused by NM itself automatically bringing up the slave interfaces when it's told to bring up the bridge, but I guess I need to try it out.

It would be no problem to make the change you've suggested to netcf or some variation, as long as it also works with older versions of NM/initscripts, and works as well with NM running as with the network service (alternately, perhaps it will be necessary for netcf to detect whether or not NM is running, and behave differently :-( )

Comment 10 Adam Williamson 2014-07-27 01:08:12 UTC
It's not that bringing up the slaves first results in an error when bringing up the bridge; rather, you just cannot bring the slaves up first with ifup. If you try it, it'll return an error that the matter device cannot be found.

I've filled a bug with network manager upstream about this aspect of things, I'll link to it later. But basically how it worked for me in testing is that if you try 'ifup slave' before the bridge is up it flat fails and does nothing. If you do 'ifup bridge' first it returns an error, but actually does bring the bridge up, and subsequent 'ifup slave' succeeds and fully brings up the connection.

Comment 11 Thomas Haller 2014-07-28 14:38:38 UTC
From the NetworkManager point of view:

`nmcli con up <slave>` will always up the master too (if the master is not already up). Also, downing a master, automatically downs the slaves. A slave cannot be active without active master.

If you up a master device, it will not automatically up any slaves.
(yes, nmcli reporting "waiting for slaves" is a bug that needs fixing -- thanks for opening https://bugzilla.gnome.org/show_bug.cgi?id=733641).



Also, if you call `nmcli con up` on any connection that is already active, it will down the connection first and up it again. 


That means after

  $ nmcli con up <slave>
  $ nmcli con up <master> (*)

will end up with no slaves.

Arguably, it might make sense when upping a master connection that is already up, to reconnect the previously attached slaves too. That would be a different RFE. The workaround is to first up the master, then the slaves.

 
The correct way would be either:

  $ nmcli con up <master> (*)
  $ nmcli con up <slave>

or just 
  $ nmcli con up <slave>


(*) these commands seem to fail, due to before mentioned bgo#733641.




From a netcf point of view, initscripts should behave consistently whether it is backed by NM or not -- whatever the concrete issues are :)


Also, I think initscripts should indeed up a connection when explicitly told so. How about:


diff --git c/sysconfig/network-scripts/ifup i/sysconfig/network-scripts/ifup
index 278fde3..5c3bb37 100755
--- c/sysconfig/network-scripts/ifup
+++ i/sysconfig/network-scripts/ifup
@@ -69,7 +69,11 @@ if [ "$_use_nm" = "true" -a -n "$UUID" ]; then
     if [ "foo$2" = "fooboot" ] && [ "${TYPE}" = "Wireless" ]; then
         exit 0
     fi
-    is_nm_handling ${DEVICE} && exit 0
+    CHECK_UUID="$UUID"
+    if [ "foo$2" = "fooboot" ] ; then
+        CHECK_UUID=
+    fi
+    is_nm_handling ${DEVICE} $CHECK_UUID && exit 0
     nmcli con up uuid "$UUID"
     exit $?
 fi
diff --git c/sysconfig/network-scripts/network-functions i/sysconfig/network-scripts/network-functions
index 8a9028f..328ad49 100644
--- c/sysconfig/network-scripts/network-functions
+++ i/sysconfig/network-scripts/network-functions
@@ -282,7 +282,7 @@ is_nm_active ()
 
 is_nm_handling ()
 {
-    LANG=C nmcli -t --fields device,state  dev status 2>/dev/null | grep -q "^\(${1}:connected\)\|\(${1}:connecting.*\)$"
+    LANG=C nmcli -t --fields device,state,con-uuid  dev status 2>/dev/null | grep -q "^${1}:\(connected\|connecting\):${2:-[-0-9a-f]\+}$"
 }
 
 is_nm_device_unmanaged ()

Comment 12 Thomas Haller 2014-07-28 19:25:01 UTC
(In reply to Thomas Haller from comment #11)

> Arguably, it might make sense when upping a master connection that is
> already up, to reconnect the previously attached slaves too. That would be a
> different RFE. The workaround is to first up the master, then the slaves.

which is upstream bug: https://bugzilla.gnome.org/show_bug.cgi?id=733644

Comment 13 Adam Williamson 2014-07-28 23:23:16 UTC
"`nmcli con up <slave>` will always up the master too (if the master is not already up)"

note, there is a corner case where this is not true :) https://bugzilla.gnome.org/show_bug.cgi?id=733890 . That is the case I hit in c#2 of this bug.

"That means after

  $ nmcli con up <slave>
  $ nmcli con up <master> (*)

will end up with no slaves."

Nice catch! I didn't spot that one in my testing :)

"Also, I think initscripts should indeed up a connection when explicitly told so. How about:"

Looks reasonable to me. I guess the reason this feels messy is that if you have two connections that both apply to the interface named 'eth0' and you run 'ifup eth0' the command is irredeemably ambiguous, and it's arguable what the "best" approach is. But we can consider this in the light of what we do if the interface is not currently up, which is pick a connection and go with it. It makes sense, I think, that in the case where the interface is up we try and activate the same interface we would if it was down, not just bail out.

Comment 14 Adam Williamson 2014-07-28 23:52:36 UTC
So let's see, to summarize from virt-manager's viewpoint. What virt-manager does when it tries to activate a bridge, I believe, is:

ifup slave
ifup bridge

Let's look at what happens when it does this.

== With NetworkManager ==

=== Interface up before attempted bridge activation ===

'ifup slave' doesn't fail, but leaves the *non*-slave connection active. That should be fixed by #c11.

'ifup bridge' fails due to https://bugzilla.gnome.org/show_bug.cgi?id=733641 ("waiting for slaves"). Fixing that bug would stop 'ifup bridge' failing, but would not result in a working connection on this workflow unless #c11 fix was applied.

=== Interface down before attempted bridge activation ===

'ifup slave' fails, due to https://bugzilla.gnome.org/show_bug.cgi?id=733890 . 'ifup bridge' never gets attempted. Fixing that bug should cause this workflow to be OK.

=== Both cases ===

It's possible that if all other bugs were fixed, both cases here may run into the bug Thomas described in c#11 where bringing up the master after the slave causes the slave to go down again, but I could not actually reproduce that bug in my testing: both 'ifup bridge' and 'nmcli con up bridge' seem to keep the slave up if it was up before, for me (Fedora Rawhide).

== Without NetworkManager ==

=== Interface up before attempted bridge activation ===

'ifup slave' effectively causes the slave device to be 'refreshed' - it will be brought up as bridge slave. 'ifup bridge' then brings the bridge up, and all is happy.

=== Interface down before attempted bridge activation ===

'ifup slave' brings up the slave, 'ifup bridge' brings up the bridge, all is happy (except that sometimes 'ifup bridge' gives up on DHCP too fast, in my testing).

So...per my testing, anyway, I think it's correct to say that fixing the two BGO bugs - 733641 and 733890 - and 'fixing' ifup to re-init if the UUID doesn't match, as per #c11 should fix all of these basic cases, if I'm reading all the possibilities correctly.

Comment 15 Adam Williamson 2014-07-29 00:51:19 UTC
So, I did some test builds! There's a Rawhide NetworkManager with the proposed fix for #733641 (but not #733890) here:

http://koji.fedoraproject.org/koji/taskinfo?taskID=7205403

and an initscripts with the fix from #c11 here:

http://koji.fedoraproject.org/koji/taskinfo?taskID=7205461

Looks like the initscripts fix isn't sufficient for the affected case. If I take an existing ifcfg-eth0 which describes a simple DHCP connection, hand edit it to describe a bridge slave and drop the UUID line, save the file, and do 'ifup eth0', the connection isn't re-initialized; NM doesn't re-read the config file so it doesn't know it's changed. Even if I do 'nmli con reload' first, it doesn't seem to consider the changed ifcfg file as a new connection, it just updates the configuration of the existing connection (the UUID doesn't change), so even with the new test, 'ifup eth0' still exits without doing anything, as the 'is_nm_handling()' check still returns 'yes, it is'.

The NetworkManager fix seems to work, though.

Comment 16 wengmeiling 2014-09-10 07:50:12 UTC
Hi, guys. How is this problem going on?
I met the similar problem:

when I create a br:
#brctl addbr br0
# ifconfig
br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::8c3:5ff:feeb:46e9  prefixlen 64  scopeid 0x20<link>
        ether 0a:c3:05:eb:46:e9  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 6  bytes 508 (508.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ens3f0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 9.81.1.120  netmask 255.255.0.0  broadcast 9.81.255.255
        inet6 fe80::2034:1ff:fe17:1212  prefixlen 64  scopeid 0x20<link>
        ether 22:34:01:17:12:12  txqueuelen 1000  (Ethernet)
        RX packets 106  bytes 10996 (10.7 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 91  bytes 13402 (13.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 0  (Local Loopback)
        RX packets 394  bytes 33524 (32.7 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 394  bytes 33524 (32.7 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

then restart the network service:
#systemctl restart network.service

but the interface ens3f0 has no ip configure:
# ifconfig
br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::8c3:5ff:feeb:46e9  prefixlen 64  scopeid 0x20<link>
        ether 0a:c3:05:eb:46:e9  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 6  bytes 508 (508.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ens3f0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether 22:34:01:17:12:12  txqueuelen 1000  (Ethernet)
        RX packets 106  bytes 10996 (10.7 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 91  bytes 13402 (13.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 0  (Local Loopback)
        RX packets 394  bytes 33524 (32.7 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 394  bytes 33524 (32.7 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

The reason is the same as Adam said from #c3:
ifup exit after "is_nm_handling ${DEVICE}"

Comment 17 wengmeiling 2014-09-10 09:26:22 UTC
another strange thing:

if I create smoe virtual interfaces:

# ip link add type veth
# ifconfig
ens3f0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 9.81.1.120  netmask 255.255.0.0  broadcast 9.81.255.255
        inet6 fe80::2034:1ff:fe17:1212  prefixlen 64  scopeid 0x20<link>
        ether 22:34:01:17:12:12  txqueuelen 1000  (Ethernet)
        RX packets 3226  bytes 453064 (442.4 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 587  bytes 64126 (62.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 0  (Local Loopback)
        RX packets 1162  bytes 98804 (96.4 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1162  bytes 98804 (96.4 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

veth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether c6:ef:31:21:f9:5f  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

veth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether 1e:75:fd:e6:e5:16  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

and then restart the network service:
#systemctl restart network.service

but the ens3f0's static configure will be used on veth1:

# ifconfig
ens3f0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether 22:34:01:17:12:12  txqueuelen 1000  (Ethernet)
        RX packets 3226  bytes 453064 (442.4 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 587  bytes 64126 (62.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 0  (Local Loopback)
        RX packets 1162  bytes 98804 (96.4 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1162  bytes 98804 (96.4 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

veth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether c6:ef:31:21:f9:5f  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

veth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 9.81.1.120  netmask 255.255.0.0  broadcast 9.81.255.255
        inet6 fe80::2034:1ff:fe17:1212  prefixlen 64  scopeid 0x20<link>
        ether 1e:75:fd:e6:e5:16  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

I don't know what's wrong, but delete the veth and restart the network, the configure is correct.

Comment 18 Laine Stump 2014-11-14 18:30:48 UTC
I just fixed Bug 1162822, which revealed information relevant to this BZ. In particular, the decision of whether to ifup the slave or the bridge first. Among other things, I found that when NM is disabled, if you attempt to ifup a bridge that is configured for dhcp in the order:

   ifup bridge
   ifup slave

The ifup bridge will *always* fail, because ifup-eth checks for carrier on any device that is configured for dhcp, and a bridge's "carrier" will never be on until at least one attached device is in "forwarding" mode. If the slave device(s) isn't connected, it can't be in forwarding mode, so the check for carrier will fail. And even if you removed the carrier check, dhclient would fail to acquire an IP address. So that says to me that the proper sequence is to first ifup any slaves, and then ifup the bridge.

For NM's part, it's fine if it chooses to automatically ifup a bridge's slaves when the bridge is ifup'ed, but in order to maintain compatibility with any existing scripts (or software such as netcf), there should be no failure if the slaves are already ifup'ed.

Comment 19 Laine Stump 2014-11-14 18:35:21 UTC
As for Comment 16 and Comment 17 (by wengmeiling ) - I believe you are experiencing a completetly unrelated problem. You most likely have an ifcfg file for the 9.81.1.120 configuration that has neither a DEVICE nor a HWADDR setting - in this case starting the network service (or NM I believe) will end up with that config being psuedo-randomly assigned to some interface, which may or may not be the interface you intended. If you add DEVICE and/or HWADDR of ens3f0 the ifcfg file, you should no longer encounter the problem.

Comment 20 wengmeiling 2014-12-11 06:24:09 UTC
to Laine:
you are right, after add HWADDR, everything is ok. Thanks!

Comment 21 Dan Williams 2015-01-14 21:28:51 UTC
(In reply to Adam Williamson (Red Hat) from comment #4)
> The 'waiting for slaves before proceeding' error comes from nmcli, filed as
> https://bugzilla.gnome.org/show_bug.cgi?id=733641 .

This is fixed in Fedora 21 as of NetworkManager-0.9.10.1-1.git20150105.

Comment 22 Jaroslav Reznik 2015-03-03 17:03:11 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle.
Changing version to '22'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22

Comment 23 Fedora End Of Life 2016-07-19 19:02:43 UTC
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 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.


Note You need to log in before you can comment on or make changes to this bug.