This bug may affecting RHV. If user will try to add the host to RHV over the FQDN/IP, it may end up as ovirtmgmt configured on top of enp4s0 or maybe on top of the bond because both interfaces has the host active connection IP address.

After adding such host to RHV, the ovirtmgmt bridge configured on top of the bond, but now both the bond and ovirtmgmt having the same IP which bad as well and possibly caused by this bug.

27: bond1: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    inet 10.35.x.y/24 brd 10.35.128.255 scope global noprefixroute dynamic bond1
       valid_lft 41992sec preferred_lft 41992sec
32: ovirtmgmt: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    inet 10.35.x.y/24 brd 10.35.128.255 scope global dynamic ovirtmgmt
       valid_lft 42965sec preferred_lft 42965sec

If the bridge was set on top of enp4s0, then result is worse - 

[root@orchid-vds1 ~]# cat /etc/sysconfig/network-scripts/ifcfg-bond1 
BONDING_OPTS="downdelay=0 miimon=100 mode=active-backup primary=enp4s0 updelay=0"
TYPE=Bond
BONDING_MASTER=yes
MACADDR=00:14:5E:00:00:00
PROXY_METHOD=none
BROWSER_ONLY=no
BOOTPROTO=dhcp
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
IPV6_ADDR_GEN_MODE=stable-privacy
NAME=bond1
UUID=040a78c8-c26b-4a2e-ae75-d055fea43347
DEVICE=bond1
ONBOOT=yes
AUTOCONNECT_SLAVES=yes
[root@orchid-vds1 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ovirtmgmt 
# Generated by VDSM version 4.20.18-1.el7ev
DEVICE=ovirtmgmt
TYPE=Bridge
DELAY=0
STP=off
ONBOOT=yes
BOOTPROTO=dhcp
MTU=1500
DEFROUTE=yes
NM_CONTROLLED=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
[root@orchid-vds1 ~]# cat /etc/sysconfig/network-scripts/ifcfg-enp4s0 
# Generated by VDSM version 4.20.18-1.el7ev
DEVICE=enp4s0
BRIDGE=ovirtmgmt
ONBOOT=yes
MTU=1500
DEFROUTE=no
NM_CONTROLLED=no
IPV6INIT=no
[root@orchid-vds1 ~]# brctl show
bridge name     bridge id               STP enabled     interfaces
;vdsmdummy;             8000.000000000000       no
ovirtmgmt               8000.00145e17d5b0       no              enp4s0
virbr0          8000.525400ba660a       yes             virbr0-nic

vdsm didn't acquired the bond

One last thing i noticed about this bond creation, when the bond created via cockpit, enp4s0 is actually not a member of the bond, although the ifcfg says differently so is the cockpit UI. 
But when running ip link after bond creation, only enp6s0 is part is a member of bond1. 

[root@orchid-vds1 ~]# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 00:14:5e:17:xx:xx brd ff:ff:ff:ff:ff:ff
3: enp6s0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond1 state UP mode DEFAULT group default qlen 1000
    link/ether 00:14:5e:17:xx:x0 brd ff:ff:ff:ff:ff:ff
4: ens1f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether 00:15:17:3d:cd:aa brd ff:ff:ff:ff:ff:ff
5: ens1f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether 00:15:17:3d:cd:ab brd ff:ff:ff:ff:ff:ff
22: bond1: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 00:14:5e:xx:xx:xx brd ff:ff:ff:ff:ff:ff

[root@orchid-vds1 ~]# cat /etc/sysconfig/network-scripts/ifcfg-enp4s0 
# Generated by dracut initrd
NAME=enp4s0
DEVICE=enp4s0
ONBOOT=yes
NETBOOT="yes"
UUID=8654bdda-10c1-4c46-b3b2-88b8a9a475d4
TYPE=Ethernet
PROXY_METHOD="none"
BROWSER_ONLY="no"
DEFROUTE="yes"
IPV4_FAILURE_FATAL="no"
MASTER=bond1
SLAVE=yes

[root@orchid-vds1 ~]# nmcli c s enp4s0
connection.master:                      bond1
connection.slave-type:                  bond
connection.autoconnect-slaves:          -1 (default)

Superficially, this looks like a duplicate of bug 1548265.  Would you agree?

An obvious workaround would be to disconnect the interfaces first before putting them into a bond - can you confirm that this works? Apparently NetworkManager changed behaviour to not tear down active devices that get put into a bond/bridge, and only do this at the next reboot. Intuitively this makes sense, as tearing down an active device without the user's explicit consent might sever the very connection the user is currently on, so this change might have been a safety improvement. However, the NetworkManager guys should comment here (or rather, on bug 1548265).

On the cockpit side we cannot change this behaviour - the only thing which Cockpit could do is to forcefully disconnect a device when you put it into a bond, but (1) this might make the behaviour actually worse, and (2) Cockpit should not second-guess NetworkManager's (or any other API it's talking to) logic.

> An obvious workaround would be to disconnect the interfaces first before putting them into a bond 

We can explicitly activate the bond after creating it, that will also enslave all interfaces that were forgotten by NM when it activated the bond automatically.

*** This bug has been marked as a duplicate of bug 1548265 ***

(In reply to Marius Vollmer from comment #7)
> Superficially, this looks like a duplicate of bug 1548265.  Would you agree?

Hi
To be honest i still not sure this is the same bug), but it is sounds very similar.

(In reply to Michael Burman from comment #11)

> To be honest i still not sure this is the same bug), but it is sounds very
> similar.

I am pretty sure now.  I'll add a nmcli reproducer to bug 1548265 that matches your report here.

(In reply to Marius Vollmer from comment #12)
> (In reply to Michael Burman from comment #11)
> 
> > To be honest i still not sure this is the same bug), but it is sounds very
> > similar.
> 
> I am pretty sure now.  I'll add a nmcli reproducer to bug 1548265 that
> matches your report here.

Ok, thanks Marius)