summaryrefslogtreecommitdiff
path: root/man
diff options
context:
space:
mode:
Diffstat (limited to 'man')
-rw-r--r--man/systemd-nspawn.xml67
-rw-r--r--man/systemd.network.xml28
-rw-r--r--man/systemd.nspawn.xml10
3 files changed, 79 insertions, 26 deletions
diff --git a/man/systemd-nspawn.xml b/man/systemd-nspawn.xml
index bd688a0ee1..0c8c699201 100644
--- a/man/systemd-nspawn.xml
+++ b/man/systemd-nspawn.xml
@@ -524,15 +524,23 @@
<term><option>-n</option></term>
<term><option>--network-veth</option></term>
- <listitem><para>Create a virtual Ethernet link
- (<literal>veth</literal>) 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
- <option>--machine=</option>), prefixed with
- <literal>ve-</literal>. The container side of the Ethernet
- link will be named <literal>host0</literal>. Note that
- <option>--network-veth</option> implies
- <option>--private-network</option>.</para></listitem>
+ <listitem><para>Create a virtual Ethernet link (<literal>veth</literal>) 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 <option>--machine=</option>), prefixed with <literal>ve-</literal>. The container side of the
+ Ethernet link will be named <literal>host0</literal>. The <option>--network-veth</option> option implies
+ <option>--private-network</option>.</para>
+
+ <para>Note that
+ <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+ includes by default a network file <filename>/usr/lib/systemd/network/80-container-ve.network</filename>
+ matching the host-side interfaces created this way, which contains settings to enable automatic address
+ provisioning on the created virtual link via DHCP, as well as automatic IP routing onto the host's external
+ network interfaces. It also contains <filename>/usr/lib/systemd/network/80-container-host0.network</filename>
+ matching the container-side interface created this way, containing settings to enable client side address
+ assignment via DHCP. In case <filename>systemd-networkd</filename> is running on both the host and inside the
+ container, automatic IP communication from the container to the host is thus available, with further
+ connectivity to the external network.</para>
+ </listitem>
</varlistentry>
<varlistentry>
@@ -553,16 +561,43 @@
<varlistentry>
<term><option>--network-bridge=</option></term>
- <listitem><para>Adds the host side of the Ethernet link
- created with <option>--network-veth</option> to the specified
- bridge. Note that <option>--network-bridge=</option> implies
- <option>--network-veth</option>. If this option is used, the
- host side of the Ethernet link will use the
- <literal>vb-</literal> prefix instead of
+ <listitem><para>Adds the host side of the Ethernet link created with <option>--network-veth</option> to the
+ specified Ethernet bridge interface. Expects a valid network interface name of a bridge device as
+ argument. Note that <option>--network-bridge=</option> implies <option>--network-veth</option>. If this option
+ is used, the host side of the Ethernet link will use the <literal>vb-</literal> prefix instead of
<literal>ve-</literal>.</para></listitem>
</varlistentry>
<varlistentry>
+ <term><option>--network-zone=</option></term>
+
+ <listitem><para>Creates a virtual Ethernet link (<literal>veth</literal>) to the container and adds it to an
+ automatically managed Ethernet bridge interface. The bridge interface is named after the passed argument,
+ prefixed with <literal>vz-</literal>. The bridge interface is automatically created when the first container
+ configured for its name is started, and is automatically removed when the last container configured for its
+ name exits. Hence, each bridge interface configured this way exists only as long as there's at least one
+ container referencing it running. This option is very similar to <option>--network-bridge=</option>, besides
+ this automatic creation/removal of the bridge device.</para>
+
+ <para>This setting makes it easy to place multiple related containers on a common, virtual Ethernet-based
+ broadcast domain, here called a "zone". Each container may only be part of one zone, but each zone may contain
+ any number of containers. Each zone is referenced by its name. Names may be chosen freely (as long as they form
+ valid network interface names when prefixed with <literal>vz-</literal>), and it is sufficient to pass the same
+ name to the <option>--network-zones=</option> switch of the various concurrently running containers to join
+ them in one zone.</para>
+
+ <para>Note that
+ <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+ includes by default a network file <filename>/usr/lib/systemd/network/80-container-vz.network</filename>
+ matching the bridge interfaces created this way, which contains settings to enable automatic address
+ provisioning on the created virtual network via DHCP, as well as automatic IP routing onto the host's external
+ network interfaces. Using <option>--network-zone=</option> is hence in most cases fully automatic and
+ sufficient to connect multiple local containers in a joined broadcast domain to the host, with further
+ connectivity to the external network.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
<term><option>-p</option></term>
<term><option>--port=</option></term>
@@ -577,7 +612,7 @@
port number and its colon may be omitted, in which case the
same port as the host port is implied. This option is only
supported if private networking is used, such as with
- <option>--network-veth</option> or
+ <option>--network-veth</option>, <option>--network-zone=</option>
<option>--network-bridge=</option>.</para></listitem>
</varlistentry>
diff --git a/man/systemd.network.xml b/man/systemd.network.xml
index 6d45d6c807..70e3804746 100644
--- a/man/systemd.network.xml
+++ b/man/systemd.network.xml
@@ -363,18 +363,26 @@
<varlistentry>
<term><varname>EmitLLDP=</varname></term>
<listitem>
- <para>Controls support for Ethernet LLDP packet emission. Accepts a boolean parameter and defaults to
- false. If enabled a short LLDP packet with information about the local system is sent out in regular
- intervals on the link. The LLDP packet will contain information about the local host name, the local
- machine ID (as stored in
- <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>) and the
+ <para>Controls support for Ethernet LLDP packet emission. Accepts a boolean parameter or the special values
+ <literal>nearest-bridge</literal>, <literal>non-tpmr-bridge</literal> and
+ <literal>customer-bridge</literal>. Defaults to false, which turns off LLDP packet emission. If not false,
+ a short LLDP packet with information about the local system is sent out in regular intervals on the
+ link. The LLDP packet will contain information about the local host name, the local machine ID (as stored
+ in <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>) and the
local interface name, as well as the pretty hostname of the system (as set in
<citerefentry><refentrytitle>machine-info</refentrytitle><manvolnum>5</manvolnum></citerefentry>). LLDP
- emission is only available on Ethernet links. Note that this setting passed data suitable for
- identification of host to the network and should thus not be used on untrusted networks, where such
- identification data should not be made available. Use this option to enable other systems to identify on
- which interface they are connected to this system. See <varname>LLDP=</varname> above for an option to
- enable LLDP reception.</para>
+ emission is only available on Ethernet links. Note that this setting passes data suitable for
+ identification of host to the network and should thus not be enabled on untrusted networks, where such
+ identification data should not be made available. Use this option to permit other systems to identify on
+ which interfaces they are connected to this system. The three special values control propagation of the
+ LLDP packets. The <literal>nearest-bridge</literal> setting permits propagation only to the nearest
+ connected bridge, <literal>non-tpmr-bridge</literal> permits propagation across Two-Port MAC Relays, but
+ not any other bridges, and <literal>customer-bridge</literal> permits propagation until a customer bridge
+ is reached. For details about these concepts, see <ulink
+ url="http://standards.ieee.org/getieee802/download/802.1AB-2009.pdf">IEEE 802.1AB-2009</ulink>. Note that
+ configuring this setting to true is equivalent to <literal>nearest-bridge</literal>, the recommended and
+ most restricted level of propagation. See <varname>LLDP=</varname> above for an option to enable LLDP
+ reception.</para>
</listitem>
</varlistentry>
<varlistentry>
diff --git a/man/systemd.nspawn.xml b/man/systemd.nspawn.xml
index 15360078ef..3683412c14 100644
--- a/man/systemd.nspawn.xml
+++ b/man/systemd.nspawn.xml
@@ -420,6 +420,16 @@
</varlistentry>
<varlistentry>
+ <term><varname>Zone=</varname></term>
+
+ <listitem><para>Takes a network zone name. This setting implies <varname>VirtualEthernet=yes</varname> and
+ <varname>Private=yes</varname> and has the effect that the host side of the created virtual Ethernet link is
+ connected to an automatically managed bridge interface named after the passed argument, prefixed with
+ <literal>vz-</literal>. This option corresponds to the <option>--network-zone=</option> command line
+ switch. This option is privileged (see above).</para></listitem>
+ </varlistentry>
+
+ <varlistentry>
<term><varname>Port=</varname></term>
<listitem><para>Exposes a TCP or UDP port of the container on