Upstream bug report:

https://bugzilla.redhat.com/show_bug.cgi?id=879180

 Igor Lvovsky 2012-11-22 04:42:51 EST

Created attachment 649602 [details]
journal log

Description of problem:

During vdsm bootstrap we need to create bridge on top of existing interface.
We do it by creation proper ifcfg files with NM_CONTROLLED=no and ifup all needed devices:

See ifcfg files example below:

[root@dhcp-1-165 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ovirtmgmt
DEVICE=ovirtmgmt
TYPE=Bridge
ONBOOT=yes
BOOTPROTO=dhcp
DELAY=0
NM_CONTROLLED=no

[root@dhcp-1-165 ~]# cat /etc/sysconfig/network-scripts/ifcfg-em1
DEVICE=em1
ONBOOT=yes
BOOTPROTO=none
HWADDR=78:2b:cb:7d:7c:ea
BRIDGE=ovirtmgmt
NM_CONTROLLED=no

At the end I get 'ovirtmgmt' bridge created and up but 'em1' interface down.
In journalctl log you can see that NetworkManager take it explicitly down.


Version-Release number of selected component (if applicable):
NetworkManager-0.9.7.0-6.git20121004.fc18.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Fresh installed F18
2. Create ifcfg files for bridge and proper interface
3. ifup all devices
  
Actual results:
Bridge is up but underlying interface is down

Expected results:
both bridge and interface should stay up


Additional info:

Snippet from attached journal log:

....
Nov 20 10:28:45 dhcp-1-165.tlv.redhat.com avahi-daemon[625]: Withdrawing address record for 10.35.1.165 on em1.
Nov 20 10:28:45 dhcp-1-165.tlv.redhat.com avahi-daemon[625]: Leaving mDNS multicast group on interface em1.IPv4 with address 10.35.1.165.
Nov 20 10:28:45 dhcp-1-165.tlv.redhat.com avahi-daemon[625]: Interface em1.IPv4 no longer relevant for mDNS.
Nov 20 10:28:45 dhcp-1-165.tlv.redhat.com avahi-daemon[625]: Withdrawing address record for fe80::7a2b:cbff:fe7d:7cea on em1.
Nov 20 10:28:45 dhcp-1-165.tlv.redhat.com kernel: device em1 entered promiscuous mode
Nov 20 10:28:45 dhcp-1-165.tlv.redhat.com NetworkManager[631]: <warn> /sys/devices/virtual/net/ovirtmgmt: couldn't determine device driver; ignoring...
Nov 20 10:28:45 dhcp-1-165.tlv.redhat.com kernel: ovirtmgmt: port 1(em1) entered forwarding state
Nov 20 10:28:45 dhcp-1-165.tlv.redhat.com kernel: ovirtmgmt: port 1(em1) entered forwarding state
Nov 20 10:28:45 dhcp-1-165.tlv.redhat.com dhclient[1589]: DHCPREQUEST on ovirtmgmt to 255.255.255.255 port 67 (xid=0x7e714890)
Nov 20 10:28:45 dhcp-1-165.tlv.redhat.com dhclient[1589]: DHCPACK from 10.35.1.252 (xid=0x7e714890)
Nov 20 10:28:46 dhcp-1-165.tlv.redhat.com NetworkManager[631]: ifcfg-rh: parsing /etc/sysconfig/network-scripts/ifcfg-ovirtmgmt ...
Nov 20 10:28:46 dhcp-1-165.tlv.redhat.com NetworkManager[631]: ifcfg-rh:     error: Bridge connections are not yet supported
Nov 20 10:28:46 dhcp-1-165.tlv.redhat.com NetworkManager[631]: ifcfg-rh: parsing /etc/sysconfig/network-scripts/ifcfg-ovirtmgmt ...
Nov 20 10:28:46 dhcp-1-165.tlv.redhat.com NetworkManager[631]: ifcfg-rh:     error: Bridge connections are not yet supported
Nov 20 10:28:46 dhcp-1-165.tlv.redhat.com NetworkManager[631]: ifcfg-rh: parsing /etc/sysconfig/network-scripts/ifcfg-em1 ...
Nov 20 10:28:46 dhcp-1-165.tlv.redhat.com NetworkManager[631]: <warn> failed to allocate link cache: (-10) Operation not supported
Nov 20 10:28:46 dhcp-1-165.tlv.redhat.com NetworkManager[631]: ifcfg-rh:     read connection 'System em1'
Nov 20 10:28:46 dhcp-1-165.tlv.redhat.com NetworkManager[631]: ifcfg-rh: Ignoring connection 'System em1' and its device due to NM_CONTROLLED/BRIDGE/VLAN.
Nov 20 10:28:46 dhcp-1-165.tlv.redhat.com NetworkManager[631]: <info> (em1): now unmanaged
Nov 20 10:28:46 dhcp-1-165.tlv.redhat.com NetworkManager[631]: <info> (em1): device state change: activated -> unmanaged (reason 'unmanaged') [100 10 3]
Nov 20 10:28:46 dhcp-1-165.tlv.redhat.com NetworkManager[631]: <info> (em1): deactivating device (reason 'unmanaged') [3]
Nov 20 10:28:46 dhcp-1-165.tlv.redhat.com NetworkManager[631]: <info> (em1): canceled DHCP transaction, DHCP client pid 1030
Nov 20 10:28:46 dhcp-1-165.tlv.redhat.com NetworkManager[631]: <info> (em1): cleaning up...
Nov 20 10:28:46 dhcp-1-165.tlv.redhat.com NetworkManager[631]: <info> (em1): taking down device.
Nov 20 10:28:46 dhcp-1-165.tlv.redhat.com NetworkManager[631]: <warn> failed to allocate link cache: (-10) Operation not supported
Nov 20 10:28:46 dhcp-1-165.tlv.redhat.com kernel: ovirtmgmt: port 1(em1) entered disabled state
Nov 20 10:28:46 dhcp-1-165.tlv.redhat.com dbus-daemon[640]: dbus[640]: [system] Activating service name='org.freedesktop.nm_dispatcher' (using servicehelper)
.....

[reply] [-]
Private
Comment 1 Igor Lvovsky 2012-11-22 05:44:46 EST

Snippet from discussion with Dan Williams and Pavel Simerda :

According to Dan this behaviour is expected:

---- snip ---

1) NM starts up and the only ifcfg files present are:

/etc/sysconfig/network-scripts/ifcfg-lo
/etc/sysconfig/network-scripts/ifcfg-p2p1

Neither of these files apply to the "em1" interface and neither
specifies NM_CONTROLLED=no.

2) The 'em1' interface is present on the system and no ifcfg file has
specified that 'em1' should not be managed by NM, so NM manages it.

3) As there is no existing connection/ifcfg defined for 'em1',
NetworkManager creates a default DHCP connection for it.

4) Nov 20 10:27:57 - em1's carrier turns ON, so NM activates the
interface using the default DHCP connection from #3

5) Nov 20 10:28:46 - an ifcfg file is created for 'em1', which includes
NM_CONTROLLED=no.  NetworkManager reads this file, determines that em1
is no longer supposed to be managed, and deactivates the interface,
clearing the IP configuration that it set up on the interface, precisely
because NM is no longer supposed to manage that interface.

When an interface is managed by NetworkManager, and thus NM has done all
the setup on that interface, it must clean up after itself when the
interface becomes unmanaged, because certain things are done with the
interface (like dhcp, 802.1x, etc) that are specific to NM.  So this
behavior is expected.

FYI, we're about to land the bridging support upstream, which might help
this, except that we'd heard the ovirt was only going to be a Tech
Preview for RHEL7, and thus we were going to add support for ovirt stuff
after RHEL 7.0.

--- snip ---

But it's not suitable from vdsm point of view.

Pavel's point is:

--- snip ---

My opinion is that NetworkManager should only deactivate devices that are
explicitly deactivated. When a device is being released from management,
I would prefer if NetworkManager just releases it without deactivation.

When NetworkManager exits, it also doesn't deactivate every single interface.
In my opinion the actions on releasing of an interface from NM management
should be exactly the same as when NM is being stopped.

> When an interface is managed by NetworkManager, and thus NM has done
> all the setup on that interface, it must clean up after itself when the
> interface becomes unmanaged,

It doesn't have to clean up at least for some interfaces. This is remotely
related to the 'connection assume' functionality. I believe that if an
interface is technically suitable for 'assume', unmanaging should leave
it in assumable state.

Therefore releasing a device from management and then taking it back and
managing it should not disrupt its configuration, unless the nature of the
device requires it (e.g. it needs a running daemon).

--- snip ---

[reply] [-]
Private
Comment 2 Igor Lvovsky 2012-11-22 05:47:22 EST

In additional Toni suggested to add option to network manager to set a "server mode" that would prevent default connection creation:

https://bugzilla.gnome.org/show_bug.cgi?id=688857

[reply] [-]
Private
Comment 3 Dan Williams 2012-12-13 11:30:36 EST

At the moment, unmanaging an interface gives the interface back to you the same way you'd get it if NetworkManager was not installed or not running.  You get to do whatever you want with it, and you have no guarantees about its configuration, just like if the interface was just plugged in or whatever.  I assume that for ONBOOT=no interfaces, you have to configure those using libvirt right now anyway, correct?  Is there a problem with:

write NM_CONTROLLED=no to the ifcfg file
wait 2 seconds
run ifup <ifcfg>

if you already know what ifcfg file you're writing NM_CONTROLLED=no to, then it should be pretty easy to ifup that ifcfg file after doing so, right?

(this behavior is quite likely to change to something you more expect for F19+, but is unlikely to change for F18)

[reply] [-]
Private
Comment 4 Jirka Klimes 2012-12-14 04:49:27 EST

See patches for not taking an interface down while unmanaging it:
https://bugzilla.gnome.org/show_bug.cgi?id=671752 comments 11,12,13

[reply] [-]
Private
Comment 5 Pavel Šimerda 2012-12-14 18:01:15 EST

(In reply to comment #4)
> See patches for not taking an interface down while unmanaging it:
> https://bugzilla.gnome.org/show_bug.cgi?id=671752 comments 11,12,13

Looks reasonable. Direct link for reference:

http://bugzilla-attachments.gnome.org/attachment.cgi?id=224621