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
ip netns not actually dealing with Linux namespaces (something I thought to be this: https://lwn.net/Articles/531114/#series_index)?
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:
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 "
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_ADMINcapability 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
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
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
In conclusion, it seems to be unclear how the term "network namespace" is used in
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
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
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?