Re: how to manage macvlan devices?

[Ling Li <liling gmail com>]

Thanks for the suggestion.  I tried "generic" but got the same error message.

# nmcli con add type generic ifname eth0 con-name eth0g ip4 10.1.16.92/16 gw4 10.1.0.1
Connection 'eth0g' (17d97a0e-363f-4478-989f-64a4dac46bb4) successfully added.
# nmcli con show
NAME         UUID                                  TYPE      DEVICE
eth0g        17d97a0e-363f-4478-989f-64a4dac46bb4  generic   --    
System eth0  5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03  ethernet  --     

# nmcli dev
DEVICE  TYPE      STATE      CONNECTION
lo      loopback  unmanaged  --        
eth0    macvlan   unmanaged  --        
# nmcli con up eth0g
Error: Connection activation failed: No suitable device found for this connection (device lo not available because device is strictly unmanaged).

The scheme I showed was part of the LXD profile, which exposes the host nic as a macvlan to the container.  So from the container OS point of view, the interface is not created by NM (hence what you said "external").

I am not sure if I am able to create a connection of type macvlan over an interface which is already a macvlan of something else.  When creating a connection of type macvlan, I need to provide the "parent" or "master" interface, which is not available anyway in the container.

And thank you very much for kindly pointing out the network-scripts package in RHEL/CentOS 8.  Those scripts were originally included in initscripts.rpm and I didn't know they were still provided.

On Thu, Oct 17, 2019 at 12:44 AM Thomas Haller <thaller redhat com> wrote:

On Wed, 2019-10-16 at 17:10 -0700, Ling Li via networkmanager-list
wrote:

Hi,

> I couldn't get NetworkManager to work in a container to bring up
> (virtual) NICs with static ip.  My hypothesis is that NM can't apply
> an Ethernet connection to a macvlan device, and wonder if there are
> workarounds that I may try.
>
> The setup is as follows:
>
> - The host is Ubuntu 18.04.  A macvlan nic is provided to containers
> with the following profile
>
> devices:
>   eth0:
>     name: eth0
>     nictype: macvlan
>     parent: eno1
>     type: nic

What is this scheme? Is this netplan, or something from LXD? Anyway, as
far as NetworkManager is concerned, what matters is

  nmcli connection show
  nmcli connection show "$MY_PROFILE"
  nmcli device status

> - The LXD container runs CentOS 7 with NM 1.18.0.
>
> - The "old-style" network scripts work, with the following
> configuration file:
>
> # cat /etc/sysconfig/network-scripts/ifcfg-eth0
> DEVICE=eth0
> _ONBOOT_=yes
> TYPE=Ethernet
> BOOTPROTO=none
> IPV4_FAILURE_FATAL="no"
> IPADDR=10.1.16.92
> PREFIX=16
> GATEWAY=10.1.0.1

This is an ethernet profile.

In NetworkManager (and initscripts' ifcfg format too!!) , you generally
configure one profile for the link (layer 2) and IP configuration. That
is different from for example systemd-networkd, which has .netdev,
.network, and .link files.

Yes, network-scripts don't really care, if the device already exists,
then the script will proceed and just do IP configuration, regardless
that this not a common ethernet. That's why initscripts work.

(Sidenote: there is the "generic" type, which maybe could be used as
Layer 3 configuration only and maybe can be used to all interfaces that
you create outside of NetworkManager. But that does not seem desirable
here).

Anyway, this means, you cannot use an "connection.type=802-3-ethernet"
profile to do something with a MACVlan device.


> - But NM won't work.
>
> # nmcli device
> DEVICE  TYPE      STATE      CONNECTION
> lo      loopback  unmanaged  --         
> eth0    macvlan   unmanaged  -- 

Hm, you created the MACVlan outside of NM. It's marked as unmanaged,
because NM didn't create it.


> # nmcli connection
> NAME         UUID                                  TYPE      DEVICE
> System eth0  5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03  ethernet  --     
>
> # ip link
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
> mode DEFAULT qlen 1000
>     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> 23: eth0@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
> noqueue state UP mode DEFAULT qlen 1000
>     link/ether 00:16:3e:10:b3:80 brd ff:ff:ff:ff:ff:ff link-netnsid 0
>
> # nmcli connection up 5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03
> Error: Connection activation failed: No suitable device found for
> this connection (device lo not available because device is strictly
> unmanaged).
>
> I tried "nmcli dev set eth0 managed yes" but still couldn't bring the
> connection up.


It's not clear to me whether you were able to successfully make the
device managed. As said, the device is unmanaged because NM sees it's
created externally. An explicit user command should override that. Of
course, afterwards you still cannot activate an type=ethernet profile
on a MACVLan device.


> The error message probably claims that eth0 is not a suitable device
> (due to its type is macvlan).  I found a post back from 2010
> https://mail.gnome.org/archives/networkmanager-list/2010-March/msg00308.html
> asking if NM can be forced to trade a macvlan as an Ethernet device,
> which might be related?

Messages from a decade ago seem to have little relevance.

> Anyway, since the "old-style" network scrips are already removed from
> CentOS 8,

initscripts are not removed, and of course they won't be removed for
the entire lifetime of CentOS8/RHEL8. They are merely not installed by
default. Try `dnf install network-scripts`.

Yes, they are deprecated in 8, and future RHEL/CentOS versions (>=9)
may or may not remove them. But they are still there, very much like in
rhel-7.


> I really wonder if NM can be used in a container with macvlan
> devices.  Any suggestions?


Either create a profile of type macvlan, and let NM create the device.

  nmcli connection add type macvlan ...

Or create the device outside of NM and use a profile of type "generic".

  nmcli connection add type generic ...


I think "generic" profiles are not much used, so it might not work (I
don't know whehter this is tested). If that doesn't work, please report
a bug.



best,
Thomas