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 <thal...@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 > >
_______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
