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 <[email protected]> > 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 > >
signature.asc
Description: This is a digitally signed message part
_______________________________________________ networkmanager-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/networkmanager-list
