1lxc.container.conf(5) lxc.container.conf(5)
2
6 lxc.container.conf - LXC container configuration file
7
9 LXC is the well-known and heavily tested low-level Linux container run‐
10 time. It is in active development since 2008 and has proven itself in
11 critical production environments world-wide. Some of its core contribu‐
12 tors are the same people that helped to implement various well-known
13 containerization features inside the Linux kernel.
14 LXC's main focus is system containers. That is, containers which offer
16 an environment as close as possible as the one you'd get from a VM but
17 without the overhead that comes with running a separate kernel and sim‐
18 ulating all the hardware.
19 This is achieved through a combination of kernel security features such
21 as namespaces, mandatory access control and control groups.
22 LXC has support for unprivileged containers. Unprivileged containers
24 are containers that are run without any privilege. This requires sup‐
25 port for user namespaces in the kernel that the container is run on.
26 LXC was the first runtime to support unprivileged containers after user
27 namespaces were merged into the mainline kernel.
28 In essence, user namespaces isolate given sets of UIDs and GIDs. This
30 is achieved by establishing a mapping between a range of UIDs and GIDs
31 on the host to a different (unprivileged) range of UIDs and GIDs in the
32 container. The kernel will translate this mapping in such a way that
33 inside the container all UIDs and GIDs appear as you would expect from
34 the host whereas on the host these UIDs and GIDs are in fact unprivi‐
35 leged. For example, a process running as UID and GID 0 inside the con‐
36 tainer might appear as UID and GID 100000 on the host. The implementa‐
37 tion and working details can be gathered from the corresponding user
38 namespace man page. UID and GID mappings can be defined with the
39 lxc.idmap key.
40 Linux containers are defined with a simple configuration file. Each
42 option in the configuration file has the form key = value fitting in
43 one line. The "#" character means the line is a comment. List options,
44 like capabilities and cgroups options, can be used with no value to
45 clear any previously defined values of that option.
46 LXC namespaces configuration keys use single dots. This means complex
48 configuration keys such as lxc.net.0 expose various subkeys such as
49 lxc.net.0.type, lxc.net.0.link, lxc.net.0.ipv6.address, and others for
50 even more fine-grained configuration.
51 CONFIGURATION
53 In order to ease administration of multiple related containers, it is
54 possible to have a container configuration file cause another file to
55 be loaded. For instance, network configuration can be defined in one
56 common file which is included by multiple containers. Then, if the con‐
57 tainers are moved to another host, only one file may need to be
58 updated.
59 lxc.include
61 Specify the file to be included. The included file must be in
62 the same valid lxc configuration file format.
63 ARCHITECTURE
65 Allows one to set the architecture for the container. For example, set
66 a 32bits architecture for a container running 32bits binaries on a
67 64bits host. This fixes the container scripts which rely on the archi‐
68 tecture to do some work like downloading the packages.
69 lxc.arch
71 Specify the architecture for the container.
72 Some valid options are x86, i686, x86_64, amd64
74 HOSTNAME
76 The utsname section defines the hostname to be set for the container.
77 That means the container can set its own hostname without changing the
78 one from the system. That makes the hostname private for the container.
79 lxc.uts.name
81 specify the hostname for the container
82 HALT SIGNAL
84 Allows one to specify signal name or number sent to the container's
85 init process to cleanly shutdown the container. Different init systems
86 could use different signals to perform clean shutdown sequence. This
87 option allows the signal to be specified in kill(1) fashion, e.g. SIG‐
88 PWR, SIGRTMIN+14, SIGRTMAX-10 or plain number. The default signal is
89 SIGPWR.
90 lxc.signal.halt
92 specify the signal used to halt the container
93 REBOOT SIGNAL
95 Allows one to specify signal name or number to reboot the container.
96 This option allows signal to be specified in kill(1) fashion, e.g.
97 SIGTERM, SIGRTMIN+14, SIGRTMAX-10 or plain number. The default signal
98 is SIGINT.
99 lxc.signal.reboot
101 specify the signal used to reboot the container
102 STOP SIGNAL
104 Allows one to specify signal name or number to forcibly shutdown the
105 container. This option allows signal to be specified in kill(1) fash‐
106 ion, e.g. SIGKILL, SIGRTMIN+14, SIGRTMAX-10 or plain number. The
107 default signal is SIGKILL.
108 lxc.signal.stop
110 specify the signal used to stop the container
111 INIT COMMAND
113 Sets the command to use as the init system for the containers.
114 lxc.execute.cmd
116 Absolute path from container rootfs to the binary to run by
117 default. This mostly makes sense for lxc-execute.
118 lxc.init.cmd
120 Absolute path from container rootfs to the binary to use as
121 init. This mostly makes sense for lxc-start. Default is
122 /sbin/init.
123 INIT WORKING DIRECTORY
125 Sets the absolute path inside the container as the working directory
126 for the containers. LXC will switch to this directory before executing
127 init.
128 lxc.init.cwd
130 Absolute path inside the container to use as the working direc‐
131 tory.
132 INIT ID
134 Sets the UID/GID to use for the init system, and subsequent commands.
135 Note that using a non-root UID when booting a system container will
136 likely not work due to missing privileges. Setting the UID/GID is
137 mostly useful when running application containers. Defaults to:
138 UID(0), GID(0)
139 lxc.init.uid
141 UID to use for init.
142 lxc.init.gid
144 GID to use for init.
145 PROC
147 Configure proc filesystem for the container.
148 lxc.proc.[proc file name]
150 Specify the proc file name to be set. The file names available
151 are those listed under /proc/PID/. Example:
152 lxc.proc.oom_score_adj = 10
154 EPHEMERAL
157 Allows one to specify whether a container will be destroyed on shut‐
158 down.
159 lxc.ephemeral
161 The only allowed values are 0 and 1. Set this to 1 to destroy a
162 container on shutdown.
163 NETWORK
165 The network section defines how the network is virtualized in the con‐
166 tainer. The network virtualization acts at layer two. In order to use
167 the network virtualization, parameters must be specified to define the
168 network interfaces of the container. Several virtual interfaces can be
169 assigned and used in a container even if the system has only one physi‐
170 cal network interface.
171 lxc.net
173 may be used without a value to clear all previous network
174 options.
175 lxc.net.[i].type
177 specify what kind of network virtualization to be used for the
178 container. Multiple networks can be specified by using an addi‐
179 tional index i after all lxc.net.* keys. For example,
180 lxc.net.0.type = veth and lxc.net.1.type = veth specify two dif‐
181 ferent networks of the same type. All keys sharing the same
182 index i will be treated as belonging to the same network. For
183 example, lxc.net.0.link = br0 will belong to lxc.net.0.type.
184 Currently, the different virtualization types can be:
185 none: will cause the container to share the host's network
187 namespace. This means the host network devices are usable in the
188 container. It also means that if both the container and host
189 have upstart as init, 'halt' in a container (for instance) will
190 shut down the host. Note that unprivileged containers do not
191 work with this setting due to an inability to mount sysfs. An
192 unsafe workaround would be to bind mount the host's sysfs.
193 empty: will create only the loopback interface.
195 veth: a virtual ethernet pair device is created with one side
197 assigned to the container and the other side attached to a
198 bridge specified by the lxc.net.[i].link option. If the bridge
199 is not specified, then the veth pair device will be created but
200 not attached to any bridge. Otherwise, the bridge has to be
201 created on the system before starting the container. lxc won't
202 handle any configuration outside of the container. By default,
203 lxc chooses a name for the network device belonging to the out‐
204 side of the container, but if you wish to handle this name your‐
205 selves, you can tell lxc to set a specific name with the
206 lxc.net.[i].veth.pair option (except for unprivileged containers
207 where this option is ignored for security reasons).
208 vlan: a vlan interface is linked with the interface specified by
210 the lxc.net.[i].link and assigned to the container. The vlan
211 identifier is specified with the option lxc.net.[i].vlan.id.
212 macvlan: a macvlan interface is linked with the interface speci‐
214 fied by the lxc.net.[i].link and assigned to the container.
215 lxc.net.[i].macvlan.mode specifies the mode the macvlan will use
216 to communicate between different macvlan on the same upper
217 device. The accepted modes are private, vepa, bridge and
218 passthru. In private mode, the device never communicates with
219 any other device on the same upper_dev (default). In vepa mode,
220 the new Virtual Ethernet Port Aggregator (VEPA) mode, it assumes
221 that the adjacent bridge returns all frames where both source
222 and destination are local to the macvlan port, i.e. the bridge
223 is set up as a reflective relay. Broadcast frames coming in from
224 the upper_dev get flooded to all macvlan interfaces in VEPA
225 mode, local frames are not delivered locally. In bridge mode, it
226 provides the behavior of a simple bridge between different
227 macvlan interfaces on the same port. Frames from one interface
228 to another one get delivered directly and are not sent out
229 externally. Broadcast frames get flooded to all other bridge
230 ports and to the external interface, but when they come back
231 from a reflective relay, we don't deliver them again. Since we
232 know all the MAC addresses, the macvlan bridge mode does not
233 require learning or STP like the bridge module does. In passthru
234 mode, all frames received by the physical interface are for‐
235 warded to the macvlan interface. Only one macvlan interface in
236 passthru mode is possible for one physical interface.
237 phys: an already existing interface specified by the
239 lxc.net.[i].link is assigned to the container.
240 lxc.net.[i].flags
242 Specify an action to do for the network.
243 up: activates the interface.
245 lxc.net.[i].link
247 Specify the interface to be used for real network traffic.
248 lxc.net.[i].mtu
250 Specify the maximum transfer unit for this interface.
251 lxc.net.[i].name
253 The interface name is dynamically allocated, but if another name
254 is needed because the configuration files being used by the con‐
255 tainer use a generic name, eg. eth0, this option will rename the
256 interface in the container.
257 lxc.net.[i].hwaddr
259 The interface mac address is dynamically allocated by default to
260 the virtual interface, but in some cases, this is needed to
261 resolve a mac address conflict or to always have the same link-
262 local ipv6 address. Any "x" in address will be replaced by ran‐
263 dom value, this allows setting hwaddr templates.
264 lxc.net.[i].ipv4.address
266 Specify the ipv4 address to assign to the virtualized interface.
267 Several lines specify several ipv4 addresses. The address is in
268 format x.y.z.t/m, eg. 192.168.1.123/24.
269 lxc.net.[i].ipv4.gateway
271 Specify the ipv4 address to use as the gateway inside the con‐
272 tainer. The address is in format x.y.z.t, eg. 192.168.1.123.
273 Can also have the special value auto, which means to take the
274 primary address from the bridge interface (as specified by the
275 lxc.net.[i].link option) and use that as the gateway. auto is
276 only available when using the veth and macvlan network types.
277 lxc.net.[i].ipv6.address
279 Specify the ipv6 address to assign to the virtualized interface.
280 Several lines specify several ipv6 addresses. The address is in
281 format x::y/m, eg. 2003:db8:1:0:214:1234:fe0b:3596/64
282 lxc.net.[i].ipv6.gateway
284 Specify the ipv6 address to use as the gateway inside the con‐
285 tainer. The address is in format x::y, eg. 2003:db8:1:0::1 Can
286 also have the special value auto, which means to take the pri‐
287 mary address from the bridge interface (as specified by the
288 lxc.net.[i].link option) and use that as the gateway. auto is
289 only available when using the veth and macvlan network types.
290 lxc.net.[i].script.up
292 Add a configuration option to specify a script to be executed
293 after creating and configuring the network used from the host
294 side.
295 In addition to the information available to all hooks. The fol‐
297 lowing information is provided to the script:
298 · LXC_HOOK_TYPE: the hook type. This is either 'up' or 'down'.
300 · LXC_HOOK_SECTION: the section type 'net'.
302 · LXC_NET_TYPE: the network type. This is one of the valid net‐
304 work types listed here (e.g. 'macvlan', 'veth').
305 · LXC_NET_PARENT: the parent device on the host. This is only
307 set for network types 'mavclan', 'veth', 'phys'.
308 · LXC_NET_PEER: the name of the peer device on the host. This is
310 only set for 'veth' network types. Note that this information
311 is only available when lxc.hook.version is set to 1.
312 Whether this information is provided in the form of environment vari‐
314 ables or as arguments to the script depends on the value of
315 lxc.hook.version. If set to 1 then information is provided in the form
316 of environment variables. If set to 0 information is provided as argu‐
317 ments to the script.
318 Standard output from the script is logged at debug level. Standard
320 error is not logged, but can be captured by the hook redirecting its
321 standard error to standard output.
322 lxc.net.[i].script.down
324 Add a configuration option to specify a script to be executed
325 before destroying the network used from the host side.
326 In addition to the information available to all hooks. The fol‐
328 lowing information is provided to the script:
329 · LXC_HOOK_TYPE: the hook type. This is either 'up' or 'down'.
331 · LXC_HOOK_SECTION: the section type 'net'.
333 · LXC_NET_TYPE: the network type. This is one of the valid net‐
335 work types listed here (e.g. 'macvlan', 'veth').
336 · LXC_NET_PARENT: the parent device on the host. This is only
338 set for network types 'mavclan', 'veth', 'phys'.
339 · LXC_NET_PEER: the name of the peer device on the host. This is
341 only set for 'veth' network types. Note that this information
342 is only available when lxc.hook.version is set to 1.
343 Whether this information is provided in the form of environment vari‐
345 ables or as arguments to the script depends on the value of
346 lxc.hook.version. If set to 1 then information is provided in the form
347 of environment variables. If set to 0 information is provided as argu‐
348 ments to the script.
349 Standard output from the script is logged at debug level. Standard
351 error is not logged, but can be captured by the hook redirecting its
352 standard error to standard output.
353 NEW PSEUDO TTY INSTANCE (DEVPTS)
355 For stricter isolation the container can have its own private instance
356 of the pseudo tty.
357 lxc.pty.max
359 If set, the container will have a new pseudo tty instance, mak‐
360 ing this private to it. The value specifies the maximum number
361 of pseudo ttys allowed for a pts instance (this limitation is
362 not implemented yet).
363 CONTAINER SYSTEM CONSOLE
365 If the container is configured with a root filesystem and the inittab
366 file is setup to use the console, you may want to specify where the
367 output of this console goes.
368 lxc.console.buffer.size
370 Setting this option instructs liblxc to allocate an in-memory
371 ringbuffer. The container's console output will be written to
372 the ringbuffer. Note that ringbuffer must be at least as big as
373 a standard page size. When passed a value smaller than a single
374 page size liblxc will allocate a ringbuffer of a single page
375 size. A page size is usually 4KB. The keyword 'auto' will cause
376 liblxc to allocate a ringbuffer of 128KB. When manually speci‐
377 fying a size for the ringbuffer the value should be a power of 2
378 when converted to bytes. Valid size prefixes are 'KB', 'MB',
379 'GB'. (Note that all conversions are based on multiples of 1024.
380 That means 'KB' == 'KiB', 'MB' == 'MiB', 'GB' == 'GiB'. Addi‐
381 tionally, the case of the suffix is ignored, i.e. 'kB', 'KB' and
382 'Kb' are treated equally.)
383 lxc.console.size
385 Setting this option instructs liblxc to place a limit on the
386 size of the console log file specified in lxc.console.logfile.
387 Note that size of the log file must be at least as big as a
388 standard page size. When passed a value smaller than a single
389 page size liblxc will set the size of log file to a single page
390 size. A page size is usually 4KB. The keyword 'auto' will cause
391 liblxc to place a limit of 128KB on the log file. When manually
392 specifying a size for the log file the value should be a power
393 of 2 when converted to bytes. Valid size prefixes are 'KB',
394 'MB', 'GB'. (Note that all conversions are based on multiples of
395 1024. That means 'KB' == 'KiB', 'MB' == 'MiB', 'GB' == 'GiB'.
396 Additionally, the case of the suffix is ignored, i.e. 'kB', 'KB'
397 and 'Kb' are treated equally.) If users want to mirror the con‐
398 sole ringbuffer on disk they should set lxc.console.size equal
399 to lxc.console.buffer.size.
400 lxc.console.logfile
402 Specify a path to a file where the console output will be writ‐
403 ten. Note that in contrast to the on-disk ringbuffer logfile
404 this file will keep growing potentially filling up the users
405 disks if not rotated and deleted. This problem can also be
406 avoided by using the in-memory ringbuffer options lxc.con‐
407 sole.buffer.size and lxc.console.buffer.logfile.
408 lxc.console.rotate
410 Whether to rotate the console logfile specified in lxc.con‐
411 sole.logfile. Users can send an API request to rotate the log‐
412 file. Note that the old logfile will have the same name as the
413 original with the suffix ".1" appended. Users wishing to pre‐
414 vent the console log file from filling the disk should rotate
415 the logfile and delete it if unneeded. This problem can also be
416 avoided by using the in-memory ringbuffer options lxc.con‐
417 sole.buffer.size and lxc.console.buffer.logfile.
418 lxc.console.path
420 Specify a path to a device to which the console will be
421 attached. The keyword 'none' will simply disable the console.
422 Note, when specifying 'none' and creating a device node for the
423 console in the container at /dev/console or bind-mounting the
424 hosts's /dev/console into the container at /dev/console the con‐
425 tainer will have direct access to the hosts's /dev/console.
426 This is dangerous when the container has write access to the
427 device and should thus be used with caution.
428 CONSOLE THROUGH THE TTYS
430 This option is useful if the container is configured with a root
431 filesystem and the inittab file is setup to launch a getty on the ttys.
432 The option specifies the number of ttys to be available for the con‐
433 tainer. The number of gettys in the inittab file of the container
434 should not be greater than the number of ttys specified in this option,
435 otherwise the excess getty sessions will die and respawn indefinitely
436 giving annoying messages on the console or in /var/log/messages.
437 lxc.tty.max
439 Specify the number of tty to make available to the container.
440 CONSOLE DEVICES LOCATION
442 LXC consoles are provided through Unix98 PTYs created on the host and
443 bind-mounted over the expected devices in the container. By default,
444 they are bind-mounted over /dev/console and /dev/ttyN. This can prevent
445 package upgrades in the guest. Therefore you can specify a directory
446 location (under /dev under which LXC will create the files and bind-
447 mount over them. These will then be symbolically linked to /dev/console
448 and /dev/ttyN. A package upgrade can then succeed as it is able to
449 remove and replace the symbolic links.
450 lxc.tty.dir
452 Specify a directory under /dev under which to create the con‐
453 tainer console devices. Note that LXC will move any bind-mounts
454 or device nodes for /dev/console into this directory.
455 /DEV DIRECTORY
457 By default, lxc creates a few symbolic links (fd,stdin,stdout,stderr)
458 in the container's /dev directory but does not automatically create
459 device node entries. This allows the container's /dev to be set up as
460 needed in the container rootfs. If lxc.autodev is set to 1, then after
461 mounting the container's rootfs LXC will mount a fresh tmpfs under /dev
462 (limited to 500k) and fill in a minimal set of initial devices. This
463 is generally required when starting a container containing a "systemd"
464 based "init" but may be optional at other times. Additional devices in
465 the containers /dev directory may be created through the use of the
466 lxc.hook.autodev hook.
467 lxc.autodev
469 Set this to 0 to stop LXC from mounting and populating a minimal
470 /dev when starting the container.
471 MOUNT POINTS
473 The mount points section specifies the different places to be mounted.
474 These mount points will be private to the container and won't be visi‐
475 ble by the processes running outside of the container. This is useful
476 to mount /etc, /var or /home for examples.
477 NOTE - LXC will generally ensure that mount targets and relative bind-
479 mount sources are properly confined under the container root, to avoid
480 attacks involving over-mounting host directories and files. (Symbolic
481 links in absolute mount sources are ignored) However, if the container
482 configuration first mounts a directory which is under the control of
483 the container user, such as /home/joe, into the container at some path,
484 and then mounts under path, then a TOCTTOU attack would be possible
485 where the container user modifies a symbolic link under his home direc‐
486 tory at just the right time.
487 lxc.mount.fstab
489 specify a file location in the fstab format, containing the
490 mount information. The mount target location can and in most
491 cases should be a relative path, which will become relative to
492 the mounted container root. For instance,
493 proc proc proc nodev,noexec,nosuid 0 0
495 Will mount a proc filesystem under the container's /proc,
498 regardless of where the root filesystem comes from. This is
499 resilient to block device backed filesystems as well as con‐
500 tainer cloning.
501 Note that when mounting a filesystem from an image file or block
503 device the third field (fs_vfstype) cannot be auto as with
504 mount(8) but must be explicitly specified.
505 lxc.mount.entry
507 Specify a mount point corresponding to a line in the fstab for‐
508 mat. Moreover lxc supports mount propagation, such as rslave or
509 rprivate, and adds three additional mount options. optional
510 don't fail if mount does not work. create=dir or create=file to
511 create dir (or file) when the point will be mounted. relative
512 source path is taken to be relative to the mounted container
513 root. For instance,
514 dev/null proc/kcore none bind,relative 0 0
516 .fi
517 Will expand dev/null to ${LXC_ROOTFS_MOUNT}/dev/null,
519 and mount it to proc/kcore inside the container.
520 lxc.mount.auto
522 specify which standard kernel file systems should be
523 automatically mounted. This may dramatically simplify
524 the configuration. The file systems are:
525 · proc:mixed (or proc):
527 mount /proc as read-write, but
528 remount /proc/sys and
529 /proc/sysrq-trigger read-only
530 for security / container isolation purposes.
531 · proc:rw: mount
533 /proc as read-write
534 · sys:mixed (or sys):
536 mount /sys as read-only but with
537 /sys/devices/virtual/net writable.
538 · sys:ro:
540 mount /sys as read-only
541 for security / container isolation purposes.
542 · sys:rw: mount
544 /sys as read-write
545 · cgroup:mixed:
547 Mount a tmpfs to /sys/fs/cgroup,
548 create directories for all hierarchies to which the container
549 is added, create subdirectories in those hierarchies with the
550 name of the cgroup, and bind-mount the container's own cgroup
551 into that directory. The container will be able to write to
552 its own cgroup directory, but not the parents, since they will
553 be remounted read-only.
554 · cgroup:mixed:force:
556 The force option will cause LXC to perform
557 the cgroup mounts for the container under all circumstances.
558 Otherwise it is similar to cgroup:mixed.
559 This is mainly useful when the cgroup namespaces are enabled
560 where LXC will normally leave mounting cgroups to the init
561 binary of the container since it is perfectly safe to do so.
562 · cgroup:ro:
564 similar to cgroup:mixed, but everything will
565 be mounted read-only.
566 · cgroup:ro:force:
568 The force option will cause LXC to perform
569 the cgroup mounts for the container under all circumstances.
570 Otherwise it is similar to cgroup:ro.
571 This is mainly useful when the cgroup namespaces are enabled
572 where LXC will normally leave mounting cgroups to the init
573 binary of the container since it is perfectly safe to do so.
574 · cgroup:rw: similar to
576 cgroup:mixed, but everything will be mounted
577 read-write. Note that the paths leading up to the container's
578 own cgroup will be writable, but will not be a cgroup
579 filesystem but just part of the tmpfs of
580 /sys/fs/cgroup
581 · cgroup:rw:force:
583 The force option will cause LXC to perform
584 the cgroup mounts for the container under all circumstances.
585 Otherwise it is similar to cgroup:rw.
586 This is mainly useful when the cgroup namespaces are enabled
587 where LXC will normally leave mounting cgroups to the init
588 binary of the container since it is perfectly safe to do so.
589 · cgroup (without specifier):
591 defaults to cgroup:rw if the
592 container retains the CAP_SYS_ADMIN capability,
593 cgroup:mixed otherwise.
594 · cgroup-full:mixed:
596 mount a tmpfs to /sys/fs/cgroup,
597 create directories for all hierarchies to which
598 the container is added, bind-mount the hierarchies
599 from the host to the container and make everything
600 read-only except the container's own cgroup. Note
601 that compared to cgroup, where
602 all paths leading up to the container's own cgroup
603 are just simple directories in the underlying
604 tmpfs, here
605 /sys/fs/cgroup/$hierarchy
606 will contain the host's full cgroup hierarchy,
607 albeit read-only outside the container's own cgroup.
608 This may leak quite a bit of information into the
609 container.
610 · cgroup-full:mixed:force:
612 The force option will cause LXC to perform
613 the cgroup mounts for the container under all circumstances.
614 Otherwise it is similar to cgroup-full:mixed.
615 This is mainly useful when the cgroup namespaces are enabled
616 where LXC will normally leave mounting cgroups to the init
617 binary of the container since it is perfectly safe to do so.
618 · cgroup-full:ro: similar to
620 cgroup-full:mixed, but everything
621 will be mounted read-only.
622 · cgroup-full:ro:force:
624 The force option will cause LXC to perform
625 the cgroup mounts for the container under all circumstances.
626 Otherwise it is similar to cgroup-full:ro.
627 This is mainly useful when the cgroup namespaces are enabled
628 where LXC will normally leave mounting cgroups to the init
629 binary of the container since it is perfectly safe to do so.
630 · cgroup-full:rw: similar to
632 cgroup-full:mixed, but everything
633 will be mounted read-write. Note that in this case,
634 the container may escape its own cgroup. (Note also
635 that if the container has CAP_SYS_ADMIN support
636 and can mount the cgroup filesystem itself, it may
637 do so anyway.)
638 · cgroup-full:rw:force:
640 The force option will cause LXC to perform
641 the cgroup mounts for the container under all circumstances.
642 Otherwise it is similar to cgroup-full:rw.
643 This is mainly useful when the cgroup namespaces are enabled
644 where LXC will normally leave mounting cgroups to the init
645 binary of the container since it is perfectly safe to do so.
646 · cgroup-full (without specifier):
648 defaults to cgroup-full:rw if the
649 container retains the CAP_SYS_ADMIN capability,
650 cgroup-full:mixed otherwise.
651 If cgroup namespaces are enabled, then any cgroup
653 auto-mounting request will be ignored, since the container can
654 mount the filesystems itself, and automounting can confuse the
655 container init.
656 Note that if automatic mounting of the cgroup filesystem
658 is enabled, the tmpfs under
659 /sys/fs/cgroup will always be
660 mounted read-write (but for the :mixed
661 and :ro cases, the individual
662 hierarchies,
663 /sys/fs/cgroup/$hierarchy, will be
664 read-only). This is in order to work around a quirk in
665 Ubuntu's
666 mountall(8)
667 command that will cause containers to wait for user
668 input at boot if
669 /sys/fs/cgroup is mounted read-only
670 and the container can't remount it read-write due to a
671 lack of CAP_SYS_ADMIN.
672 Examples:
674 lxc.mount.auto = proc sys cgroup
676 lxc.mount.auto = proc:rw sys:rw cgroup-full:rw
677 ROOT FILE SYSTEM
680 The root file system of the container can be different than that of the
681 host system.
682 lxc.rootfs.path
684 specify the root file system for the container. It can be an
685 image file, a directory or a block device. If not specified, the
686 container shares its root file system with the host.
687 For directory or simple block-device backed containers, a path‐
689 name can be used. If the rootfs is backed by a nbd device, then
690 nbd:file:1 specifies that file should be attached to a nbd
691 device, and partition 1 should be mounted as the rootfs.
692 nbd:file specifies that the nbd device itself should be mounted.
693 overlayfs:/lower:/upper specifies that the rootfs should be an
694 overlay with /upper being mounted read-write over a read-only
695 mount of /lower. For overlay multiple /lower directories can be
696 specified. loop:/file tells lxc to attach /file to a loop device
697 and mount the loop device.
698 lxc.rootfs.mount
700 where to recursively bind lxc.rootfs.path before pivoting. This
701 is to ensure success of the pivot_root(8) syscall. Any directory
702 suffices, the default should generally work.
703 lxc.rootfs.options
705 extra mount options to use when mounting the rootfs.
706 CONTROL GROUP
708 The control group section contains the configuration for the different
709 subsystem. lxc does not check the correctness of the subsystem name.
710 This has the disadvantage of not detecting configuration errors until
711 the container is started, but has the advantage of permitting any
712 future subsystem.
713 lxc.cgroup.[controller name]
715 Specify the control group value to be set on a legacy cgroup
716 hierarchy. The controller name is the literal name of the con‐
717 trol group. The permitted names and the syntax of their values
718 is not dictated by LXC, instead it depends on the features of
719 the Linux kernel running at the time the container is started,
720 eg. lxc.cgroup.cpuset.cpus
721 lxc.cgroup2.[controller name]
723 Specify the control group value to be set on the unified cgroup
724 hierarchy. The controller name is the literal name of the con‐
725 trol group. The permitted names and the syntax of their values
726 is not dictated by LXC, instead it depends on the features of
727 the Linux kernel running at the time the container is started,
728 eg. lxc.cgroup2.memory.high
729 lxc.cgroup.dir
731 specify a directory or path in which the container's cgroup will
732 be created. For example, setting lxc.cgroup.dir =
733 my-cgroup/first for a container named "c1" will create the con‐
734 tainer's cgroup as a sub-cgroup of "my-cgroup". For example, if
735 the user's current cgroup "my-user" is located in the root
736 cgroup of the cpuset controller in a cgroup v1 hierarchy this
737 would create the cgroup "/sys/fs/cgroup/cpuset/my-user/my-
738 cgroup/first/c1" for the container. Any missing cgroups will be
739 created by LXC. This presupposes that the user has write access
740 to its current cgroup.
741 CAPABILITIES
743 The capabilities can be dropped in the container if this one is run as
744 root.
745 lxc.cap.drop
747 Specify the capability to be dropped in the container. A single
748 line defining several capabilities with a space separation is
749 allowed. The format is the lower case of the capability defini‐
750 tion without the "CAP_" prefix, eg. CAP_SYS_MODULE should be
751 specified as sys_module. See capabilities(7). If used with no
752 value, lxc will clear any drop capabilities specified up to this
753 point.
754 lxc.cap.keep
756 Specify the capability to be kept in the container. All other
757 capabilities will be dropped. When a special value of "none" is
758 encountered, lxc will clear any keep capabilities specified up
759 to this point. A value of "none" alone can be used to drop all
760 capabilities.
761 NAMESPACES
763 A namespace can be cloned (lxc.namespace.clone), kept (lxc.names‐
764 pace.keep) or shared (lxc.namespace.share.[namespace identifier]).
765 lxc.namespace.clone
767 Specify namespaces which the container is supposed to be created
768 with. The namespaces to create are specified as a space sepa‐
769 rated list. Each namespace must correspond to one of the stan‐
770 dard namespace identifiers as seen in the /proc/PID/ns direc‐
771 tory. When lxc.namespace.clone is not explicitly set all names‐
772 paces supported by the kernel and the current configuration will
773 be used.
774 To create a new mount, net and ipc namespace set lxc.names‐
776 pace.clone=mount net ipc.
777 lxc.namespace.keep
779 Specify namespaces which the container is supposed to inherit
780 from the process that created it. The namespaces to keep are
781 specified as a space separated list. Each namespace must corre‐
782 spond to one of the standard namespace identifiers as seen in
783 the /proc/PID/ns directory. The lxc.namespace.keep is a black‐
784 list option, i.e. it is useful when enforcing that containers
785 must keep a specific set of namespaces.
786 To keep the network, user and ipc namespace set lxc.names‐
788 pace.keep=user net ipc.
789 Note that sharing pid namespaces will likely not work with most
791 init systems.
792 Note that if the container requests a new user namespace and the
794 container wants to inherit the network namespace it needs to
795 inherit the user namespace as well.
796 lxc.namespace.share.[namespace identifier]
798 Specify a namespace to inherit from another container or
799 process. The [namespace identifier] suffix needs to be replaced
800 with one of the namespaces that appear in the /proc/PID/ns
801 directory.
802 To inherit the namespace from another process set the lxc.names‐
804 pace.share.[namespace identifier] to the PID of the process,
805 e.g. lxc.namespace.share.net=42.
806 To inherit the namespace from another container set the
808 lxc.namespace.share.[namespace identifier] to the name of the
809 container, e.g. lxc.namespace.share.pid=c3.
810 To inherit the namespace from another container located in a
812 different path than the standard liblxc path set the lxc.names‐
813 pace.share.[namespace identifier] to the full path to the con‐
814 tainer, e.g. lxc.namespace.share.user=/opt/c3.
815 In order to inherit namespaces the caller needs to have suffi‐
817 cient privilege over the process or container.
818 Note that sharing pid namespaces between system containers will
820 likely not work with most init systems.
821 Note that if two processes are in different user namespaces and
823 one process wants to inherit the other's network namespace it
824 usually needs to inherit the user namespace as well.
825 RESOURCE LIMITS
827 The soft and hard resource limits for the container can be changed.
828 Unprivileged containers can only lower them. Resources which are not
829 explicitly specified will be inherited.
830 lxc.prlimit.[limit name]
832 Specify the resource limit to be set. A limit is specified as
833 two colon separated values which are either numeric or the word
834 'unlimited'. A single value can be used as a shortcut to set
835 both soft and hard limit to the same value. The permitted names
836 the "RLIMIT_" resource names in lowercase without the "RLIMIT_"
837 prefix, eg. RLIMIT_NOFILE should be specified as "nofile". See
838 setrlimit(2). If used with no value, lxc will clear the
839 resource limit specified up to this point. A resource with no
840 explicitly configured limitation will be inherited from the
841 process starting up the container.
842 SYSCTL
844 Configure kernel parameters for the container.
845 lxc.sysctl.[kernel parameters name]
847 Specify the kernel parameters to be set. The parameters avail‐
848 able are those listed under /proc/sys/. Note that not all
849 sysctls are namespaced. Changing Non-namespaced sysctls will
850 cause the system-wide setting to be modified. sysctl(8). If
851 used with no value, lxc will clear the parameters specified up
852 to this point.
853 APPARMOR PROFILE
855 If lxc was compiled and installed with apparmor support, and the host
856 system has apparmor enabled, then the apparmor profile under which the
857 container should be run can be specified in the container configura‐
858 tion. The default is lxc-container-default-cgns if the host kernel is
859 cgroup namespace aware, or lxc-container-default otherwise.
860 lxc.apparmor.profile
862 Specify the apparmor profile under which the container should be
863 run. To specify that the container should be unconfined, use
864 lxc.apparmor.profile = unconfined
866 If the apparmor profile should remain unchanged (i.e. if you are
868 nesting containers and are already confined), then use
869 lxc.apparmor.profile = unchanged
871 lxc.apparmor.allow_incomplete
873 Apparmor profiles are pathname based. Therefore many file
874 restrictions require mount restrictions to be effective against
875 a determined attacker. However, these mount restrictions are not
876 yet implemented in the upstream kernel. Without the mount
877 restrictions, the apparmor profiles still protect against acci‐
878 dental damager.
879 If this flag is 0 (default), then the container will not be
881 started if the kernel lacks the apparmor mount features, so that
882 a regression after a kernel upgrade will be detected. To start
883 the container under partial apparmor protection, set this flag
884 to 1.
885 SELINUX CONTEXT
887 If lxc was compiled and installed with SELinux support, and the host
888 system has SELinux enabled, then the SELinux context under which the
889 container should be run can be specified in the container configura‐
890 tion. The default is unconfined_t, which means that lxc will not
891 attempt to change contexts. See /usr/share/lxc/selinux/lxc.te for an
892 example policy and more information.
893 lxc.selinux.context
895 Specify the SELinux context under which the container should be
896 run or unconfined_t. For example
897 lxc.selinux.context = system_u:system_r:lxc_t:s0:c22
899 SECCOMP CONFIGURATION
901 A container can be started with a reduced set of available system calls
902 by loading a seccomp profile at startup. The seccomp configuration file
903 must begin with a version number on the first line, a policy type on
904 the second line, followed by the configuration.
905 Versions 1 and 2 are currently supported. In version 1, the policy is a
907 simple whitelist. The second line therefore must read "whitelist", with
908 the rest of the file containing one (numeric) syscall number per line.
909 Each syscall number is whitelisted, while every unlisted number is
910 blacklisted for use in the container
911 In version 2, the policy may be blacklist or whitelist, supports per-
913 rule and per-policy default actions, and supports per-architecture sys‐
914 tem call resolution from textual names.
915 An example blacklist policy, in which all system calls are allowed
917 except for mknod, which will simply do nothing and return 0 (success),
918 looks like:
919 2
921 blacklist
922 mknod errno 0
923 lxc.seccomp.profile
926 Specify a file containing the seccomp configuration to load
927 before the container starts.
928 PR_SET_NO_NEW_PRIVS
930 With PR_SET_NO_NEW_PRIVS active execve() promises not to grant privi‐
931 leges to do anything that could not have been done without the execve()
932 call (for example, rendering the set-user-ID and set-group-ID mode
933 bits, and file capabilities non-functional). Once set, this bit cannot
934 be unset. The setting of this bit is inherited by children created by
935 fork() and clone(), and preserved across execve(). Note that
936 PR_SET_NO_NEW_PRIVS is applied after the container has changed into its
937 intended AppArmor profile or SElinux context.
938 lxc.no_new_privs
940 Specify whether the PR_SET_NO_NEW_PRIVS flag should be set for
941 the container. Set to 1 to activate.
942 UID MAPPINGS
944 A container can be started in a private user namespace with user and
945 group id mappings. For instance, you can map userid 0 in the container
946 to userid 200000 on the host. The root user in the container will be
947 privileged in the container, but unprivileged on the host. Normally a
948 system container will want a range of ids, so you would map, for
949 instance, user and group ids 0 through 20,000 in the container to the
950 ids 200,000 through 220,000.
951 lxc.idmap
953 Four values must be provided. First a character, either 'u', or
954 'g', to specify whether user or group ids are being mapped. Next
955 is the first userid as seen in the user namespace of the con‐
956 tainer. Next is the userid as seen on the host. Finally, a range
957 indicating the number of consecutive ids to map.
958 CONTAINER HOOKS
960 Container hooks are programs or scripts which can be executed at vari‐
961 ous times in a container's lifetime.
962 When a container hook is executed, additional information is passed
964 along. The lxc.hook.version argument can be used to determine if the
965 following arguments are passed as command line arguments or through
966 environment variables. The arguments are:
967 · Container name.
969 · Section (always 'lxc').
971 · The hook type (i.e. 'clone' or 'pre-mount').
973 · Additional arguments. In the case of the clone hook, any extra argu‐
975 ments passed will appear as further arguments to the hook. In the
976 case of the stop hook, paths to filedescriptors for each of the con‐
977 tainer's namespaces along with their types are passed.
978 The following environment variables are set:
980 · LXC_CGNS_AWARE: indicator whether the container is cgroup namespace
982 aware.
983 · LXC_CONFIG_FILE: the path to the container configuration file.
985 · LXC_HOOK_TYPE: the hook type (e.g. 'clone', 'mount', 'pre-mount').
987 Note that the existence of this environment variable is conditional
988 on the value of lxc.hook.version. If it is set to 1 then
989 LXC_HOOK_TYPE will be set.
990 · LXC_HOOK_SECTION: the section type (e.g. 'lxc', 'net'). Note that the
992 existence of this environment variable is conditional on the value of
993 lxc.hook.version. If it is set to 1 then LXC_HOOK_SECTION will be
994 set.
995 · LXC_HOOK_VERSION: the version of the hooks. This value is identical
997 to the value of the container's lxc.hook.version config item. If it
998 is set to 0 then old-style hooks are used. If it is set to 1 then
999 new-style hooks are used.
1000 · LXC_LOG_LEVEL: the container's log level.
1002 · LXC_NAME: is the container's name.
1004 · LXC_[NAMESPACE IDENTIFIER]_NS: path under /proc/PID/fd/ to a file
1006 descriptor referring to the container's namespace. For each preserved
1007 namespace type there will be a separate environment variable. These
1008 environment variables will only be set if lxc.hook.version is set to
1009 1.
1010 · LXC_ROOTFS_MOUNT: the path to the mounted root filesystem.
1012 · LXC_ROOTFS_PATH: this is the lxc.rootfs.path entry for the container.
1014 Note this is likely not where the mounted rootfs is to be found, use
1015 LXC_ROOTFS_MOUNT for that.
1016 · LXC_SRC_NAME: in the case of the clone hook, this is the original
1018 container's name.
1019 Standard output from the hooks is logged at debug level. Standard
1021 error is not logged, but can be captured by the hook redirecting its
1022 standard error to standard output.
1023 lxc.hook.version
1025 To pass the arguments in new style via environment variables set
1026 to 1 otherwise set to 0 to pass them as arguments. This setting
1027 affects all hooks arguments that were traditionally passed as
1028 arguments to the script. Specifically, it affects the container
1029 name, section (e.g. 'lxc', 'net') and hook type (e.g. 'clone',
1030 'mount', 'pre-mount') arguments. If new-style hooks are used
1031 then the arguments will be available as environment variables.
1032 The container name will be set in LXC_NAME. (This is set inde‐
1033 pendently of the value used for this config item.) The section
1034 will be set in LXC_HOOK_SECTION and the hook type will be set in
1035 LXC_HOOK_TYPE. It also affects how the paths to file descrip‐
1036 tors referring to the container's namespaces are passed. If set
1037 to 1 then for each namespace a separate environment variable
1038 LXC_[NAMESPACE IDENTIFIER]_NS will be set. If set to 0 then the
1039 paths will be passed as arguments to the stop hook.
1040 lxc.hook.pre-start
1042 A hook to be run in the host's namespace before the container
1043 ttys, consoles, or mounts are up.
1044 lxc.hook.pre-mount
1046 A hook to be run in the container's fs namespace but before the
1047 rootfs has been set up. This allows for manipulation of the
1048 rootfs, i.e. to mount an encrypted filesystem. Mounts done in
1049 this hook will not be reflected on the host (apart from mounts
1050 propagation), so they will be automatically cleaned up when the
1051 container shuts down.
1052 lxc.hook.mount
1054 A hook to be run in the container's namespace after mounting has
1055 been done, but before the pivot_root.
1056 lxc.hook.autodev
1058 A hook to be run in the container's namespace after mounting has
1059 been done and after any mount hooks have run, but before the
1060 pivot_root, if lxc.autodev == 1. The purpose of this hook is to
1061 assist in populating the /dev directory of the container when
1062 using the autodev option for systemd based containers. The con‐
1063 tainer's /dev directory is relative to the ${LXC_ROOTFS_MOUNT}
1064 environment variable available when the hook is run.
1065 lxc.hook.start-host
1067 A hook to be run in the host's namespace after the container has
1068 been setup, and immediately before starting the container init.
1069 lxc.hook.start
1071 A hook to be run in the container's namespace immediately before
1072 executing the container's init. This requires the program to be
1073 available in the container.
1074 lxc.hook.stop
1076 A hook to be run in the host's namespace with references to the
1077 container's namespaces after the container has been shut down.
1078 For each namespace an extra argument is passed to the hook con‐
1079 taining the namespace's type and a filename that can be used to
1080 obtain a file descriptor to the corresponding namespace, sepa‐
1081 rated by a colon. The type is the name as it would appear in the
1082 /proc/PID/ns directory. For instance for the mount namespace
1083 the argument usually looks like mnt:/proc/PID/fd/12.
1084 lxc.hook.post-stop
1086 A hook to be run in the host's namespace after the container has
1087 been shut down.
1088 lxc.hook.clone
1090 A hook to be run when the container is cloned to a new one. See
1091 lxc-clone(1) for more information.
1092 lxc.hook.destroy
1094 A hook to be run when the container is destroyed.
1095 CONTAINER HOOKS ENVIRONMENT VARIABLES
1097 A number of environment variables are made available to the startup
1098 hooks to provide configuration information and assist in the function‐
1099 ing of the hooks. Not all variables are valid in all contexts. In par‐
1100 ticular, all paths are relative to the host system and, as such, not
1101 valid during the lxc.hook.start hook.
1102 LXC_NAME
1104 The LXC name of the container. Useful for logging messages in
1105 common log environments. [-n]
1106 LXC_CONFIG_FILE
1108 Host relative path to the container configuration file. This
1109 gives the container to reference the original, top level, con‐
1110 figuration file for the container in order to locate any addi‐
1111 tional configuration information not otherwise made available.
1112 [-f]
1113 LXC_CONSOLE
1115 The path to the console output of the container if not NULL.
1116 [-c] [lxc.console.path]
1117 LXC_CONSOLE_LOGPATH
1119 The path to the console log output of the container if not NULL.
1120 [-L]
1121 LXC_ROOTFS_MOUNT
1123 The mount location to which the container is initially bound.
1124 This will be the host relative path to the container rootfs for
1125 the container instance being started and is where changes should
1126 be made for that instance. [lxc.rootfs.mount]
1127 LXC_ROOTFS_PATH
1129 The host relative path to the container root which has been
1130 mounted to the rootfs.mount location. [lxc.rootfs.path]
1131 LXC_SRC_NAME
1133 Only for the clone hook. Is set to the original container name.
1134 LXC_TARGET
1136 Only for the stop hook. Is set to "stop" for a container shut‐
1137 down or "reboot" for a container reboot.
1138 LXC_CGNS_AWARE
1140 If unset, then this version of lxc is not aware of cgroup names‐
1141 paces. If set, it will be set to 1, and lxc is aware of cgroup
1142 namespaces. Note this does not guarantee that cgroup namespaces
1143 are enabled in the kernel. This is used by the lxcfs mount hook.
1144 LOGGING
1146 Logging can be configured on a per-container basis. By default, depend‐
1147 ing upon how the lxc package was compiled, container startup is logged
1148 only at the ERROR level, and logged to a file named after the container
1149 (with '.log' appended) either under the container path, or under
1150 /var/log/lxc.
1151 Both the default log level and the log file can be specified in the
1153 container configuration file, overriding the default behavior. Note
1154 that the configuration file entries can in turn be overridden by the
1155 command line options to lxc-start.
1156 lxc.log.level
1158 The level at which to log. The log level is an integer in the
1159 range of 0..8 inclusive, where a lower number means more verbose
1160 debugging. In particular 0 = trace, 1 = debug, 2 = info, 3 =
1161 notice, 4 = warn, 5 = error, 6 = critical, 7 = alert, and 8 =
1162 fatal. If unspecified, the level defaults to 5 (error), so that
1163 only errors and above are logged.
1164 Note that when a script (such as either a hook script or a net‐
1166 work interface up or down script) is called, the script's stan‐
1167 dard output is logged at level 1, debug.
1168 lxc.log.file
1170 The file to which logging info should be written.
1171 lxc.log.syslog
1173 Send logging info to syslog. It respects the log level defined
1174 in lxc.log.level. The argument should be the syslog facility to
1175 use, valid ones are: daemon, local0, local1, local2, local3,
1176 local4, local5, local5, local6, local7.
1177 AUTOSTART
1179 The autostart options support marking which containers should be auto-
1180 started and in what order. These options may be used by LXC tools
1181 directly or by external tooling provided by the distributions.
1182 lxc.start.auto
1184 Whether the container should be auto-started. Valid values are
1185 0 (off) and 1 (on).
1186 lxc.start.delay
1188 How long to wait (in seconds) after the container is started
1189 before starting the next one.
1190 lxc.start.order
1192 An integer used to sort the containers when auto-starting a
1193 series of containers at once.
1194 lxc.monitor.unshare
1196 If not zero the mount namespace will be unshared from the host
1197 before initializing the container (before running any pre-start
1198 hooks). This requires the CAP_SYS_ADMIN capability at startup.
1199 Default is 0.
1200 lxc.group
1202 A multi-value key (can be used multiple times) to put the con‐
1203 tainer in a container group. Those groups can then be used
1204 (amongst other things) to start a series of related containers.
1205 AUTOSTART AND SYSTEM BOOT
1207 Each container can be part of any number of groups or no group at all.
1208 Two groups are special. One is the NULL group, i.e. the container does
1209 not belong to any group. The other group is the "onboot" group.
1210 When the system boots with the LXC service enabled, it will first
1212 attempt to boot any containers with lxc.start.auto == 1 that is a mem‐
1213 ber of the "onboot" group. The startup will be in order of
1214 lxc.start.order. If an lxc.start.delay has been specified, that delay
1215 will be honored before attempting to start the next container to give
1216 the current container time to begin initialization and reduce overload‐
1217 ing the host system. After starting the members of the "onboot" group,
1218 the LXC system will proceed to boot containers with lxc.start.auto == 1
1219 which are not members of any group (the NULL group) and proceed as with
1220 the onboot group.
1221 CONTAINER ENVIRONMENT
1223 If you want to pass environment variables into the container (that is,
1224 environment variables which will be available to init and all of its
1225 descendents), you can use lxc.environment parameters to do so. Be care‐
1226 ful that you do not pass in anything sensitive; any process in the con‐
1227 tainer which doesn't have its environment scrubbed will have these
1228 variables available to it, and environment variables are always avail‐
1229 able via /proc/PID/environ.
1230 This configuration parameter can be specified multiple times; once for
1232 each environment variable you wish to configure.
1233 lxc.environment
1235 Specify an environment variable to pass into the container.
1236 Example:
1237 lxc.environment = APP_ENV=production
1239 lxc.environment = SYSLOG_SERVER=192.0.2.42
1240
1243 In addition to the few examples given below, you will find some other
1244 examples of configuration file in /usr/share/doc/lxc/examples
1245 NETWORK
1247 This configuration sets up a container to use a veth pair device with
1248 one side plugged to a bridge br0 (which has been configured before on
1249 the system by the administrator). The virtual network device visible in
1250 the container is renamed to eth0.
1251 lxc.uts.name = myhostname
1253 lxc.net.0.type = veth
1254 lxc.net.0.flags = up
1255 lxc.net.0.link = br0
1256 lxc.net.0.name = eth0
1257 lxc.net.0.hwaddr = 4a:49:43:49:79:bf
1258 lxc.net.0.ipv4.address = 10.2.3.5/24 10.2.3.255
1259 lxc.net.0.ipv6.address = 2003:db8:1:0:214:1234:fe0b:3597
1260 UID/GID MAPPING
1263 This configuration will map both user and group ids in the range 0-9999
1264 in the container to the ids 100000-109999 on the host.
1265 lxc.idmap = u 0 100000 10000
1267 lxc.idmap = g 0 100000 10000
1268 CONTROL GROUP
1271 This configuration will setup several control groups for the applica‐
1272 tion, cpuset.cpus restricts usage of the defined cpu, cpus.share prior‐
1273 itize the control group, devices.allow makes usable the specified
1274 devices.
1275 lxc.cgroup.cpuset.cpus = 0,1
1277 lxc.cgroup.cpu.shares = 1234
1278 lxc.cgroup.devices.deny = a
1279 lxc.cgroup.devices.allow = c 1:3 rw
1280 lxc.cgroup.devices.allow = b 8:0 rw
1281 COMPLEX CONFIGURATION
1284 This example show a complex configuration making a complex network
1285 stack, using the control groups, setting a new hostname, mounting some
1286 locations and a changing root file system.
1287 lxc.uts.name = complex
1289 lxc.net.0.type = veth
1290 lxc.net.0.flags = up
1291 lxc.net.0.link = br0
1292 lxc.net.0.hwaddr = 4a:49:43:49:79:bf
1293 lxc.net.0.ipv4.address = 10.2.3.5/24 10.2.3.255
1294 lxc.net.0.ipv6.address = 2003:db8:1:0:214:1234:fe0b:3597
1295 lxc.net.0.ipv6.address = 2003:db8:1:0:214:5432:feab:3588
1296 lxc.net.1.type = macvlan
1297 lxc.net.1.flags = up
1298 lxc.net.1.link = eth0
1299 lxc.net.1.hwaddr = 4a:49:43:49:79:bd
1300 lxc.net.1.ipv4.address = 10.2.3.4/24
1301 lxc.net.1.ipv4.address = 192.168.10.125/24
1302 lxc.net.1.ipv6.address = 2003:db8:1:0:214:1234:fe0b:3596
1303 lxc.net.2.type = phys
1304 lxc.net.2.flags = up
1305 lxc.net.2.link = dummy0
1306 lxc.net.2.hwaddr = 4a:49:43:49:79:ff
1307 lxc.net.2.ipv4.address = 10.2.3.6/24
1308 lxc.net.2.ipv6.address = 2003:db8:1:0:214:1234:fe0b:3297
1309 lxc.cgroup.cpuset.cpus = 0,1
1310 lxc.cgroup.cpu.shares = 1234
1311 lxc.cgroup.devices.deny = a
1312 lxc.cgroup.devices.allow = c 1:3 rw
1313 lxc.cgroup.devices.allow = b 8:0 rw
1314 lxc.mount.fstab = /etc/fstab.complex
1315 lxc.mount.entry = /lib /root/myrootfs/lib none ro,bind 0 0
1316 lxc.rootfs.path = dir:/mnt/rootfs.complex
1317 lxc.cap.drop = sys_module mknod setuid net_raw
1318 lxc.cap.drop = mac_override
1319
1322 chroot(1), pivot_root(8), fstab(5), capabilities(7)
1323
1325 lxc(7), lxc-create(1), lxc-copy(1), lxc-destroy(1), lxc-start(1), lxc-
1326 stop(1), lxc-execute(1), lxc-console(1), lxc-monitor(1), lxc-wait(1),
1327 lxc-cgroup(1), lxc-ls(1), lxc-info(1), lxc-freeze(1), lxc-unfreeze(1),
1328 lxc-attach(1), lxc.conf(5)
1329
1331 Daniel Lezcano <daniel.lezcano@free.fr>
1332 2019-02-01 lxc.container.conf(5)