3 lxc: linux Container library
5 (C) Copyright IBM Corp. 2007, 2008
8 Daniel Lezcano <daniel.lezcano at free.fr>
10 This library is free software; you can redistribute it and/or
11 modify it under the terms of the GNU Lesser General Public
12 License as published by the Free Software Foundation; either
13 version 2.1 of the License, or (at your option) any later version.
15 This library is distributed in the hope that it will be useful,
16 but 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.
20 You should have received a copy of the GNU Lesser General Public
21 License along with this library; if not, write to the Free Software
22 Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
26 <!DOCTYPE refentry PUBLIC @docdtd@ [
28 <!ENTITY seealso SYSTEM "@builddir@/see_also.sgml">
33 <docinfo><date>@LXC_GENERATE_DATE@</date></docinfo>
36 <refentrytitle>lxc.conf</refentrytitle>
37 <manvolnum>5</manvolnum>
41 <refname>lxc.conf</refname>
44 linux container configuration file
49 <title>Description</title>
52 The linux containers (<command>lxc</command>) are always created
53 before being used. This creation defines a set of system
54 resources to be virtualized / isolated when a process is using
55 the container. By default, the pids, sysv ipc and mount points
56 are virtualized and isolated. The other system resources are
57 shared across containers, until they are explicitly defined in
58 the configuration file. For example, if there is no network
59 configuration, the network will be shared between the creator of
60 the container and the container itself, but if the network is
61 specified, a new network stack is created for the container and
62 the container can no longer use the network of its ancestor.
66 The configuration file defines the different system resources to
67 be assigned for the container. At present, the utsname, the
68 network, the mount points, the root file system, the user namespace,
69 and the control groups are supported.
73 Each option in the configuration file has the form <command>key
74 = value</command> fitting in one line. The '#' character means
75 the line is a comment.
79 <title>Configuration</title>
81 In order to ease administration of multiple related containers, it
82 is possible to have a container configuration file cause another
83 file to be loaded. For instance, network configuration
84 can be defined in one common file which is included by multiple
85 containers. Then, if the containers are moved to another host,
86 only one file may need to be updated.
92 <option>lxc.include</option>
96 Specify the file to be included. The included file must be
97 in the same valid lxc configuration file format.
105 <title>Architecture</title>
107 Allows one to set the architecture for the container. For example,
108 set a 32bits architecture for a container running 32bits
109 binaries on a 64bits host. This fixes the container scripts
110 which rely on the architecture to do some work like
111 downloading the packages.
117 <option>lxc.arch</option>
121 Specify the architecture for the container.
125 <option>x86</option>,
126 <option>i686</option>,
127 <option>x86_64</option>,
128 <option>amd64</option>
137 <title>Hostname</title>
139 The utsname section defines the hostname to be set for the
140 container. That means the container can set its own hostname
141 without changing the one from the system. That makes the
142 hostname private for the container.
147 <option>lxc.utsname</option>
151 specify the hostname for the container
159 <title>Halt signal</title>
161 Allows one to specify signal name or number, sent by lxc-stop to the
162 container's init process to cleanly shutdown the container. Different
163 init systems could use different signals to perform clean shutdown
164 sequence. This option allows the signal to be specified in kill(1)
165 fashion, e.g. SIGPWR, SIGRTMIN+14, SIGRTMAX-10 or plain number. The
166 default signal is SIGPWR.
171 <option>lxc.haltsignal</option>
175 specify the signal used to halt the container
183 <title>Stop signal</title>
185 Allows one to specify signal name or number, sent by lxc-stop to forcibly
186 shutdown the container. This option allows signal to be specified in
187 kill(1) fashion, e.g. SIGKILL, SIGRTMIN+14, SIGRTMAX-10 or plain number.
188 The default signal is SIGKILL.
193 <option>lxc.stopsignal</option>
197 specify the signal used to stop the container
205 <title>Network</title>
207 The network section defines how the network is virtualized in
208 the container. The network virtualization acts at layer
209 two. In order to use the network virtualization, parameters
210 must be specified to define the network interfaces of the
211 container. Several virtual interfaces can be assigned and used
212 in a container even if the system has only one physical
218 <option>lxc.network.type</option>
222 specify what kind of network virtualization to be used
223 for the container. Each time
224 a <option>lxc.network.type</option> field is found a new
225 round of network configuration begins. In this way,
226 several network virtualization types can be specified
227 for the same container, as well as assigning several
228 network interfaces for one container. The different
229 virtualization types can be:
233 <option>none:</option> will cause the container to share
234 the host's network namespace. This means the host
235 network devices are usable in the container. It also
236 means that if both the container and host have upstart as
237 init, 'halt' in a container (for instance) will shut down the
242 <option>empty:</option> will create only the loopback
247 <option>veth:</option> a peer network device is created
248 with one side assigned to the container and the other
249 side is attached to a bridge specified by
250 the <option>lxc.network.link</option>. If the bridge is
251 not specified, then the veth pair device will be created
252 but not attached to any bridge. Otherwise, the bridge
253 has to be setup before on the
254 system, <command>lxc</command> won't handle any
255 configuration outside of the container. By
256 default <command>lxc</command> choose a name for the
257 network device belonging to the outside of the
258 container, this name is handled
259 by <command>lxc</command>, but if you wish to handle
260 this name yourself, you can tell <command>lxc</command>
261 to set a specific name with
262 the <option>lxc.network.veth.pair</option> option.
266 <option>vlan:</option> a vlan interface is linked with
267 the interface specified by
268 the <option>lxc.network.link</option> and assigned to
269 the container. The vlan identifier is specified with the
270 option <option>lxc.network.vlan.id</option>.
274 <option>macvlan:</option> a macvlan interface is linked
275 with the interface specified by
276 the <option>lxc.network.link</option> and assigned to
278 <option>lxc.network.macvlan.mode</option> specifies the
279 mode the macvlan will use to communicate between
280 different macvlan on the same upper device. The accepted
281 modes are <option>private</option>, the device never
282 communicates with any other device on the same upper_dev (default),
283 <option>vepa</option>, the new Virtual Ethernet Port
284 Aggregator (VEPA) mode, it assumes that the adjacent
285 bridge returns all frames where both source and
286 destination are local to the macvlan port, i.e. the
287 bridge is set up as a reflective relay. Broadcast
288 frames coming in from the upper_dev get flooded to all
289 macvlan interfaces in VEPA mode, local frames are not
290 delivered locally, or <option>bridge</option>, it
291 provides the behavior of a simple bridge between
292 different macvlan interfaces on the same port. Frames
293 from one interface to another one get delivered directly
294 and are not sent out externally. Broadcast frames get
295 flooded to all other bridge ports and to the external
296 interface, but when they come back from a reflective
297 relay, we don't deliver them again. Since we know all
298 the MAC addresses, the macvlan bridge mode does not
299 require learning or STP like the bridge module does.
303 <option>phys:</option> an already existing interface
304 specified by the <option>lxc.network.link</option> is
305 assigned to the container.
312 <option>lxc.network.flags</option>
316 specify an action to do for the
320 <para><option>up:</option> activates the interface.
327 <option>lxc.network.link</option>
331 specify the interface to be used for real network
339 <option>lxc.network.mtu</option>
343 specify the maximum transfer unit for this interface.
350 <option>lxc.network.name</option>
354 the interface name is dynamically allocated, but if
355 another name is needed because the configuration files
356 being used by the container use a generic name,
357 eg. eth0, this option will rename the interface in the
365 <option>lxc.network.hwaddr</option>
369 the interface mac address is dynamically allocated by
370 default to the virtual interface, but in some cases,
371 this is needed to resolve a mac address conflict or to
372 always have the same link-local ipv6 address.
373 Any "x" in address will be replaced by random value,
374 this allows setting hwaddr templates.
381 <option>lxc.network.ipv4</option>
385 specify the ipv4 address to assign to the virtualized
386 interface. Several lines specify several ipv4 addresses.
387 The address is in format x.y.z.t/m,
388 eg. 192.168.1.123/24. The broadcast address should be
389 specified on the same line, right after the ipv4
397 <option>lxc.network.ipv4.gateway</option>
401 specify the ipv4 address to use as the gateway inside the
402 container. The address is in format x.y.z.t, eg.
405 Can also have the special value <option>auto</option>,
406 which means to take the primary address from the bridge
407 interface (as specified by the
408 <option>lxc.network.link</option> option) and use that as
409 the gateway. <option>auto</option> is only available when
410 using the <option>veth</option> and
411 <option>macvlan</option> network types.
419 <option>lxc.network.ipv6</option>
423 specify the ipv6 address to assign to the virtualized
424 interface. Several lines specify several ipv6 addresses.
425 The address is in format x::y/m,
426 eg. 2003:db8:1:0:214:1234:fe0b:3596/64
433 <option>lxc.network.ipv6.gateway</option>
437 specify the ipv6 address to use as the gateway inside the
438 container. The address is in format x::y,
441 Can also have the special value <option>auto</option>,
442 which means to take the primary address from the bridge
443 interface (as specified by the
444 <option>lxc.network.link</option> option) and use that as
445 the gateway. <option>auto</option> is only available when
446 using the <option>veth</option> and
447 <option>macvlan</option> network types.
454 <option>lxc.network.script.up</option>
458 add a configuration option to specify a script to be
459 executed after creating and configuring the network used
460 from the host side. The following arguments are passed
461 to the script: container name and config section name
462 (net) Additional arguments depend on the config section
463 employing a script hook; the following are used by the
464 network system: execution context (up), network type
465 (empty/veth/macvlan/phys), Depending on the network
466 type, other arguments may be passed:
467 veth/macvlan/phys. And finally (host-sided) device name.
470 Standard output from the script is logged at debug level.
471 Standard error is not logged, but can be captured by the
472 hook redirecting its standard error to standard output.
479 <option>lxc.network.script.down</option>
483 add a configuration option to specify a script to be
484 executed before destroying the network used from the
485 host side. The following arguments are passed to the
486 script: container name and config section name (net)
487 Additional arguments depend on the config section
488 employing a script hook; the following are used by the
489 network system: execution context (down), network type
490 (empty/veth/macvlan/phys), Depending on the network
491 type, other arguments may be passed:
492 veth/macvlan/phys. And finally (host-sided) device name.
495 Standard output from the script is logged at debug level.
496 Standard error is not logged, but can be captured by the
497 hook redirecting its standard error to standard output.
505 <title>New pseudo tty instance (devpts)</title>
507 For stricter isolation the container can have its own private
508 instance of the pseudo tty.
513 <option>lxc.pts</option>
517 If set, the container will have a new pseudo tty
518 instance, making this private to it. The value specifies
519 the maximum number of pseudo ttys allowed for a pts
520 instance (this limitation is not implemented yet).
528 <title>Container system console</title>
530 If the container is configured with a root filesystem and the
531 inittab file is setup to use the console, you may want to specify
532 where the output of this console goes.
537 <option>lxc.console</option>
541 Specify a path to a file where the console output will
542 be written. The keyword 'none' will simply disable the
543 console. This is dangerous once if have a rootfs with a
544 console device file where the application can write, the
545 messages will fall in the host.
553 <title>Console through the ttys</title>
555 This option is useful if the container is configured with a root
556 filesystem and the inittab file is setup to launch a getty on the
557 ttys. The option specifies the number of ttys to be available for
558 the container. The number of gettys in the inittab file of the
559 container should not be greater than the number of ttys specified
560 in this option, otherwise the excess getty sessions will die and
561 respawn indefinitely giving annoying messages on the console or in
562 <filename>/var/log/messages</filename>.
567 <option>lxc.tty</option>
571 Specify the number of tty to make available to the
580 <title>Console devices location</title>
582 LXC consoles are provided through Unix98 PTYs created on the
583 host and bind-mounted over the expected devices in the container.
584 By default, they are bind-mounted over <filename>/dev/console</filename>
585 and <filename>/dev/ttyN</filename>. This can prevent package upgrades
586 in the guest. Therefore you can specify a directory location (under
587 <filename>/dev</filename> under which LXC will create the files and
588 bind-mount over them. These will then be symbolically linked to
589 <filename>/dev/console</filename> and <filename>/dev/ttyN</filename>.
590 A package upgrade can then succeed as it is able to remove and replace
596 <option>lxc.devttydir</option>
600 Specify a directory under <filename>/dev</filename>
601 under which to create the container console devices.
609 <title>/dev directory</title>
611 By default, lxc does nothing with the container's
612 <filename>/dev</filename>. This allows the container's
613 <filename>/dev</filename> to be set up as needed in the container
614 rootfs. If lxc.autodev is set to 1, then after mounting the container's
615 rootfs LXC will mount a fresh tmpfs under <filename>/dev</filename>
616 (limited to 100k) and fill in a minimal set of initial devices.
617 This is generally required when starting a container containing
618 a "systemd" based "init" but may be optional at other times. Additional
619 devices in the containers /dev directory may be created through the
620 use of the <option>lxc.hook.autodev</option> hook.
625 <option>lxc.autodev</option>
629 Set this to 1 to have LXC mount and populate a minimal
630 <filename>/dev</filename> when starting the container.
638 <title>Enable kmsg symlink</title>
640 Enable creating /dev/kmsg as symlink to /dev/console. This defaults to 1.
645 <option>lxc.kmsg</option>
649 Set this to 0 to disable /dev/kmsg symlinking.
657 <title>Mount points</title>
659 The mount points section specifies the different places to be
660 mounted. These mount points will be private to the container
661 and won't be visible by the processes running outside of the
662 container. This is useful to mount /etc, /var or /home for
668 <option>lxc.mount</option>
672 specify a file location in
673 the <filename>fstab</filename> format, containing the
674 mount information. If the rootfs is an image file or a
675 block device and the fstab is used to mount a point
676 somewhere in this rootfs, the path of the rootfs mount
677 point should be prefixed with the
678 <filename>@LXCROOTFSMOUNT@</filename> default path or
679 the value of <option>lxc.rootfs.mount</option> if
680 specified. Note that when mounting a filesystem from an
681 image file or block device the third field (fs_vfstype)
682 cannot be auto as with
684 <refentrytitle>mount</refentrytitle>
685 <manvolnum>8</manvolnum>
687 but must be explicitly specified.
694 <option>lxc.mount.entry</option>
698 specify a mount point corresponding to a line in the
706 <option>lxc.mount.auto</option>
710 specify which standard kernel file systems should be
711 automatically mounted. This may dramatically simplify
712 the configuration. The file systems are:
717 <option>proc:mixed</option> (or <option>proc</option>):
718 mount <filename>/proc</filename> as read-write, but
719 remount <filename>/proc/sys</filename> and
720 <filename>/proc/sysrq-trigger</filename> read-only
721 for security / container isolation purposes.
726 <option>proc:rw</option>: mount
727 <filename>/proc</filename> as read-write
732 <option>sys:ro</option> (or <option>sys</option>):
733 mount <filename>/sys</filename> as read-only
734 for security / container isolation purposes.
739 <option>sys:rw</option>: mount
740 <filename>/sys</filename> as read-write
745 <option>cgroup:mixed</option> (or
746 <option>cgroup</option>):
747 mount a tmpfs to <filename>/sys/fs/cgroup</filename>,
748 create directories for all hierarchies to which
749 the container is added, create subdirectories
750 there with the name of the cgroup, and bind-mount
751 the container's own cgroup into that directory.
752 The container will be able to write to its own
753 cgroup directory, but not the parents, since they
754 will be remounted read-only
759 <option>cgroup:ro</option>: similar to
760 <option>cgroup:mixed</option>, but everything will
761 be mounted read-only.
766 <option>cgroup:rw</option>: similar to
767 <option>cgroup:mixed</option>, but everything will
768 be mounted read-write. Note that the paths leading
769 up to the container's own cgroup will be writable,
770 but will not be a cgroup filesystem but just part
771 of the tmpfs of <filename>/sys/fs/cgroup</filename>
776 <option>cgroup-full:mixed</option> (or
777 <option>cgroup-full</option>):
778 mount a tmpfs to <filename>/sys/fs/cgroup</filename>,
779 create directories for all hierarchies to which
780 the container is added, bind-mount the hierarchies
781 from the host to the container and make everything
782 read-only except the container's own cgroup. Note
783 that compared to <option>cgroup</option>, where
784 all paths leading up to the container's own cgroup
785 are just simple directories in the underlying
787 <filename>/sys/fs/cgroup/$hierarchy</filename>
788 will contain the host's full cgroup hierarchy,
789 albeit read-only outside the container's own cgroup.
790 This may leak quite a bit of information into the
796 <option>cgroup-full:ro</option>: similar to
797 <option>cgroup-full:mixed</option>, but everything
798 will be mounted read-only.
803 <option>cgroup-full:rw</option>: similar to
804 <option>cgroup-full:mixed</option>, but everything
805 will be mounted read-write. Note that in this case,
806 the container may escape its own cgroup. (Note also
807 that if the container has CAP_SYS_ADMIN support
808 and can mount the cgroup filesystem itself, it may
817 lxc.mount.auto = proc sys cgroup
818 lxc.mount.auto = proc:rw sys:rw cgroup-full:rw
827 <title>Root file system</title>
829 The root file system of the container can be different than that
835 <option>lxc.rootfs</option>
839 specify the root file system for the container. It can
840 be an image file, a directory or a block device. If not
841 specified, the container shares its root file system
849 <option>lxc.rootfs.mount</option>
853 where to recursively bind <option>lxc.rootfs</option>
854 before pivoting. This is to ensure success of the
856 <refentrytitle><command>pivot_root</command></refentrytitle>
857 <manvolnum>8</manvolnum>
859 syscall. Any directory suffices, the default should
867 <option>lxc.pivotdir</option>
871 where to pivot the original root file system under
872 <option>lxc.rootfs</option>, specified relatively to
873 that. The default is <filename>mnt</filename>.
874 It is created if necessary, and also removed after
875 unmounting everything from it during container setup.
883 <title>Control group</title>
885 The control group section contains the configuration for the
886 different subsystem. <command>lxc</command> does not check the
887 correctness of the subsystem name. This has the disadvantage
888 of not detecting configuration errors until the container is
889 started, but has the advantage of permitting any future
895 <option>lxc.cgroup.[subsystem name]</option>
899 specify the control group value to be set. The
900 subsystem name is the literal name of the control group
901 subsystem. The permitted names and the syntax of their
902 values is not dictated by LXC, instead it depends on the
903 features of the Linux kernel running at the time the
904 container is started,
905 eg. <option>lxc.cgroup.cpuset.cpus</option>
913 <title>Capabilities</title>
915 The capabilities can be dropped in the container if this one
921 <option>lxc.cap.drop</option>
925 Specify the capability to be dropped in the container. A
926 single line defining several capabilities with a space
927 separation is allowed. The format is the lower case of
928 the capability definition without the "CAP_" prefix,
929 eg. CAP_SYS_MODULE should be specified as
932 <refentrytitle><command>capabilities</command></refentrytitle>
933 <manvolnum>7</manvolnum>
940 <option>lxc.cap.keep</option>
944 Specify the capability to be kept in the container. All other
945 capabilities will be dropped.
953 <title>Apparmor profile</title>
955 If lxc was compiled and installed with apparmor support, and the host
956 system has apparmor enabled, then the apparmor profile under which the
957 container should be run can be specified in the container
958 configuration. The default is <command>lxc-container-default</command>.
963 <option>lxc.aa_profile</option>
967 Specify the apparmor profile under which the container should
968 be run. To specify that the container should be unconfined,
971 <programlisting>lxc.aa_profile = unconfined</programlisting>
978 <title>SELinux context</title>
980 If lxc was compiled and installed with SELinux support, and the host
981 system has SELinux enabled, then the SELinux context under which the
982 container should be run can be specified in the container
983 configuration. The default is <command>unconfined_t</command>,
984 which means that lxc will not attempt to change contexts.
989 <option>lxc.se_context</option>
993 Specify the SELinux context under which the container should
994 be run or <command>unconfined_t</command>. For example
996 <programlisting>lxc.se_context = unconfined_u:unconfined_r:lxc_t:s0-s0:c0.c1023</programlisting>
1003 <title>Seccomp configuration</title>
1005 A container can be started with a reduced set of available
1006 system calls by loading a seccomp profile at startup. The
1007 seccomp configuration file should begin with a version number
1008 (which currently must be 1) on the first line, a policy type
1009 (which must be 'whitelist') on the second line, followed by a
1010 list of allowed system call numbers, one per line.
1015 <option>lxc.seccomp</option>
1019 Specify a file containing the seccomp configuration to
1020 load before the container starts.
1028 <title>UID mappings</title>
1030 A container can be started in a private user namespace with
1031 user and group id mappings. For instance, you can map userid
1032 0 in the container to userid 200000 on the host. The root
1033 user in the container will be privileged in the container,
1034 but unprivileged on the host. Normally a system container
1035 will want a range of ids, so you would map, for instance,
1036 user and group ids 0 through 20,000 in the container to the
1037 ids 200,000 through 220,000.
1042 <option>lxc.id_map</option>
1046 Four values must be provided. First a character, either
1047 'u', or 'g', to specify whether user or group ids are
1048 being mapped. Next is the first userid as seen in the
1049 user namespace of the container. Next is the userid as
1050 seen on the host. Finally, a range indicating the number
1051 of consecutive ids to map.
1059 <title>Container hooks</title>
1061 Container hooks are programs or scripts which can be executed
1062 at various times in a container's lifetime.
1065 When a container hook is executed, information is passed both
1066 as command line arguments and through environment variables.
1069 <listitem><para> Container name. </para></listitem>
1070 <listitem><para> Section (always 'lxc'). </para></listitem>
1071 <listitem><para> The hook type (i.e. 'clone' or 'pre-mount'). </para></listitem>
1072 <listitem><para> Additional arguments In the
1073 case of the clone hook, any extra arguments passed to
1074 lxc-clone will appear as further arguments to the hook. </para></listitem>
1076 The following environment variables are set:
1078 <listitem><para> LXC_NAME: is the container's name. </para></listitem>
1079 <listitem><para> LXC_ROOTFS_MOUNT: the path to the mounted root filesystem. </para></listitem>
1080 <listitem><para> LXC_CONFIG_FILE: the path to the container configuration file. </para></listitem>
1081 <listitem><para> LXC_SRC_NAME: in the case of the clone hook, this is the original container's name. </para></listitem>
1082 <listitem><para> LXC_ROOTFS_PATH: this is the lxc.rootfs entry for the container. Note this is likely not where the mounted rootfs is to be found, use LXC_ROOTFS_MOUNT for that. </para></listitem>
1086 Standard output from the hooks is logged at debug level.
1087 Standard error is not logged, but can be captured by the
1088 hook redirecting its standard error to standard output.
1093 <option>lxc.hook.pre-start</option>
1097 A hook to be run in the host's namespace before the
1098 container ttys, consoles, or mounts are up.
1106 <option>lxc.hook.pre-mount</option>
1110 A hook to be run in the container's fs namespace but before
1111 the rootfs has been set up. This allows for manipulation
1112 of the rootfs, i.e. to mount an encrypted filesystem. Mounts
1113 done in this hook will not be reflected on the host (apart from
1114 mounts propagation), so they will be automatically cleaned up
1115 when the container shuts down.
1123 <option>lxc.hook.mount</option>
1127 A hook to be run in the container's namespace after
1128 mounting has been done, but before the pivot_root.
1136 <option>lxc.hook.autodev</option>
1140 A hook to be run in the container's namespace after
1141 mounting has been done and after any mount hooks have
1142 run, but before the pivot_root, if
1143 <option>lxc.autodev</option> == 1.
1144 The purpose of this hook is to assist in populating the
1145 /dev directory of the container when using the autodev
1146 option for systemd based containers. The container's /dev
1147 directory is relative to the
1148 ${<option>LXC_ROOTFS_MOUNT</option>} environment
1149 variable available when the hook is run.
1157 <option>lxc.hook.start</option>
1161 A hook to be run in the container's namespace immediately
1162 before executing the container's init. This requires the
1163 program to be available in the container.
1171 <option>lxc.hook.post-stop</option>
1175 A hook to be run in the host's namespace after the
1176 container has been shut down.
1184 <option>lxc.hook.clone</option>
1188 A hook to be run when the container is cloned to a new one.
1189 See <citerefentry><refentrytitle><command>lxc-clone</command></refentrytitle>
1190 <manvolnum>1</manvolnum></citerefentry> for more information.
1198 <title>Container hooks Environment Variables</title>
1200 A number of environment variables are made available to the startup
1201 hooks to provide configuration information and assist in the
1202 functioning of the hooks. Not all variables are valid in all
1203 contexts. In particular, all paths are relative to the host system
1204 and, as such, not valid during the <option>lxc.hook.start</option> hook.
1209 <option>LXC_NAME</option>
1213 The LXC name of the container. Useful for logging messages
1214 in common log environments. [<option>-n</option>]
1222 <option>LXC_CONFIG_FILE</option>
1226 Host relative path to the container configuration file. This
1227 gives the container to reference the original, top level,
1228 configuration file for the container in order to locate any
1229 additional configuration information not otherwise made
1230 available. [<option>-f</option>]
1238 <option>LXC_CONSOLE</option>
1242 The path to the console output of the container if not NULL.
1243 [<option>-c</option>] [<option>lxc.console</option>]
1251 <option>LXC_CONSOLE_LOGPATH</option>
1255 The path to the console log output of the container if not NULL.
1256 [<option>-L</option>]
1264 <option>LXC_ROOTFS_MOUNT</option>
1268 The mount location to which the container is initially bound.
1269 This will be the host relative path to the container rootfs
1270 for the container instance being started and is where changes
1271 should be made for that instance.
1272 [<option>lxc.rootfs.mount</option>]
1280 <option>LXC_ROOTFS_PATH</option>
1284 The host relative path to the container root which has been
1285 mounted to the rootfs.mount location.
1286 [<option>lxc.rootfs</option>]
1294 <title>Logging</title>
1296 Logging can be configured on a per-container basis. By default,
1297 depending upon how the lxc package was compiled, container startup
1298 is logged only at the ERROR level, and logged to a file named after
1299 the container (with '.log' appended) either under the container path,
1303 Both the default log level and the log file can be specified in the
1304 container configuration file, overriding the default behavior. Note
1305 that the configuration file entries can in turn be overridden by the
1306 command line options to <command>lxc-start</command>.
1311 <option>lxc.loglevel</option>
1315 The level at which to log. The log level is an integer in
1316 the range of 0..8 inclusive, where a lower number means more
1317 verbose debugging. In particular 0 = trace, 1 = debug, 2 =
1318 info, 3 = notice, 4 = warn, 5 = error, 6 = critical, 7 =
1319 alert, and 8 = fatal. If unspecified, the level defaults
1320 to 5 (error), so that only errors and above are logged.
1323 Note that when a script (such as either a hook script or a
1324 network interface up or down script) is called, the script's
1325 standard output is logged at level 1, debug.
1331 <option>lxc.logfile</option>
1335 The file to which logging info should be written.
1343 <title>Autostart</title>
1345 The autostart options support marking which containers should be
1346 auto-started and in what order. These options may be used by LXC tools
1347 directly or by external tooling provided by the distributions.
1353 <option>lxc.start.auto</option>
1357 Whether the container should be auto-started.
1358 Valid values are 0 (off) and 1 (on).
1364 <option>lxc.start.delay</option>
1368 How long to wait (in seconds) after the container is
1369 started before starting the next one.
1375 <option>lxc.start.order</option>
1379 An integer used to sort the containers when auto-starting
1380 a series of containers at once.
1386 <option>lxc.group</option>
1390 A multi-value key (can be used multiple times) to put the
1391 container in a container group. Those groups can then be
1392 used (amongst other things) to start a series of related
1402 <title>Examples</title>
1404 In addition to the few examples given below, you will find
1405 some other examples of configuration file in @DOCDIR@/examples
1408 <title>Network</title>
1409 <para>This configuration sets up a container to use a veth pair
1410 device with one side plugged to a bridge br0 (which has been
1411 configured before on the system by the administrator). The
1412 virtual network device visible in the container is renamed to
1415 lxc.utsname = myhostname
1416 lxc.network.type = veth
1417 lxc.network.flags = up
1418 lxc.network.link = br0
1419 lxc.network.name = eth0
1420 lxc.network.hwaddr = 4a:49:43:49:79:bf
1421 lxc.network.ipv4 = 10.2.3.5/24 10.2.3.255
1422 lxc.network.ipv6 = 2003:db8:1:0:214:1234:fe0b:3597
1427 <title>UID/GID mapping</title>
1428 <para>This configuration will map both user and group ids in the
1429 range 0-9999 in the container to the ids 100000-109999 on the host.
1432 lxc.id_map = u 0 100000 10000
1433 lxc.id_map = g 0 100000 10000
1438 <title>Control group</title>
1439 <para>This configuration will setup several control groups for
1440 the application, cpuset.cpus restricts usage of the defined cpu,
1441 cpus.share prioritize the control group, devices.allow makes
1442 usable the specified devices.</para>
1444 lxc.cgroup.cpuset.cpus = 0,1
1445 lxc.cgroup.cpu.shares = 1234
1446 lxc.cgroup.devices.deny = a
1447 lxc.cgroup.devices.allow = c 1:3 rw
1448 lxc.cgroup.devices.allow = b 8:0 rw
1453 <title>Complex configuration</title>
1454 <para>This example show a complex configuration making a complex
1455 network stack, using the control groups, setting a new hostname,
1456 mounting some locations and a changing root file system.</para>
1458 lxc.utsname = complex
1459 lxc.network.type = veth
1460 lxc.network.flags = up
1461 lxc.network.link = br0
1462 lxc.network.hwaddr = 4a:49:43:49:79:bf
1463 lxc.network.ipv4 = 10.2.3.5/24 10.2.3.255
1464 lxc.network.ipv6 = 2003:db8:1:0:214:1234:fe0b:3597
1465 lxc.network.ipv6 = 2003:db8:1:0:214:5432:feab:3588
1466 lxc.network.type = macvlan
1467 lxc.network.flags = up
1468 lxc.network.link = eth0
1469 lxc.network.hwaddr = 4a:49:43:49:79:bd
1470 lxc.network.ipv4 = 10.2.3.4/24
1471 lxc.network.ipv4 = 192.168.10.125/24
1472 lxc.network.ipv6 = 2003:db8:1:0:214:1234:fe0b:3596
1473 lxc.network.type = phys
1474 lxc.network.flags = up
1475 lxc.network.link = dummy0
1476 lxc.network.hwaddr = 4a:49:43:49:79:ff
1477 lxc.network.ipv4 = 10.2.3.6/24
1478 lxc.network.ipv6 = 2003:db8:1:0:214:1234:fe0b:3297
1479 lxc.cgroup.cpuset.cpus = 0,1
1480 lxc.cgroup.cpu.shares = 1234
1481 lxc.cgroup.devices.deny = a
1482 lxc.cgroup.devices.allow = c 1:3 rw
1483 lxc.cgroup.devices.allow = b 8:0 rw
1484 lxc.mount = /etc/fstab.complex
1485 lxc.mount.entry = /lib /root/myrootfs/lib none ro,bind 0 0
1486 lxc.rootfs = /mnt/rootfs.complex
1487 lxc.cap.drop = sys_module mknod setuid net_raw
1488 lxc.cap.drop = mac_override
1495 <title>See Also</title>
1498 <refentrytitle><command>chroot</command></refentrytitle>
1499 <manvolnum>1</manvolnum>
1503 <refentrytitle><command>pivot_root</command></refentrytitle>
1504 <manvolnum>8</manvolnum>
1508 <refentrytitle><filename>fstab</filename></refentrytitle>
1509 <manvolnum>5</manvolnum>
1513 <refentrytitle><filename>capabilities</filename></refentrytitle>
1514 <manvolnum>7</manvolnum>
1522 <title>Author</title>
1523 <para>Daniel Lezcano <email>daniel.lezcano@free.fr</email></para>
1528 <!-- Keep this comment at the end of the file
1533 sgml-minimize-attributes:nil
1534 sgml-always-quote-attributes:t
1537 sgml-parent-document:nil
1538 sgml-default-dtd-file:nil
1539 sgml-exposed-tags:nil
1540 sgml-local-catalogs:nil
1541 sgml-local-ecat-files:nil