Re: how to manage macvlan devices?

From: Thomas Haller <thaller redhat com>
To: Ling Li <liling gmail com>
Cc: networkmanager-list gnome org
Subject: Re: how to manage macvlan devices?
Date: Fri, 18 Oct 2019 12:23:17 +0200

On Thu, 2019-10-17 at 15:33 -0700, Ling Li wrote:

Hi,

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


"strictly unmanaged" means that something is preventing the device from
working. That cannot be overruled via `nmcli device set $DEV managed
yes`.

Unclear why that is the case. The level=TRACE logfile would tell you.
Maybe as you run NM in a container, note that there is usually no udev
there.
NM can run with or without udev, and it determines so based on /sys
beaing writable. I means, if you run a container and have no udev, also
/sys must be mounted read-only.

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.


yes, the "generic" profile would be right here...


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

Attachment: signature.asc
Description: This is a digitally signed message part

References:
- how to manage macvlan devices?
  - From: Ling Li
- Re: how to manage macvlan devices?
  - From: Thomas Haller
- Re: how to manage macvlan devices?
  - From: Ling Li

[Date Prev][Date Next] [Thread Prev][Thread Next] [Thread Index] [Date Index] [Author Index]