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) .....
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 ---
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
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)
See patches for not taking an interface down while unmanaging it: https://bugzilla.gnome.org/show_bug.cgi?id=671752 comments 11,12,13
(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
(In reply to comment #3) > 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? There's an easy workaround, so the bug will be better handled upstream.