Vdsm should tell NetworkManager not to manage its reference bond (as described below). Alternatively, we can desert the idea of extracting default bonding options during runtime (we can ship with a data file copying them).

+++ This bug was initially created as a clone of Bug #1136843 +++

Description of problem:

VDSM component of oVirt project is used (among many other tasks) to manage and monitor select network devices of a virtualization slave. In particular, to be able to report options of bonding devices it manages, it has to create a randomly named (to prevent clashes) dummy bond on startup to asses default kernel options (and deletes it right away).

As soon as NetworkManager learns of this new bonding device it sets its state to UP. This, however, makes VDSM unable to change bonding mode of the device ("Operation not permitted"), which is crucial for reading default bonding options across modes.

As a workaround, VDSM could ifdown the device but I am seeking a solution in NetworkManager. I hoped that installing NetworkManager-config-server package would prevent NM from managing the bond, but neither of two directives in 00-server.conf, 'no-auto-default' and 'ignore-carrier', apply to this situation.

Is there a way to keep this bond in its DOWN state with NetworkManager running?

Version-Release number of selected component (if applicable):

NetworkManager-0.9.9.1-25.git20140326.4dba720.el7_0.x86_64
NetworkManager-config-server-0.9.9.1-25.git20140326.4dba720.el7_0.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Make sure you have NetworkManager running with 00-server.conf in /etc/NetworkManager/conf.d/
2. echo +do_not_ifup > /sys/class/net/bonding_masters
3. ip link show do_not_ifup

Actual results:

9: do_not_ifup: <NO-CARRIER,BROADCAST,MULTICAST,MASTER,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT
    link/ether 4a:9f:7f:1e:61:f0 brd ff:ff:ff:ff:ff:ff

Expected results:

9: do_not_ifup: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noqueue state DOWN mode DEFAULT 
    link/ether 4a:9f:7f:1e:61:f0 brd ff:ff:ff:ff:ff:ff

Additional info:

journalctl -b -u NetworkManager.service attached.

--- Additional comment from RHEL Product and Program Management on 2014-09-03 15:17:10 IDT ---

Since this bug report was entered in bugzilla, the release flag has been
set to ? to ensure that it is properly evaluated for this release.

--- Additional comment from Jirka Klimes on 2014-09-03 17:05:16 IDT ---

It should be sufficient to add 'unmanaged-devices' option to keyfile section in NetworkManager.conf.
/etc/NetworkManager.conf

...
[keyfile]
unmanaged-devices=interface-name:do_not_ifup;interface-name:other_iface;

Unfortunately, RHEL7 version of NM misses this commit:
http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=194b14e39899e8f3a73b1a151ed5384ecbf80149
which will cause that a connection will be created for the interface. And NM will not show the interface as unmanaged. However, the interface will be downed, so this could be good enough for your usecase.

Alternatively, you can add the line into the config file *after* you created the interface, this will cause that NM will properly unmanage the interface.
Yet another way is to create /etc/sysconfig/network-scripts/ifcfg-bla
with this content:
DEVICE=do_not_ifup
NM_CONTROLLED=no
and then call 'nmcli con load /etc/sysconfig/network-scripts/ifcfg-bla'

Note:
We consider adding an API for unmanaging interfaces, see bug 1114685. However, the main goal is to make NetworkManager to be non-disruptive, so that one doesn't have to care about whether an interface is managed or not.