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


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

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

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?


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?

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.