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, theCAP_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 byip-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?
ip
andsystemd-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 usingip
then check bylsns
. I guess you will not see it.