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