Re: NM refuses to manage a VLAN

[Dan Williams <dcbw redhat com>]

On Fri, 2014-07-04 at 08:24 -0600, Pete Zaitcev wrote:
> Dear All:
>
> I am trying to migrate an existing setup. To that end, I defined
> a connection with "nmcli c add type vlan". Result is like this:
>
> [root elanor network-scripts]# nmcli conn show configured
> NAME          UUID                                  TYPE  TIMESTAMP-REAL
> vlan-ethgray  098fcf3f-1801-4cfa-a8d4-85346bcd4083  vlan  never
> [root elanor network-scripts]# nmcli conn show configured id vlan-ethgray
> connection.id:                          vlan-ethgray
> connection.uuid:                        098fcf3f-1801-4cfa-a8d4-85346bcd4083
> connection.interface-name:              ethmain.4
> connection.type:                        vlan
> connection.autoconnect:                 yes
> connection.timestamp:                   0
> connection.read-only:                   no
> connection.permissions:
> connection.zone:                        --
> connection.master:                      --
> connection.slave-type:                  --
> connection.secondaries:
> connection.gateway-ping-timeout:        0
> 802-3-ethernet.port:                    --
> 802-3-ethernet.speed:                   0
> 802-3-ethernet.duplex:                  --
> 802-3-ethernet.auto-negotiate:          yes
> 802-3-ethernet.mac-address:             --
> 802-3-ethernet.cloned-mac-address:      --
> 802-3-ethernet.mac-address-blacklist:
> 802-3-ethernet.mtu:                     auto
> 802-3-ethernet.s390-subchannels:
> 802-3-ethernet.s390-nettype:            --
> 802-3-ethernet.s390-options:   
> ipv4.method:                            manual
> ipv4.dns:
> ipv4.dns-search:
> ipv4.addresses:                         { ip = 192.168.132.1/24, gw = 0.0.0.0 }
> ipv4.routes:
> ipv4.ignore-auto-routes:                no
> ipv4.ignore-auto-dns:                   no
> ipv4.dhcp-client-id:                    --
> ipv4.dhcp-send-hostname:                yes
> ipv4.dhcp-hostname:                     --
> ipv4.never-default:                     no
> ipv4.may-fail:                          no
> ipv6.method:                            manual
> ipv6.dns:
> ipv6.dns-search:
> ipv6.addresses:                         { ip = fd2d:acfb:74cc:5::1/64, gw = :: }; { ip = fe80:0:0:5::1/64, 
> gw = :: }
> ipv6.routes:
> ipv6.ignore-auto-routes:                no
> ipv6.ignore-auto-dns:                   no
> ipv6.never-default:                     yes
> ipv6.may-fail:                          no
> ipv6.ip6-privacy:                       -1 (unknown)
> ipv6.dhcp-hostname:                     --
> vlan.interface-name:                    ethmain.4
> vlan.parent:                            ethmain
> vlan.id:                                4
> vlan.flags:                             0 (NONE)
> vlan.ingress-priority-map:
> vlan.egress-priority-map:
> [root elanor network-scripts]# 
>
> Then, I make sure that device alias is deleted:
>
> [root elanor network-scripts]# ip link delete dev ethmain.4
> [root elanor network-scripts]# nmcli dev
> DEVICE     TYPE      STATE
> ethmain    ethernet  unmanaged 
> lo         loopback  unmanaged 
> ethmain.2  vlan      unmanaged 
> ethmain.3  vlan      unmanaged 
> ethmain.5  vlan      unmanaged 
> [root elanor network-scripts]# 
>
> So far, so good. But then...
>
> [root elanor network-scripts]# nmcli c up id vlan-ethgray
> Error: Connection activation failed: Device not managed by NetworkManager or unavailable
>
> Oops! 
>
> [root elanor network-scripts]# nmcli dev
> DEVICE     TYPE      STATE     
> ethmain    ethernet  unmanaged 
> lo         loopback  unmanaged 
> ethmain.2  vlan      unmanaged 
> ethmain.3  vlan      unmanaged 
> ethmain.4  vlan      unmanaged 
> ethmain.5  vlan      unmanaged 
>
> So, NM creates the correct alias (visible with ip link or ip addr),
> but bails before setting any addresses on it. This happens with
> NetworkManager-0.9.9.0-40.git20131003.fc20.i686.
>
> Any ideas how this could be fixed?

Hi,

I tried to reproduce this with that RPM version from F20 (and even on
i686!) but cannot.  But in any case, could you:

systemctl mask NetworkManager
systemctl stop NetworkManager
/usr/sbin/NetworkManager --no-daemon --log-level=debug

and then try to reproduce the issue?  Then we'll see if the logs
elucidate anything.

Thanks!
Dan