2

tl;dr Linux has namespaces, in particular, network namespaces. It seems the namespace supposedly created via the -n flag when running systemd-nspwawn does not show up when employing ip netns list (neither in the host nor in the supposedly created namespace). It is either systemd-nspawn or ip netns not actually dealing with Linux namespaces (something I thought to be this: https://lwn.net/Articles/531114/#series_index)?

longer story:
I use the following command to run a "light-weight container" of Arch Linux from within my Arch Linux:

systemd-nspawn -nbUD /mntpointArchLinuxSysFs

the data at /mntpointArchLinuxSysFs has been bootstrapped, and "runs/boots" well. The man systemd-nspawn tells me that the -n options-flag means:

-n, --network-veth

Create a virtual Ethernet link ("veth") between host and container. The host side of the Ethernet link will be available as a network interface named after the container's name (as specified with --machine=), prefixed with "ve-". The container side of the Ethernet link will be named "host0". The --network-veth option implies --private-network.

In turn, the implied --private-network is explained thus

--private-network

Disconnect networking of the container from the host. This makes all network interfaces unavailable in the container, with the

exception of the loopback device and those specified with --network-interface= and configured with --network-veth. If this option is specified, the CAP_NET_ADMIN capability will be added to the set of capabilities the container retains. The latter may be disabled by using --drop-capability=. If this option is not specified (or implied by one of the options listed below), the container will have full access to the host network.

which seems to be a feat which is achieved via Linux namespaces, in particular Linux network namespaces, this that the started processes (i.e. the init of the container at /mntpointArchLinuxSysFs/bin/init and all child processes are in a different network namespace, i.e. are --private-network and only have the veth (virtual ethernet pair) as a remaining connection to the host namespace/system.

Using lsns shows that indeed systemd-nspawn created a namespace

root@host$> lsns | grep net
4026531992 net       183     1 root     /sbin/init
4026532332 net         1   824 rtkit    /usr/lib/rtkit-daemon
4026532406 net         7  4697 vu-mnt-0 /usr/lib/systemd/systemd

However ip netns list does refuse to "play along":

root@host$> ip netns list
root@host$>

Then is I for the sake of understanding create a dummy namespace via ip netns like this

root@host$> ip netns add dummy_netns
root@host$> ip netns list
dummy_netns
root@host$>

A network namespace is displayed, however, misses ironically in the lsns.

In conclusion, it seems to be unclear how the term "network namespace" is used in systemd-nspawn, ip netns as my test seem to suggest they might not really be the same thing? Maybe the term is ambiguous?

update

this part of the systemd-nspawn man page suggest imho, however that indeed both iproute and systemd-nspawn refer to the same thing in terms of network namespaces.

--network-namespace-path= Takes the path to a file representing a kernel network namespace that the container shall run in. The specified path should refer to a (possibly bind-mounted) network namespace file, as exposed by the kernel below /proc/$PID/ns/net. This makes the container enter the given network namespace. One of the typical use cases is to give a network namespace under /run/netns created by ip-netns(8), for example, --network-namespace-path=/run/netns/foo. Note that this option cannot be used together with other network-related options, such as --private-network or --network-interface=.

Even though the last part stating that it cannot be used with the --private-network option again seems to suggest some sort of distincion. what is going on here?

  • Notice the network namespace created by ip and systemd-nspawn is different, the former creates one and bind mount it to /run/ns, so even if no process is in that namespace, it's still available, and former possibly only list such bind-mounted namespace under /run/ns. But lsns list namespace simply by searching the whole /proc, all the namespace listed has some process in it. I suggest you create a namespace using ip then check by lsns. I guess you will not see it. – 炸鱼薯条德里克 Jun 20 at 13:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.