]> git.ipfire.org Git - thirdparty/systemd.git/blob - man/systemd-nspawn.xml
nspawn: add new option "--port=" for exposing container ports on the local host
[thirdparty/systemd.git] / man / systemd-nspawn.xml
1 <?xml version='1.0'?> <!--*-nxml-*-->
2 <!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
3 "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
4
5 <!--
6 This file is part of systemd.
7
8 Copyright 2010 Lennart Poettering
9
10 systemd is free software; you can redistribute it and/or modify it
11 under the terms of the GNU Lesser General Public License as published by
12 the Free Software Foundation; either version 2.1 of the License, or
13 (at your option) any later version.
14
15 systemd is distributed in the hope that it will be useful, but
16 WITHOUT ANY WARRANTY; without even the implied warranty of
17 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
18 Lesser General Public License for more details.
19
20 You should have received a copy of the GNU Lesser General Public License
21 along with systemd; If not, see <http://www.gnu.org/licenses/>.
22 -->
23
24 <refentry id="systemd-nspawn"
25 xmlns:xi="http://www.w3.org/2001/XInclude">
26
27 <refentryinfo>
28 <title>systemd-nspawn</title>
29 <productname>systemd</productname>
30
31 <authorgroup>
32 <author>
33 <contrib>Developer</contrib>
34 <firstname>Lennart</firstname>
35 <surname>Poettering</surname>
36 <email>lennart@poettering.net</email>
37 </author>
38 </authorgroup>
39 </refentryinfo>
40
41 <refmeta>
42 <refentrytitle>systemd-nspawn</refentrytitle>
43 <manvolnum>1</manvolnum>
44 </refmeta>
45
46 <refnamediv>
47 <refname>systemd-nspawn</refname>
48 <refpurpose>Spawn a namespace container for debugging, testing and building</refpurpose>
49 </refnamediv>
50
51 <refsynopsisdiv>
52 <cmdsynopsis>
53 <command>systemd-nspawn</command>
54 <arg choice="opt" rep="repeat">OPTIONS</arg>
55 <arg choice="opt"><replaceable>COMMAND</replaceable>
56 <arg choice="opt" rep="repeat">ARGS</arg>
57 </arg>
58 </cmdsynopsis>
59 <cmdsynopsis>
60 <command>systemd-nspawn</command>
61 <arg choice="plain">-b</arg>
62 <arg choice="opt" rep="repeat">OPTIONS</arg>
63 <arg choice="opt" rep="repeat">ARGS</arg>
64 </cmdsynopsis>
65 </refsynopsisdiv>
66
67 <refsect1>
68 <title>Description</title>
69
70 <para><command>systemd-nspawn</command> may be used to
71 run a command or OS in a light-weight namespace
72 container. In many ways it is similar to
73 <citerefentry project='man-pages'><refentrytitle>chroot</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
74 but more powerful since it fully virtualizes the file
75 system hierarchy, as well as the process tree, the
76 various IPC subsystems and the host and domain
77 name.</para>
78
79 <para><command>systemd-nspawn</command> limits access
80 to various kernel interfaces in the container to
81 read-only, such as <filename>/sys</filename>,
82 <filename>/proc/sys</filename> or
83 <filename>/sys/fs/selinux</filename>. Network
84 interfaces and the system clock may not be changed
85 from within the container. Device nodes may not be
86 created. The host system cannot be rebooted and kernel
87 modules may not be loaded from within the
88 container.</para>
89
90 <para>Note that even though these security precautions
91 are taken <command>systemd-nspawn</command> is not
92 suitable for secure container setups. Many of the
93 security features may be circumvented and are hence
94 primarily useful to avoid accidental changes to the
95 host system from the container. The intended use of
96 this program is debugging and testing as well as
97 building of packages, distributions and software
98 involved with boot and systems management.</para>
99
100 <para>In contrast to
101 <citerefentry project='man-pages'><refentrytitle>chroot</refentrytitle><manvolnum>1</manvolnum></citerefentry> <command>systemd-nspawn</command>
102 may be used to boot full Linux-based operating systems
103 in a container.</para>
104
105 <para>Use a tool like
106 <citerefentry project='die-net'><refentrytitle>yum</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
107 <citerefentry project='die-net'><refentrytitle>debootstrap</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
108 or
109 <citerefentry project='archlinux'><refentrytitle>pacman</refentrytitle><manvolnum>8</manvolnum></citerefentry>
110 to set up an OS directory tree suitable as file system
111 hierarchy for <command>systemd-nspawn</command>
112 containers.</para>
113
114 <para>Note that <command>systemd-nspawn</command> will
115 mount file systems private to the container to
116 <filename>/dev</filename>,
117 <filename>/run</filename> and similar. These will
118 not be visible outside of the container, and their
119 contents will be lost when the container exits.</para>
120
121 <para>Note that running two
122 <command>systemd-nspawn</command> containers from the
123 same directory tree will not make processes in them
124 see each other. The PID namespace separation of the
125 two containers is complete and the containers will
126 share very few runtime objects except for the
127 underlying file system. Use
128 <citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s
129 <command>login</command> command to request an
130 additional login prompt in a running container.</para>
131
132 <para><command>systemd-nspawn</command> implements the
133 <ulink
134 url="http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface">Container
135 Interface</ulink> specification.</para>
136
137 <para>As a safety check
138 <command>systemd-nspawn</command> will verify the
139 existence of <filename>/usr/lib/os-release</filename>
140 or <filename>/etc/os-release</filename> in the
141 container tree before starting the container (see
142 <citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry>). It
143 might be necessary to add this file to the container
144 tree manually if the OS of the container is too old to
145 contain this file out-of-the-box.</para>
146 </refsect1>
147
148 <refsect1>
149 <title>Options</title>
150
151 <para>If option <option>-b</option> is specified, the
152 arguments are used as arguments for the init
153 binary. Otherwise, <replaceable>COMMAND</replaceable>
154 specifies the program to launch in the container, and
155 the remaining arguments are used as arguments for this
156 program. If <option>-b</option> is not used and no
157 arguments are specifed, a shell is launched in the
158 container.</para>
159
160 <para>The following options are understood:</para>
161
162 <variablelist>
163 <varlistentry>
164 <term><option>-D</option></term>
165 <term><option>--directory=</option></term>
166
167 <listitem><para>Directory to use as
168 file system root for the container.</para>
169
170 <para>If neither
171 <option>--directory=</option>, nor
172 <option>--image=</option> is specified
173 the directory is determined as
174 <filename>/var/lib/container/</filename>
175 suffixed by the machine name as
176 specified with
177 <option>--machine=</option>. If
178 neither <option>--directory=</option>,
179 <option>--image=</option>, nor
180 <option>--machine=</option> are
181 specified, the current directory will
182 be used. May not be specified together
183 with
184 <option>--image=</option>.</para></listitem>
185 </varlistentry>
186
187 <varlistentry>
188 <term><option>--template=</option></term>
189
190 <listitem><para>Directory or
191 <literal>btrfs</literal> subvolume to
192 use as template for the container's
193 root directory. If this is specified
194 and the container's root directory (as
195 configured by
196 <option>--directory=</option>) does
197 not yet exist it is created as
198 <literal>btrfs</literal> subvolume and
199 populated from this template
200 tree. Ideally, the specified template
201 path refers to the root of a
202 <literal>btrfs</literal> subvolume, in
203 which case a simple copy-on-write
204 snapshot is taken, and populating the
205 root directory is instant. If the
206 specified template path does not refer
207 to the root of a
208 <literal>btrfs</literal> subvolume (or
209 not even to a <literal>btrfs</literal>
210 file system at all), the tree is
211 copied, which can be substantially
212 more time-consuming. Note that if this
213 option is used the container's root
214 directory (in contrast to the template
215 directory!) must be located on a
216 <literal>btrfs</literal> file system,
217 so that the <literal>btrfs</literal>
218 subvolume may be created. May not be
219 specified together with
220 <option>--image=</option> or
221 <option>--ephemeral</option>.</para></listitem>
222 </varlistentry>
223
224 <varlistentry>
225 <term><option>-x</option></term>
226 <term><option>--ephemeral</option></term>
227
228 <listitem><para>If specified, the
229 container is run with a temporary
230 <literal>btrfs</literal> snapshot of
231 its root directory (as configured with
232 <option>--directory=</option>), that
233 is removed immediately when the
234 container terminates. This option is
235 only supported if the root file system
236 is <literal>btrfs</literal>. May not
237 be specified together with
238 <option>--image=</option> or
239 <option>--template=</option>.</para></listitem>
240 </varlistentry>
241
242 <varlistentry>
243 <term><option>-i</option></term>
244 <term><option>--image=</option></term>
245
246 <listitem><para>Disk image to mount
247 the root directory for the container
248 from. Takes a path to a regular file
249 or to a block device node. The file or
250 block device must contain a GUID
251 Partition Table with a root partition
252 which is mounted as the root directory
253 of the container. Optionally, it may
254 contain a home and/or a server data
255 partition which are mounted to the
256 appropriate places in the
257 container. All these partitions must
258 be identified by the partition types
259 defined by the <ulink
260 url="http://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/">Discoverable
261 Partitions Specification</ulink>. Any
262 other partitions, such as foreign
263 partitions, swap partitions or EFI
264 system partitions are not mounted. May
265 not be specified together with
266 <option>--directory=</option>,
267 <option>--template=</option> or
268 <option>--ephemeral</option>.</para></listitem>
269 </varlistentry>
270
271 <varlistentry>
272 <term><option>-b</option></term>
273 <term><option>--boot</option></term>
274
275 <listitem><para>Automatically search
276 for an init binary and invoke it
277 instead of a shell or a user supplied
278 program. If this option is used,
279 arguments specified on the command
280 line are used as arguments for the
281 init binary. This option may not be
282 combined with
283 <option>--share-system</option>.
284 </para></listitem>
285 </varlistentry>
286
287 <varlistentry>
288 <term><option>-u</option></term>
289 <term><option>--user=</option></term>
290
291 <listitem><para>After transitioning
292 into the container, change to the
293 specified user-defined in the
294 container's user database. Like all
295 other systemd-nspawn features, this is
296 not a security feature and provides
297 protection against accidental
298 destructive operations
299 only.</para></listitem>
300 </varlistentry>
301
302 <varlistentry>
303 <term><option>-M</option></term>
304 <term><option>--machine=</option></term>
305
306 <listitem><para>Sets the machine name
307 for this container. This name may be
308 used to identify this container during
309 its runtime (for example in tools like
310 <citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
311 and similar), and is used to
312 initialize the container's hostname
313 (which the container can choose to
314 override, however). If not specified,
315 the last component of the root
316 directory path of the container is
317 used, possibly suffixed with a random
318 identifier in case
319 <option>--ephemeral</option> mode is
320 selected. If the root directory
321 selected is the host's root directory
322 the host's hostname is used as default
323 instead.</para></listitem>
324 </varlistentry>
325
326 <varlistentry>
327 <term><option>--uuid=</option></term>
328
329 <listitem><para>Set the specified UUID
330 for the container. The init system
331 will initialize
332 <filename>/etc/machine-id</filename>
333 from this if this file is not set yet.
334 </para></listitem>
335 </varlistentry>
336
337 <varlistentry>
338 <term><option>--slice=</option></term>
339
340 <listitem><para>Make the container
341 part of the specified slice, instead
342 of the default
343 <filename>machine.slice</filename>.</para>
344 </listitem>
345 </varlistentry>
346
347 <varlistentry>
348 <term><option>--private-network</option></term>
349
350 <listitem><para>Disconnect networking
351 of the container from the host. This
352 makes all network interfaces
353 unavailable in the container, with the
354 exception of the loopback device and
355 those specified with
356 <option>--network-interface=</option>
357 and configured with
358 <option>--network-veth</option>. If
359 this option is specified, the
360 CAP_NET_ADMIN capability will be added
361 to the set of capabilities the
362 container retains. The latter may be
363 disabled by using
364 <option>--drop-capability=</option>.</para></listitem>
365 </varlistentry>
366
367 <varlistentry>
368 <term><option>--network-interface=</option></term>
369
370 <listitem><para>Assign the specified
371 network interface to the
372 container. This will remove the
373 specified interface from the calling
374 namespace and place it in the
375 container. When the container
376 terminates, it is moved back to the
377 host namespace. Note that
378 <option>--network-interface=</option>
379 implies
380 <option>--private-network</option>. This
381 option may be used more than once to
382 add multiple network interfaces to the
383 container.</para></listitem>
384 </varlistentry>
385
386 <varlistentry>
387 <term><option>--network-macvlan=</option></term>
388
389 <listitem><para>Create a
390 <literal>macvlan</literal> interface
391 of the specified Ethernet network
392 interface and add it to the
393 container. A
394 <literal>macvlan</literal> interface
395 is a virtual interface that adds a
396 second MAC address to an existing
397 physical Ethernet link. The interface
398 in the container will be named after
399 the interface on the host, prefixed
400 with <literal>mv-</literal>. Note that
401 <option>--network-macvlan=</option>
402 implies
403 <option>--private-network</option>. This
404 option may be used more than once to
405 add multiple network interfaces to the
406 container.</para></listitem>
407 </varlistentry>
408
409 <varlistentry>
410 <term><option>--network-veth</option></term>
411
412 <listitem><para>Create a virtual
413 Ethernet link
414 (<literal>veth</literal>) between host
415 and container. The host side of the
416 Ethernet link will be available as a
417 network interface named after the
418 container's name (as specified with
419 <option>--machine=</option>), prefixed
420 with <literal>ve-</literal>. The
421 container side of the Ethernet
422 link will be named
423 <literal>host0</literal>. Note that
424 <option>--network-veth</option>
425 implies
426 <option>--private-network</option>.</para></listitem>
427 </varlistentry>
428
429 <varlistentry>
430 <term><option>--network-bridge=</option></term>
431
432 <listitem><para>Adds the host side of
433 the Ethernet link created with
434 <option>--network-veth</option> to the
435 specified bridge. Note that
436 <option>--network-bridge=</option>
437 implies
438 <option>--network-veth</option>. If
439 this option is used, the host side of
440 the Ethernet link will use the
441 <literal>vb-</literal> prefix instead
442 of <literal>ve-</literal>.</para></listitem>
443 </varlistentry>
444
445 <varlistentry>
446 <term><option>-p</option></term>
447 <term><option>--port=</option></term>
448
449 <listitem><para>If private networking
450 is enabled, maps an IP port on the
451 host onto an IP port on the
452 container. Takes a protocol specifier
453 (either <literal>tcp</literal> or
454 <literal>udp</literal>), separated by
455 a colon from a host port number in the
456 range 1 to 65535, separated by a colon
457 from a container port number in the
458 range from 1 to 65535. The protocol
459 specifier and its separating colon may
460 be omitted, in which case
461 <literal>tcp</literal> is assumed.
462 The container port number and its
463 colon may be ommitted, in which case
464 the same port as the host port is
465 implied. This option is only supported
466 if private networking is used, such as
467 <option>--network-veth</option> or
468 <option>--network-bridge=</option>.</para></listitem>
469 </varlistentry>
470
471 <varlistentry>
472 <term><option>-Z</option></term>
473 <term><option>--selinux-context=</option></term>
474
475 <listitem><para>Sets the SELinux
476 security context to be used to label
477 processes in the container.</para>
478 </listitem>
479 </varlistentry>
480
481 <varlistentry>
482 <term><option>-L</option></term>
483 <term><option>--selinux-apifs-context=</option></term>
484
485 <listitem><para>Sets the SELinux security
486 context to be used to label files in
487 the virtual API file systems in the
488 container.</para>
489 </listitem>
490 </varlistentry>
491
492 <varlistentry>
493 <term><option>--capability=</option></term>
494
495 <listitem><para>List one or more
496 additional capabilities to grant the
497 container. Takes a comma-separated
498 list of capability names, see
499 <citerefentry project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>
500 for more information. Note that the
501 following capabilities will be granted
502 in any way: CAP_CHOWN,
503 CAP_DAC_OVERRIDE, CAP_DAC_READ_SEARCH,
504 CAP_FOWNER, CAP_FSETID, CAP_IPC_OWNER,
505 CAP_KILL, CAP_LEASE,
506 CAP_LINUX_IMMUTABLE,
507 CAP_NET_BIND_SERVICE,
508 CAP_NET_BROADCAST, CAP_NET_RAW,
509 CAP_SETGID, CAP_SETFCAP, CAP_SETPCAP,
510 CAP_SETUID, CAP_SYS_ADMIN,
511 CAP_SYS_CHROOT, CAP_SYS_NICE,
512 CAP_SYS_PTRACE, CAP_SYS_TTY_CONFIG,
513 CAP_SYS_RESOURCE, CAP_SYS_BOOT,
514 CAP_AUDIT_WRITE,
515 CAP_AUDIT_CONTROL. Also CAP_NET_ADMIN
516 is retained if
517 <option>--private-network</option> is
518 specified. If the special value
519 <literal>all</literal> is passed, all
520 capabilities are
521 retained.</para></listitem>
522 </varlistentry>
523
524 <varlistentry>
525 <term><option>--drop-capability=</option></term>
526
527 <listitem><para>Specify one or more
528 additional capabilities to drop for
529 the container. This allows running the
530 container with fewer capabilities than
531 the default (see above).</para></listitem>
532 </varlistentry>
533
534 <varlistentry>
535 <term><option>--link-journal=</option></term>
536
537 <listitem><para>Control whether the
538 container's journal shall be made
539 visible to the host system. If enabled,
540 allows viewing the container's journal
541 files from the host (but not vice
542 versa). Takes one of
543 <literal>no</literal>,
544 <literal>host</literal>,
545 <literal>try-host</literal>,
546 <literal>guest</literal>,
547 <literal>try-guest</literal>,
548 <literal>auto</literal>. If
549 <literal>no</literal>, the journal is
550 not linked. If <literal>host</literal>,
551 the journal files are stored on the
552 host file system (beneath
553 <filename>/var/log/journal/<replaceable>machine-id</replaceable></filename>)
554 and the subdirectory is bind-mounted
555 into the container at the same
556 location. If <literal>guest</literal>,
557 the journal files are stored on the
558 guest file system (beneath
559 <filename>/var/log/journal/<replaceable>machine-id</replaceable></filename>)
560 and the subdirectory is symlinked into the host
561 at the same location. <literal>try-host</literal>
562 and <literal>try-guest</literal> do the same
563 but do not fail if the host does not have
564 persistent journalling enabled.
565 If <literal>auto</literal> (the default),
566 and the right subdirectory of
567 <filename>/var/log/journal</filename>
568 exists, it will be bind mounted
569 into the container. If the
570 subdirectory does not exist, no
571 linking is performed. Effectively,
572 booting a container once with
573 <literal>guest</literal> or
574 <literal>host</literal> will link the
575 journal persistently if further on
576 the default of <literal>auto</literal>
577 is used.</para></listitem>
578 </varlistentry>
579
580 <varlistentry>
581 <term><option>-j</option></term>
582
583 <listitem><para>Equivalent to
584 <option>--link-journal=try-guest</option>.</para></listitem>
585 </varlistentry>
586
587 <varlistentry>
588 <term><option>--read-only</option></term>
589
590 <listitem><para>Mount the root file
591 system read-only for the
592 container.</para></listitem>
593 </varlistentry>
594
595 <varlistentry>
596 <term><option>--bind=</option></term>
597 <term><option>--bind-ro=</option></term>
598
599 <listitem><para>Bind mount a file or
600 directory from the host into the
601 container. Either takes a path
602 argument -- in which case the
603 specified path will be mounted from
604 the host to the same path in the
605 container --, or a colon-separated
606 pair of paths -- in which case the
607 first specified path is the source in
608 the host, and the second path is the
609 destination in the container. The
610 <option>--bind-ro=</option> option
611 creates read-only bind
612 mounts.</para></listitem>
613 </varlistentry>
614
615 <varlistentry>
616 <term><option>--tmpfs=</option></term>
617
618 <listitem><para>Mount a tmpfs file
619 system into the container. Takes a
620 single absolute path argument that
621 specifies where to mount the tmpfs
622 instance to (in which case the
623 directory access mode will be chosen
624 as 0755, owned by root/root), or
625 optionally a colon-separated pair of
626 path and mount option string, that is
627 used for mounting (in which case the
628 kernel default for access mode and
629 owner will be chosen, unless otherwise
630 specified). This option is
631 particularly useful for mounting
632 directories such as
633 <filename>/var</filename> as tmpfs, to
634 allow state-less systems, in
635 particular when combined with
636 <option>--read-only</option>.</para></listitem>
637 </varlistentry>
638
639 <varlistentry>
640 <term><option>--setenv=</option></term>
641
642 <listitem><para>Specifies an
643 environment variable assignment to
644 pass to the init process in the
645 container, in the format
646 <literal>NAME=VALUE</literal>. This
647 may be used to override the default
648 variables or to set additional
649 variables. This parameter may be used
650 more than once.</para></listitem>
651 </varlistentry>
652
653 <varlistentry>
654 <term><option>--share-system</option></term>
655
656 <listitem><para>Allows the container
657 to share certain system facilities
658 with the host. More specifically, this
659 turns off PID namespacing, UTS
660 namespacing and IPC namespacing, and
661 thus allows the guest to see and
662 interact more easily with processes
663 outside of the container. Note that
664 using this option makes it impossible
665 to start up a full Operating System in
666 the container, as an init system
667 cannot operate in this mode. It is
668 only useful to run specific programs
669 or applications this way, without
670 involving an init system in the
671 container. This option implies
672 <option>--register=no</option>. This
673 option may not be combined with
674 <option>--boot</option>.</para></listitem>
675 </varlistentry>
676
677 <varlistentry>
678 <term><option>--register=</option></term>
679
680 <listitem><para>Controls whether the
681 container is registered with
682 <citerefentry><refentrytitle>systemd-machined</refentrytitle><manvolnum>8</manvolnum></citerefentry>. Takes
683 a boolean argument, defaults to
684 <literal>yes</literal>. This option
685 should be enabled when the container
686 runs a full Operating System (more
687 specifically: an init system), and is
688 useful to ensure that the container is
689 accessible via
690 <citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
691 and shown by tools such as
692 <citerefentry project='man-pages'><refentrytitle>ps</refentrytitle><manvolnum>1</manvolnum></citerefentry>. If
693 the container does not run an init
694 system, it is recommended to set this
695 option to <literal>no</literal>. Note
696 that <option>--share-system</option>
697 implies
698 <option>--register=no</option>.
699 </para></listitem>
700 </varlistentry>
701
702 <varlistentry>
703 <term><option>--keep-unit</option></term>
704
705 <listitem><para>Instead of creating a
706 transient scope unit to run the
707 container in, simply register the
708 service or scope unit
709 <command>systemd-nspawn</command> has
710 been invoked in with
711 <citerefentry><refentrytitle>systemd-machined</refentrytitle><manvolnum>8</manvolnum></citerefentry>. This
712 has no effect if
713 <option>--register=no</option> is
714 used. This switch should be used if
715 <command>systemd-nspawn</command> is
716 invoked from within a service unit,
717 and the service unit's sole purpose
718 is to run a single
719 <command>systemd-nspawn</command>
720 container. This option is not
721 available if run from a user
722 session.</para></listitem>
723 </varlistentry>
724
725 <varlistentry>
726 <term><option>--personality=</option></term>
727
728 <listitem><para>Control the
729 architecture ("personality") reported
730 by
731 <citerefentry><refentrytitle>uname</refentrytitle><manvolnum>2</manvolnum></citerefentry>
732 in the container. Currently, only
733 <literal>x86</literal> and
734 <literal>x86-64</literal> are
735 supported. This is useful when running
736 a 32-bit container on a 64-bit
737 host. If this setting is not used,
738 the personality reported in the
739 container is the same as the one
740 reported on the
741 host.</para></listitem>
742 </varlistentry>
743
744 <varlistentry>
745 <term><option>-q</option></term>
746 <term><option>--quiet</option></term>
747
748 <listitem><para>Turns off any status
749 output by the tool itself. When this
750 switch is used, the only output
751 from nspawn will be the console output
752 of the container OS itself.</para></listitem>
753 </varlistentry>
754
755 <varlistentry>
756 <term><option>--volatile</option><replaceable>=MODE</replaceable></term>
757
758 <listitem><para>Boots the container in
759 volatile mode. When no mode parameter
760 is passed or when mode is specified as
761 <literal>yes</literal> full volatile
762 mode is enabled. This means the root
763 directory is mounted as mostly
764 unpopulated <literal>tmpfs</literal>
765 instance, and
766 <filename>/usr</filename> from the OS
767 tree is mounted into it, read-only
768 (the system thus starts up with
769 read-only OS resources, but pristine
770 state and configuration, any changes
771 to the either are lost on
772 shutdown). When the mode parameter is
773 specified as <literal>state</literal>
774 the OS tree is mounted read-only, but
775 <filename>/var</filename> is mounted
776 as <literal>tmpfs</literal> instance
777 into it (the system thus starts up
778 with read-only OS resources and
779 configuration, but pristine state, any
780 changes to the latter are lost on
781 shutdown). When the mode parameter is
782 specified as <literal>no</literal>
783 (the default) the whole OS tree is
784 made available writable.</para>
785
786 <para>Note that setting this to
787 <literal>yes</literal> or
788 <literal>state</literal> will only
789 work correctly with operating systems
790 in the container that can boot up with
791 only <filename>/usr</filename>
792 mounted, and are able to populate
793 <filename>/var</filename>
794 automatically, as
795 needed.</para></listitem>
796 </varlistentry>
797
798 <xi:include href="standard-options.xml" xpointer="help" />
799 <xi:include href="standard-options.xml" xpointer="version" />
800 </variablelist>
801
802 </refsect1>
803
804 <refsect1>
805 <title>Examples</title>
806 <example>
807 <title>Boot a minimal Fedora distribution in a container</title>
808
809 <programlisting># yum -y --releasever=21 --nogpg --installroot=/srv/mycontainer --disablerepo='*' --enablerepo=fedora install systemd passwd yum fedora-release vim-minimal
810 # systemd-nspawn -bD /srv/mycontainer</programlisting>
811
812 <para>This installs a minimal Fedora distribution into
813 the directory <filename noindex='true'>/srv/mycontainer/</filename> and
814 then boots an OS in a namespace container in
815 it.</para>
816 </example>
817
818 <example>
819 <title>Spawn a shell in a container of a minimal Debian unstable distribution</title>
820
821 <programlisting># debootstrap --arch=amd64 unstable ~/debian-tree/
822 # systemd-nspawn -D ~/debian-tree/</programlisting>
823
824 <para>This installs a minimal Debian unstable
825 distribution into the directory
826 <filename>~/debian-tree/</filename> and then spawns a
827 shell in a namespace container in it.</para>
828 </example>
829
830 <example>
831 <title>Boot a minimal Arch Linux distribution in a container</title>
832
833 <programlisting># pacstrap -c -d ~/arch-tree/ base
834 # systemd-nspawn -bD ~/arch-tree/</programlisting>
835
836 <para>This installs a mimimal Arch Linux distribution into
837 the directory <filename>~/arch-tree/</filename> and then
838 boots an OS in a namespace container in it.</para>
839 </example>
840
841 <example>
842 <title>Enable Arch Linux container on boot</title>
843
844 <programlisting># mv ~/arch-tree /var/lib/container/arch
845 # systemctl enable systemd-nspawn@arch.service
846 # systemctl start systemd-nspawn@arch.service</programlisting>
847
848 <para>This makes the Arch Linux container part of the
849 <filename>multi-user.target</filename> on the host.
850 </para>
851 </example>
852
853 <example>
854 <title>Boot into an ephemeral <literal>btrfs</literal> snapshot of the host system</title>
855
856 <programlisting># systemd-nspawn -D / -xb</programlisting>
857
858 <para>This runs a copy of the host system in a
859 <literal>btrfs</literal> snapshot which is
860 removed immediately when the container
861 exits. All file system changes made during
862 runtime will be lost on shutdown,
863 hence.</para>
864 </example>
865
866 <example>
867 <title>Run a container with SELinux sandbox security contexts</title>
868
869 <programlisting># chcon system_u:object_r:svirt_sandbox_file_t:s0:c0,c1 -R /srv/container
870 # 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</programlisting>
871 </example>
872 </refsect1>
873
874 <refsect1>
875 <title>Exit status</title>
876
877 <para>The exit code of the program executed in the
878 container is returned.</para>
879 </refsect1>
880
881 <refsect1>
882 <title>See Also</title>
883 <para>
884 <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
885 <citerefentry project='man-pages'><refentrytitle>chroot</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
886 <citerefentry project='die-net'><refentrytitle>yum</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
887 <citerefentry project='die-net'><refentrytitle>debootstrap</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
888 <citerefentry project='archlinux'><refentrytitle>pacman</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
889 <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
890 <citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
891 <citerefentry><refentrytitle>btrfs</refentrytitle><manvolnum>8</manvolnum></citerefentry>
892 </para>
893 </refsect1>
894
895 </refentry>