Bug 879180
| Summary: | NetworkManager takes interface down if it stop managing it. | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Igor Lvovsky <ilvovsky> | ||||
| Component: | NetworkManager | Assignee: | Dan Williams <dcbw> | ||||
| Status: | CLOSED UPSTREAM | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 18 | CC: | alonbl, asegurap, danw, dcbw, dkenigsb, iheim, jklimes, lpeer, mburns, psimerda | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2013-05-07 15:23:41 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
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. |
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) .....