mirror of
https://git.proxmox.com/git/systemd
synced 2025-05-29 11:51:49 +00:00
381 lines
38 KiB
HTML
381 lines
38 KiB
HTML
<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>systemd-nspawn</title><meta name="generator" content="DocBook XSL Stylesheets V1.78.1"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><style>
|
||
a.headerlink {
|
||
color: #c60f0f;
|
||
font-size: 0.8em;
|
||
padding: 0 4px 0 4px;
|
||
text-decoration: none;
|
||
visibility: hidden;
|
||
}
|
||
|
||
a.headerlink:hover {
|
||
background-color: #c60f0f;
|
||
color: white;
|
||
}
|
||
|
||
h1:hover > a.headerlink, h2:hover > a.headerlink, h3:hover > a.headerlink, dt:hover > a.headerlink {
|
||
visibility: visible;
|
||
}
|
||
</style><a href="index.html">Index </a>·
|
||
<a href="systemd.directives.html">Directives </a>·
|
||
<a href="../python-systemd/index.html">Python </a>·
|
||
<a href="../libudev/index.html">libudev </a>·
|
||
<a href="../libudev/index.html">gudev </a><span style="float:right">systemd 219</span><hr><div class="refentry"><a name="systemd-nspawn"></a><div class="titlepage"></div><div class="refnamediv"><h2>Name</h2><p>systemd-nspawn — Spawn a namespace container for debugging, testing and building</p></div><div class="refsynopsisdiv"><h2>Synopsis</h2><div class="cmdsynopsis"><p><code class="command">systemd-nspawn</code> [OPTIONS...] [<em class="replaceable"><code>COMMAND</code></em>
|
||
[ARGS...]
|
||
]</p></div><div class="cmdsynopsis"><p><code class="command">systemd-nspawn</code> -b [OPTIONS...] [ARGS...]</p></div></div><div class="refsect1"><a name="idm140120374671376"></a><h2 id="Description">Description<a class="headerlink" title="Permalink to this headline" href="#Description">¶</a></h2><p><span class="command"><strong>systemd-nspawn</strong></span> may be used to run a
|
||
command or OS in a light-weight namespace container. In many ways
|
||
it is similar to
|
||
<a href="http://man7.org/linux/man-pages/man1/chroot.1.html"><span class="citerefentry"><span class="refentrytitle">chroot</span>(1)</span></a>,
|
||
but more powerful since it fully virtualizes the file system
|
||
hierarchy, as well as the process tree, the various IPC subsystems
|
||
and the host and domain name.</p><p><span class="command"><strong>systemd-nspawn</strong></span> limits access to various
|
||
kernel interfaces in the container to read-only, such as
|
||
<code class="filename">/sys</code>, <code class="filename">/proc/sys</code> or
|
||
<code class="filename">/sys/fs/selinux</code>. Network interfaces and the
|
||
system clock may not be changed from within the container. Device
|
||
nodes may not be created. The host system cannot be rebooted and
|
||
kernel modules may not be loaded from within the container.</p><p>Note that even though these security precautions are taken
|
||
<span class="command"><strong>systemd-nspawn</strong></span> is not suitable for secure
|
||
container setups. Many of the security features may be
|
||
circumvented and are hence primarily useful to avoid accidental
|
||
changes to the host system from the container. The intended use of
|
||
this program is debugging and testing as well as building of
|
||
packages, distributions and software involved with boot and
|
||
systems management.</p><p>In contrast to
|
||
<a href="http://man7.org/linux/man-pages/man1/chroot.1.html"><span class="citerefentry"><span class="refentrytitle">chroot</span>(1)</span></a> <span class="command"><strong>systemd-nspawn</strong></span>
|
||
may be used to boot full Linux-based operating systems in a
|
||
container.</p><p>Use a tool like
|
||
<a href="https://www.mankier.com/8/dnf"><span class="citerefentry"><span class="refentrytitle">dnf</span>(8)</span></a>,
|
||
<a href="http://linux.die.net/man/8/yum"><span class="citerefentry"><span class="refentrytitle">yum</span>(8)</span></a>,
|
||
<a href="http://linux.die.net/man/8/debootstrap"><span class="citerefentry"><span class="refentrytitle">debootstrap</span>(8)</span></a>,
|
||
or
|
||
<a href="https://www.archlinux.org/pacman/pacman.8.html"><span class="citerefentry"><span class="refentrytitle">pacman</span>(8)</span></a>
|
||
to set up an OS directory tree suitable as file system hierarchy
|
||
for <span class="command"><strong>systemd-nspawn</strong></span> containers.</p><p>Note that <span class="command"><strong>systemd-nspawn</strong></span> will mount file
|
||
systems private to the container to <code class="filename">/dev</code>,
|
||
<code class="filename">/run</code> and similar. These will not be visible
|
||
outside of the container, and their contents will be lost when the
|
||
container exits.</p><p>Note that running two <span class="command"><strong>systemd-nspawn</strong></span>
|
||
containers from the same directory tree will not make processes in
|
||
them see each other. The PID namespace separation of the two
|
||
containers is complete and the containers will share very few
|
||
runtime objects except for the underlying file system. Use
|
||
<a href="machinectl.html"><span class="citerefentry"><span class="refentrytitle">machinectl</span>(1)</span></a>'s
|
||
<span class="command"><strong>login</strong></span> command to request an additional login
|
||
prompt in a running container.</p><p><span class="command"><strong>systemd-nspawn</strong></span> implements the
|
||
<a class="ulink" href="http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface" target="_top">Container
|
||
Interface</a> specification.</p><p>As a safety check <span class="command"><strong>systemd-nspawn</strong></span> will
|
||
verify the existence of <code class="filename">/usr/lib/os-release</code>
|
||
or <code class="filename">/etc/os-release</code> in the container tree
|
||
before starting the container (see
|
||
<a href="os-release.html"><span class="citerefentry"><span class="refentrytitle">os-release</span>(5)</span></a>).
|
||
It might be necessary to add this file to the container tree
|
||
manually if the OS of the container is too old to contain this
|
||
file out-of-the-box.</p></div><div class="refsect1"><a name="idm140120378540128"></a><h2 id="Options">Options<a class="headerlink" title="Permalink to this headline" href="#Options">¶</a></h2><p>If option <code class="option">-b</code> is specified, the arguments
|
||
are used as arguments for the init binary. Otherwise,
|
||
<em class="replaceable"><code>COMMAND</code></em> specifies the program to launch
|
||
in the container, and the remaining arguments are used as
|
||
arguments for this program. If <code class="option">-b</code> is not used and
|
||
no arguments are specifed, a shell is launched in the
|
||
container.</p><p>The following options are understood:</p><div class="variablelist"><dl class="variablelist"><dt id="-D"><span class="term"><code class="option">-D</code>, </span><span class="term"><code class="option">--directory=</code></span><a class="headerlink" title="Permalink to this term" href="#-D">¶</a></dt><dd><p>Directory to use as file system root for the
|
||
container.</p><p>If neither <code class="option">--directory=</code>, nor
|
||
<code class="option">--image=</code> is specified the directory is
|
||
determined as <code class="filename">/var/lib/machines/</code> suffixed
|
||
by the machine name as specified with
|
||
<code class="option">--machine=</code>. If neither
|
||
<code class="option">--directory=</code>, <code class="option">--image=</code>, nor
|
||
<code class="option">--machine=</code> are specified, the current
|
||
directory will be used. May not be specified together with
|
||
<code class="option">--image=</code>.</p></dd><dt id="--template="><span class="term"><code class="option">--template=</code></span><a class="headerlink" title="Permalink to this term" href="#--template=">¶</a></dt><dd><p>Directory or "<code class="literal">btrfs</code>"
|
||
subvolume to use as template for the container's root
|
||
directory. If this is specified and the container's root
|
||
directory (as configured by <code class="option">--directory=</code>)
|
||
does not yet exist it is created as "<code class="literal">btrfs</code>"
|
||
subvolume and populated from this template tree. Ideally, the
|
||
specified template path refers to the root of a
|
||
"<code class="literal">btrfs</code>" subvolume, in which case a simple
|
||
copy-on-write snapshot is taken, and populating the root
|
||
directory is instant. If the specified template path does not
|
||
refer to the root of a "<code class="literal">btrfs</code>" subvolume (or
|
||
not even to a "<code class="literal">btrfs</code>" file system at all),
|
||
the tree is copied, which can be substantially more
|
||
time-consuming. Note that if this option is used the
|
||
container's root directory (in contrast to the template
|
||
directory!) must be located on a "<code class="literal">btrfs</code>" file
|
||
system, so that the "<code class="literal">btrfs</code>" subvolume may be
|
||
created. May not be specified together with
|
||
<code class="option">--image=</code> or
|
||
<code class="option">--ephemeral</code>.</p></dd><dt id="-x"><span class="term"><code class="option">-x</code>, </span><span class="term"><code class="option">--ephemeral</code></span><a class="headerlink" title="Permalink to this term" href="#-x">¶</a></dt><dd><p>If specified, the container is run with a
|
||
temporary "<code class="literal">btrfs</code>" snapshot of its root
|
||
directory (as configured with <code class="option">--directory=</code>),
|
||
that is removed immediately when the container terminates.
|
||
This option is only supported if the root file system is
|
||
"<code class="literal">btrfs</code>". May not be specified together with
|
||
<code class="option">--image=</code> or
|
||
<code class="option">--template=</code>.</p></dd><dt id="-i"><span class="term"><code class="option">-i</code>, </span><span class="term"><code class="option">--image=</code></span><a class="headerlink" title="Permalink to this term" href="#-i">¶</a></dt><dd><p>Disk image to mount the root directory for the
|
||
container from. Takes a path to a regular file or to a block
|
||
device node. The file or block device must contain
|
||
either:</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>An MBR partition table with a single
|
||
partition of type 0x83 that is marked
|
||
bootable.</p></li><li class="listitem"><p>A GUID partition table (GPT) with a single
|
||
partition of type
|
||
0fc63daf-8483-4772-8e79-3d69d8477de4.</p></li><li class="listitem"><p>A GUID partition table (GPT) with a marked
|
||
root partition which is mounted as the root directory of the
|
||
container. Optionally, GPT images may contain a home and/or
|
||
a server data partition which are mounted to the appropriate
|
||
places in the container. All these partitions must be
|
||
identified by the partition types defined by the <a class="ulink" href="http://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/" target="_top">Discoverable
|
||
Partitions Specification</a>.</p></li></ul></div><p>Any other partitions, such as foreign partitions, swap
|
||
partitions or EFI system partitions are not mounted. May not
|
||
be specified together with <code class="option">--directory=</code>,
|
||
<code class="option">--template=</code> or
|
||
<code class="option">--ephemeral</code>.</p></dd><dt id="-b"><span class="term"><code class="option">-b</code>, </span><span class="term"><code class="option">--boot</code></span><a class="headerlink" title="Permalink to this term" href="#-b">¶</a></dt><dd><p>Automatically search for an init binary and
|
||
invoke it instead of a shell or a user supplied program. If
|
||
this option is used, arguments specified on the command line
|
||
are used as arguments for the init binary. This option may not
|
||
be combined with <code class="option">--share-system</code>.
|
||
</p></dd><dt id="-u"><span class="term"><code class="option">-u</code>, </span><span class="term"><code class="option">--user=</code></span><a class="headerlink" title="Permalink to this term" href="#-u">¶</a></dt><dd><p>After transitioning into the container, change
|
||
to the specified user-defined in the container's user
|
||
database. Like all other systemd-nspawn features, this is not
|
||
a security feature and provides protection against accidental
|
||
destructive operations only.</p></dd><dt id="-M"><span class="term"><code class="option">-M</code>, </span><span class="term"><code class="option">--machine=</code></span><a class="headerlink" title="Permalink to this term" href="#-M">¶</a></dt><dd><p>Sets the machine name for this container. This
|
||
name may be used to identify this container during its runtime
|
||
(for example in tools like
|
||
<a href="machinectl.html"><span class="citerefentry"><span class="refentrytitle">machinectl</span>(1)</span></a>
|
||
and similar), and is used to initialize the container's
|
||
hostname (which the container can choose to override,
|
||
however). If not specified, the last component of the root
|
||
directory path of the container is used, possibly suffixed
|
||
with a random identifier in case <code class="option">--ephemeral</code>
|
||
mode is selected. If the root directory selected is the host's
|
||
root directory the host's hostname is used as default
|
||
instead.</p></dd><dt id="--uuid="><span class="term"><code class="option">--uuid=</code></span><a class="headerlink" title="Permalink to this term" href="#--uuid=">¶</a></dt><dd><p>Set the specified UUID for the container. The
|
||
init system will initialize
|
||
<code class="filename">/etc/machine-id</code> from this if this file is
|
||
not set yet. </p></dd><dt id="--slice="><span class="term"><code class="option">--slice=</code></span><a class="headerlink" title="Permalink to this term" href="#--slice=">¶</a></dt><dd><p>Make the container part of the specified
|
||
slice, instead of the default
|
||
<code class="filename">machine.slice</code>.</p></dd><dt id="--private-network"><span class="term"><code class="option">--private-network</code></span><a class="headerlink" title="Permalink to this term" href="#--private-network">¶</a></dt><dd><p>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 <code class="option">--network-interface=</code> and
|
||
configured with <code class="option">--network-veth</code>. 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
|
||
<code class="option">--drop-capability=</code>.</p></dd><dt id="--network-interface="><span class="term"><code class="option">--network-interface=</code></span><a class="headerlink" title="Permalink to this term" href="#--network-interface=">¶</a></dt><dd><p>Assign the specified network interface to the
|
||
container. This will remove the specified interface from the
|
||
calling namespace and place it in the container. When the
|
||
container terminates, it is moved back to the host namespace.
|
||
Note that <code class="option">--network-interface=</code> implies
|
||
<code class="option">--private-network</code>. This option may be used
|
||
more than once to add multiple network interfaces to the
|
||
container.</p></dd><dt id="--network-macvlan="><span class="term"><code class="option">--network-macvlan=</code></span><a class="headerlink" title="Permalink to this term" href="#--network-macvlan=">¶</a></dt><dd><p>Create a "<code class="literal">macvlan</code>" interface
|
||
of the specified Ethernet network interface and add it to the
|
||
container. A "<code class="literal">macvlan</code>" interface is a virtual
|
||
interface that adds a second MAC address to an existing
|
||
physical Ethernet link. The interface in the container will be
|
||
named after the interface on the host, prefixed with
|
||
"<code class="literal">mv-</code>". Note that
|
||
<code class="option">--network-macvlan=</code> implies
|
||
<code class="option">--private-network</code>. This option may be used
|
||
more than once to add multiple network interfaces to the
|
||
container.</p></dd><dt id="--network-ipvlan="><span class="term"><code class="option">--network-ipvlan=</code></span><a class="headerlink" title="Permalink to this term" href="#--network-ipvlan=">¶</a></dt><dd><p>Create an "<code class="literal">ipvlan</code>" interface
|
||
of the specified Ethernet network interface and add it to the
|
||
container. An "<code class="literal">ipvlan</code>" interface is a virtual
|
||
interface, similar to a "<code class="literal">macvlan</code>" interface,
|
||
which uses the same MAC address as the underlying interface.
|
||
The interface in the container will be named after the
|
||
interface on the host, prefixed with "<code class="literal">iv-</code>".
|
||
Note that <code class="option">--network-ipvlan=</code> implies
|
||
<code class="option">--private-network</code>. This option may be used
|
||
more than once to add multiple network interfaces to the
|
||
container.</p></dd><dt id="-n"><span class="term"><code class="option">-n</code>, </span><span class="term"><code class="option">--network-veth</code></span><a class="headerlink" title="Permalink to this term" href="#-n">¶</a></dt><dd><p>Create a virtual Ethernet link
|
||
("<code class="literal">veth</code>") 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
|
||
<code class="option">--machine=</code>), prefixed with
|
||
"<code class="literal">ve-</code>". The container side of the Ethernet
|
||
link will be named "<code class="literal">host0</code>". Note that
|
||
<code class="option">--network-veth</code> implies
|
||
<code class="option">--private-network</code>.</p></dd><dt id="--network-bridge="><span class="term"><code class="option">--network-bridge=</code></span><a class="headerlink" title="Permalink to this term" href="#--network-bridge=">¶</a></dt><dd><p>Adds the host side of the Ethernet link
|
||
created with <code class="option">--network-veth</code> to the specified
|
||
bridge. Note that <code class="option">--network-bridge=</code> implies
|
||
<code class="option">--network-veth</code>. If this option is used, the
|
||
host side of the Ethernet link will use the
|
||
"<code class="literal">vb-</code>" prefix instead of
|
||
"<code class="literal">ve-</code>".</p></dd><dt id="-p"><span class="term"><code class="option">-p</code>, </span><span class="term"><code class="option">--port=</code></span><a class="headerlink" title="Permalink to this term" href="#-p">¶</a></dt><dd><p>If private networking is enabled, maps an IP
|
||
port on the host onto an IP port on the container. Takes a
|
||
protocol specifier (either "<code class="literal">tcp</code>" or
|
||
"<code class="literal">udp</code>"), separated by a colon from a host port
|
||
number in the range 1 to 65535, separated by a colon from a
|
||
container port number in the range from 1 to 65535. The
|
||
protocol specifier and its separating colon may be omitted, in
|
||
which case "<code class="literal">tcp</code>" is assumed. The container
|
||
port number and its colon may be ommitted, in which case the
|
||
same port as the host port is implied. This option is only
|
||
supported if private networking is used, such as
|
||
<code class="option">--network-veth</code> or
|
||
<code class="option">--network-bridge=</code>.</p></dd><dt id="-Z"><span class="term"><code class="option">-Z</code>, </span><span class="term"><code class="option">--selinux-context=</code></span><a class="headerlink" title="Permalink to this term" href="#-Z">¶</a></dt><dd><p>Sets the SELinux security context to be used
|
||
to label processes in the container.</p></dd><dt id="-L"><span class="term"><code class="option">-L</code>, </span><span class="term"><code class="option">--selinux-apifs-context=</code></span><a class="headerlink" title="Permalink to this term" href="#-L">¶</a></dt><dd><p>Sets the SELinux security context to be used
|
||
to label files in the virtual API file systems in the
|
||
container.</p></dd><dt id="--capability="><span class="term"><code class="option">--capability=</code></span><a class="headerlink" title="Permalink to this term" href="#--capability=">¶</a></dt><dd><p>List one or more additional capabilities to
|
||
grant the container. Takes a comma-separated list of
|
||
capability names, see
|
||
<a href="http://man7.org/linux/man-pages/man7/capabilities.7.html"><span class="citerefentry"><span class="refentrytitle">capabilities</span>(7)</span></a>
|
||
for more information. Note that the following capabilities
|
||
will be granted in any way: CAP_CHOWN, CAP_DAC_OVERRIDE,
|
||
CAP_DAC_READ_SEARCH, CAP_FOWNER, CAP_FSETID, CAP_IPC_OWNER,
|
||
CAP_KILL, CAP_LEASE, CAP_LINUX_IMMUTABLE,
|
||
CAP_NET_BIND_SERVICE, CAP_NET_BROADCAST, CAP_NET_RAW,
|
||
CAP_SETGID, CAP_SETFCAP, CAP_SETPCAP, CAP_SETUID,
|
||
CAP_SYS_ADMIN, CAP_SYS_CHROOT, CAP_SYS_NICE, CAP_SYS_PTRACE,
|
||
CAP_SYS_TTY_CONFIG, CAP_SYS_RESOURCE, CAP_SYS_BOOT,
|
||
CAP_AUDIT_WRITE, CAP_AUDIT_CONTROL. Also CAP_NET_ADMIN is
|
||
retained if <code class="option">--private-network</code> is specified.
|
||
If the special value "<code class="literal">all</code>" is passed, all
|
||
capabilities are retained.</p></dd><dt id="--drop-capability="><span class="term"><code class="option">--drop-capability=</code></span><a class="headerlink" title="Permalink to this term" href="#--drop-capability=">¶</a></dt><dd><p>Specify one or more additional capabilities to
|
||
drop for the container. This allows running the container with
|
||
fewer capabilities than the default (see
|
||
above).</p></dd><dt id="--link-journal="><span class="term"><code class="option">--link-journal=</code></span><a class="headerlink" title="Permalink to this term" href="#--link-journal=">¶</a></dt><dd><p>Control whether the container's journal shall
|
||
be made visible to the host system. If enabled, allows viewing
|
||
the container's journal files from the host (but not vice
|
||
versa). Takes one of "<code class="literal">no</code>",
|
||
"<code class="literal">host</code>", "<code class="literal">try-host</code>",
|
||
"<code class="literal">guest</code>", "<code class="literal">try-guest</code>",
|
||
"<code class="literal">auto</code>". If "<code class="literal">no</code>", the journal
|
||
is not linked. If "<code class="literal">host</code>", the journal files
|
||
are stored on the host file system (beneath
|
||
<code class="filename">/var/log/journal/<em class="replaceable"><code>machine-id</code></em></code>)
|
||
and the subdirectory is bind-mounted into the container at the
|
||
same location. If "<code class="literal">guest</code>", the journal files
|
||
are stored on the guest file system (beneath
|
||
<code class="filename">/var/log/journal/<em class="replaceable"><code>machine-id</code></em></code>)
|
||
and the subdirectory is symlinked into the host at the same
|
||
location. "<code class="literal">try-host</code>" and
|
||
"<code class="literal">try-guest</code>" do the same but do not fail if
|
||
the host does not have persistent journalling enabled. If
|
||
"<code class="literal">auto</code>" (the default), and the right
|
||
subdirectory of <code class="filename">/var/log/journal</code> exists,
|
||
it will be bind mounted into the container. If the
|
||
subdirectory does not exist, no linking is performed.
|
||
Effectively, booting a container once with
|
||
"<code class="literal">guest</code>" or "<code class="literal">host</code>" will link
|
||
the journal persistently if further on the default of
|
||
"<code class="literal">auto</code>" is used.</p></dd><dt id="-j"><span class="term"><code class="option">-j</code></span><a class="headerlink" title="Permalink to this term" href="#-j">¶</a></dt><dd><p>Equivalent to
|
||
<code class="option">--link-journal=try-guest</code>.</p></dd><dt id="--read-only"><span class="term"><code class="option">--read-only</code></span><a class="headerlink" title="Permalink to this term" href="#--read-only">¶</a></dt><dd><p>Mount the root file system read-only for the
|
||
container.</p></dd><dt id="--bind="><span class="term"><code class="option">--bind=</code>, </span><span class="term"><code class="option">--bind-ro=</code></span><a class="headerlink" title="Permalink to this term" href="#--bind=">¶</a></dt><dd><p>Bind mount a file or directory from the host
|
||
into the container. Either takes a path argument -- in which
|
||
case the specified path will be mounted from the host to the
|
||
same path in the container --, or a colon-separated pair of
|
||
paths -- in which case the first specified path is the source
|
||
in the host, and the second path is the destination in the
|
||
container. The <code class="option">--bind-ro=</code> option creates
|
||
read-only bind mounts.</p></dd><dt id="--tmpfs="><span class="term"><code class="option">--tmpfs=</code></span><a class="headerlink" title="Permalink to this term" href="#--tmpfs=">¶</a></dt><dd><p>Mount a tmpfs file system into the container.
|
||
Takes a single absolute path argument that specifies where to
|
||
mount the tmpfs instance to (in which case the directory
|
||
access mode will be chosen as 0755, owned by root/root), or
|
||
optionally a colon-separated pair of path and mount option
|
||
string, that is used for mounting (in which case the kernel
|
||
default for access mode and owner will be chosen, unless
|
||
otherwise specified). This option is particularly useful for
|
||
mounting directories such as <code class="filename">/var</code> as
|
||
tmpfs, to allow state-less systems, in particular when
|
||
combined with <code class="option">--read-only</code>.</p></dd><dt id="--setenv="><span class="term"><code class="option">--setenv=</code></span><a class="headerlink" title="Permalink to this term" href="#--setenv=">¶</a></dt><dd><p>Specifies an environment variable assignment
|
||
to pass to the init process in the container, in the format
|
||
"<code class="literal">NAME=VALUE</code>". This may be used to override
|
||
the default variables or to set additional variables. This
|
||
parameter may be used more than once.</p></dd><dt id="--share-system"><span class="term"><code class="option">--share-system</code></span><a class="headerlink" title="Permalink to this term" href="#--share-system">¶</a></dt><dd><p>Allows the container to share certain system
|
||
facilities with the host. More specifically, this turns off
|
||
PID namespacing, UTS namespacing and IPC namespacing, and thus
|
||
allows the guest to see and interact more easily with
|
||
processes outside of the container. Note that using this
|
||
option makes it impossible to start up a full Operating System
|
||
in the container, as an init system cannot operate in this
|
||
mode. It is only useful to run specific programs or
|
||
applications this way, without involving an init system in the
|
||
container. This option implies <code class="option">--register=no</code>.
|
||
This option may not be combined with
|
||
<code class="option">--boot</code>.</p></dd><dt id="--register="><span class="term"><code class="option">--register=</code></span><a class="headerlink" title="Permalink to this term" href="#--register=">¶</a></dt><dd><p>Controls whether the container is registered
|
||
with
|
||
<a href="systemd-machined.html"><span class="citerefentry"><span class="refentrytitle">systemd-machined</span>(8)</span></a>.
|
||
Takes a boolean argument, defaults to "<code class="literal">yes</code>".
|
||
This option should be enabled when the container runs a full
|
||
Operating System (more specifically: an init system), and is
|
||
useful to ensure that the container is accessible via
|
||
<a href="machinectl.html"><span class="citerefentry"><span class="refentrytitle">machinectl</span>(1)</span></a>
|
||
and shown by tools such as
|
||
<a href="http://man7.org/linux/man-pages/man1/ps.1.html"><span class="citerefentry"><span class="refentrytitle">ps</span>(1)</span></a>.
|
||
If the container does not run an init system, it is
|
||
recommended to set this option to "<code class="literal">no</code>". Note
|
||
that <code class="option">--share-system</code> implies
|
||
<code class="option">--register=no</code>. </p></dd><dt id="--keep-unit"><span class="term"><code class="option">--keep-unit</code></span><a class="headerlink" title="Permalink to this term" href="#--keep-unit">¶</a></dt><dd><p>Instead of creating a transient scope unit to
|
||
run the container in, simply register the service or scope
|
||
unit <span class="command"><strong>systemd-nspawn</strong></span> has been invoked in
|
||
with
|
||
<a href="systemd-machined.html"><span class="citerefentry"><span class="refentrytitle">systemd-machined</span>(8)</span></a>.
|
||
This has no effect if <code class="option">--register=no</code> is used.
|
||
This switch should be used if
|
||
<span class="command"><strong>systemd-nspawn</strong></span> is invoked from within a
|
||
service unit, and the service unit's sole purpose is to run a
|
||
single <span class="command"><strong>systemd-nspawn</strong></span> container. This
|
||
option is not available if run from a user
|
||
session.</p></dd><dt id="--personality="><span class="term"><code class="option">--personality=</code></span><a class="headerlink" title="Permalink to this term" href="#--personality=">¶</a></dt><dd><p>Control the architecture ("personality")
|
||
reported by
|
||
<a href="http://man7.org/linux/man-pages/man2/uname.2.html"><span class="citerefentry"><span class="refentrytitle">uname</span>(2)</span></a>
|
||
in the container. Currently, only "<code class="literal">x86</code>" and
|
||
"<code class="literal">x86-64</code>" are supported. This is useful when
|
||
running a 32-bit container on a 64-bit host. If this setting
|
||
is not used, the personality reported in the container is the
|
||
same as the one reported on the host.</p></dd><dt id="-q"><span class="term"><code class="option">-q</code>, </span><span class="term"><code class="option">--quiet</code></span><a class="headerlink" title="Permalink to this term" href="#-q">¶</a></dt><dd><p>Turns off any status output by the tool
|
||
itself. When this switch is used, the only output from nspawn
|
||
will be the console output of the container OS
|
||
itself.</p></dd><dt id="--volatile=MODE"><span class="term"><code class="option">--volatile</code><em class="replaceable"><code>=MODE</code></em></span><a class="headerlink" title="Permalink to this term" href="#--volatile=MODE">¶</a></dt><dd><p>Boots the container in volatile mode. When no
|
||
mode parameter is passed or when mode is specified as
|
||
"<code class="literal">yes</code>" full volatile mode is enabled. This
|
||
means the root directory is mounted as mostly unpopulated
|
||
"<code class="literal">tmpfs</code>" instance, and
|
||
<code class="filename">/usr</code> from the OS tree is mounted into it,
|
||
read-only (the system thus starts up with read-only OS
|
||
resources, but pristine state and configuration, any changes
|
||
to the either are lost on shutdown). When the mode parameter
|
||
is specified as "<code class="literal">state</code>" the OS tree is
|
||
mounted read-only, but <code class="filename">/var</code> is mounted as
|
||
"<code class="literal">tmpfs</code>" instance into it (the system thus
|
||
starts up with read-only OS resources and configuration, but
|
||
pristine state, any changes to the latter are lost on
|
||
shutdown). When the mode parameter is specified as
|
||
"<code class="literal">no</code>" (the default) the whole OS tree is made
|
||
available writable.</p><p>Note that setting this to "<code class="literal">yes</code>" or
|
||
"<code class="literal">state</code>" will only work correctly with
|
||
operating systems in the container that can boot up with only
|
||
<code class="filename">/usr</code> mounted, and are able to populate
|
||
<code class="filename">/var</code> automatically, as
|
||
needed.</p></dd><dt id="-h"><span class="term"><code class="option">-h</code>, </span><span class="term"><code class="option">--help</code></span><a class="headerlink" title="Permalink to this term" href="#-h">¶</a></dt><dd><p><a name="help-text"></a>Print a short help text and exit.
|
||
</p></dd><dt id="--version"><span class="term"><code class="option">--version</code></span><a class="headerlink" title="Permalink to this term" href="#--version">¶</a></dt><dd><p><a name="version-text"></a>Print a short version string and exit.</p></dd></dl></div></div><div class="refsect1"><a name="idm140120373477968"></a><h2 id="Examples">Examples<a class="headerlink" title="Permalink to this headline" href="#Examples">¶</a></h2><div class="example"><a name="idm140120373477328"></a><p class="title"><b>Example 1. Download a Fedora image and start a shell in it</b></p><div class="example-contents"><pre class="programlisting"># machinectl pull-raw --verify=no http://ftp.halifax.rwth-aachen.de/fedora/linux/releases/21/Cloud/Images/x86_64/Fedora-Cloud-Base-20141203-21.x86_64.raw.xz
|
||
# systemd-nspawn -M Fedora-Cloud-Base-20141203-21</pre><p>This downloads an image using
|
||
<a href="machinectl.html"><span class="citerefentry"><span class="refentrytitle">machinectl</span>(1)</span></a>
|
||
and opens a shell in it.</p></div></div><br class="example-break"><div class="example"><a name="idm140120373474560"></a><p class="title"><b>Example 2. Build and boot a minimal Fedora distribution in a container</b></p><div class="example-contents"><pre class="programlisting"># dnf -y --releasever=21 --nogpg --installroot=/srv/mycontainer --disablerepo='*' --enablerepo=fedora install systemd passwd dnf fedora-release vim-minimal
|
||
# systemd-nspawn -bD /srv/mycontainer</pre><p>This installs a minimal Fedora distribution into the
|
||
directory <code class="filename">/srv/mycontainer/</code>
|
||
and then boots an OS in a namespace container in it.</p></div></div><br class="example-break"><div class="example"><a name="idm140120373471472"></a><p class="title"><b>Example 3. Spawn a shell in a container of a minimal Debian unstable distribution</b></p><div class="example-contents"><pre class="programlisting"># debootstrap --arch=amd64 unstable ~/debian-tree/
|
||
# systemd-nspawn -D ~/debian-tree/</pre><p>This installs a minimal Debian unstable distribution into
|
||
the directory <code class="filename">~/debian-tree/</code> and then
|
||
spawns a shell in a namespace container in it.</p></div></div><br class="example-break"><div class="example"><a name="idm140120373468720"></a><p class="title"><b>Example 4. Boot a minimal Arch Linux distribution in a container</b></p><div class="example-contents"><pre class="programlisting"># pacstrap -c -d ~/arch-tree/ base
|
||
# systemd-nspawn -bD ~/arch-tree/</pre><p>This installs a mimimal Arch Linux distribution into the
|
||
directory <code class="filename">~/arch-tree/</code> and then boots an OS
|
||
in a namespace container in it.</p></div></div><br class="example-break"><div class="example"><a name="idm140120373466064"></a><p class="title"><b>Example 5. Boot into an ephemeral "<code class="literal">btrfs</code>" snapshot of the host system</b></p><div class="example-contents"><pre class="programlisting"># systemd-nspawn -D / -xb</pre><p>This runs a copy of the host system in a
|
||
"<code class="literal">btrfs</code>" snapshot which is removed immediately
|
||
when the container exits. All file system changes made during
|
||
runtime will be lost on shutdown, hence.</p></div></div><br class="example-break"><div class="example"><a name="idm140120373462864"></a><p class="title"><b>Example 6. Run a container with SELinux sandbox security contexts</b></p><div class="example-contents"><pre class="programlisting"># chcon system_u:object_r:svirt_sandbox_file_t:s0:c0,c1 -R /srv/container
|
||
# systemd-nspawn -L system_u:object_r:svirt_sandbox_file_t:s0:c0,c1 -Z system_u:system_r:svirt_lxc_net_t:s0:c0,c1 -D /srv/container /bin/sh</pre></div></div><br class="example-break"></div><div class="refsect1"><a name="idm140120373461120"></a><h2 id="Exit status">Exit status<a class="headerlink" title="Permalink to this headline" href="#Exit%20status">¶</a></h2><p>The exit code of the program executed in the container is
|
||
returned.</p></div><div class="refsect1"><a name="idm140120373459888"></a><h2 id="See Also">See Also<a class="headerlink" title="Permalink to this headline" href="#See%20Also">¶</a></h2><p>
|
||
<a href="systemd.html"><span class="citerefentry"><span class="refentrytitle">systemd</span>(1)</span></a>,
|
||
<a href="http://man7.org/linux/man-pages/man1/chroot.1.html"><span class="citerefentry"><span class="refentrytitle">chroot</span>(1)</span></a>,
|
||
<a href="https://www.mankier.com/8/dnf"><span class="citerefentry"><span class="refentrytitle">dnf</span>(8)</span></a>,
|
||
<a href="http://linux.die.net/man/8/yum"><span class="citerefentry"><span class="refentrytitle">yum</span>(8)</span></a>,
|
||
<a href="http://linux.die.net/man/8/debootstrap"><span class="citerefentry"><span class="refentrytitle">debootstrap</span>(8)</span></a>,
|
||
<a href="https://www.archlinux.org/pacman/pacman.8.html"><span class="citerefentry"><span class="refentrytitle">pacman</span>(8)</span></a>,
|
||
<a href="systemd.slice.html"><span class="citerefentry"><span class="refentrytitle">systemd.slice</span>(5)</span></a>,
|
||
<a href="machinectl.html"><span class="citerefentry"><span class="refentrytitle">machinectl</span>(1)</span></a>,
|
||
<a href="btrfs.html"><span class="citerefentry"><span class="refentrytitle">btrfs</span>(8)</span></a>
|
||
</p></div></div></body></html>
|