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.

Hi Jirka,

When you say 'the interface will be downed' do you mean that it will be taken back down after NM takes it up? If that is the case, we need a way to work around (or better yet, prevent) the iff_up.

Jirka, thanks for your answer :-)

(In reply to Jirka Klimes from comment #2)
> 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.

If this option accepts a glob like bond* and can be added to /etc/NetworkManager/conf.d/00-server.conf I consider this a good solution for my problem :-) I would only have to name the dummy bond accordingly (append the random part to 'bond' prefix).

> 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.

I'd rather have NM completely ignore the bond.

> 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'

This is also a good workaround. If only NM watched the directory and modified the connection automatically :-)

> 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.

The second approach hints that a proper API is welcome. Taking manual control should be possible, at least for troubleshooting. But this comment belongs to the linked bug, I guess.

(In reply to Antoni Segura Puimedon from comment #3)
> Hi Jirka,
> 
> When you say 'the interface will be downed' do you mean that it will be
> taken back down after NM takes it up? If that is the case, we need a way to
> work around (or better yet, prevent) the iff_up.

In my test the interface stays down, so it should be OK.
Anyway, NM will not show the interface as unmanaged. So we should include the commit I pointed out in comment #2 into RHEL7:
http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=194b14e39899e8f3a73b1a151ed5384ecbf80149

I would focus this bug on that.

Created attachment 935415 [details]
[PATCH] core: don't generate a connection for unmanaged devices

Rebase of the upstream patch to RHEL7 code.

patch looks right

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-0311.html