1lxc.container.conf(5)                                    lxc.container.conf(5)
2
3
4

NAME

6       lxc.container.conf - LXC container configuration file
7

DESCRIPTION

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
15       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
20       This is achieved through a combination of kernel security features such
21       as namespaces, mandatory access control and control groups.
22
23       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
29       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
41       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
47       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
52   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
60       lxc.include
61              Specify  the  file  to be included. The included file must be in
62              the same valid lxc configuration file format.
63
64   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
70       lxc.arch
71              Specify the architecture for the container.
72
73              Some valid options are x86, i686, x86_64, amd64
74
75   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
80       lxc.uts.name
81              specify the hostname for the container
82
83   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
91       lxc.signal.halt
92              specify the signal used to halt the container
93
94   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
100       lxc.signal.reboot
101              specify the signal used to reboot the container
102
103   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
109       lxc.signal.stop
110              specify the signal used to stop the container
111
112   INIT COMMAND
113       Sets the command to use as the init system for the containers.
114
115       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
119       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
124   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
129       lxc.init.cwd
130              Absolute  path inside the container to use as the working direc‐
131              tory.
132
133   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
140       lxc.init.uid
141              UID to use for init.
142
143       lxc.init.gid
144              GID to use for init.
145
146   PROC
147       Configure proc filesystem for the container.
148
149       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
153                            lxc.proc.oom_score_adj = 10
154
155
156   EPHEMERAL
157       Allows  one  to  specify whether a container will be destroyed on shut‐
158       down.
159
160       lxc.ephemeral
161              The only allowed values are 0 and 1. Set this to 1 to destroy  a
162              container on shutdown.
163
164   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
172       lxc.net
173              may be used without  a  value  to  clear  all  previous  network
174              options.
175
176       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
186              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
194              empty: will create only the loopback interface.
195
196              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
209              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
213              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
238              phys:  an  already   existing   interface   specified   by   the
239              lxc.net.[i].link is assigned to the container.
240
241       lxc.net.[i].flags
242              Specify an action to do for the network.
243
244              up: activates the interface.
245
246       lxc.net.[i].link
247              Specify the interface to be used for real network traffic.
248
249       lxc.net.[i].mtu
250              Specify the maximum transfer unit for this interface.
251
252       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
258       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
265       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
270       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
278       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
283       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
291       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
296              In addition to the information available to all hooks. The  fol‐
297              lowing information is provided to the script:
298
299              · LXC_HOOK_TYPE: the hook type. This is either 'up' or 'down'.
300
301              · LXC_HOOK_SECTION: the section type 'net'.
302
303              · LXC_NET_TYPE:  the network type. This is one of the valid net‐
304                work types listed here (e.g. 'macvlan', 'veth').
305
306              · LXC_NET_PARENT: the parent device on the host.  This  is  only
307                set for network types 'mavclan', 'veth', 'phys'.
308
309              · 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
313       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
319       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
323       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
327              In addition to the information available to all hooks. The  fol‐
328              lowing information is provided to the script:
329
330              · LXC_HOOK_TYPE: the hook type. This is either 'up' or 'down'.
331
332              · LXC_HOOK_SECTION: the section type 'net'.
333
334              · LXC_NET_TYPE:  the network type. This is one of the valid net‐
335                work types listed here (e.g. 'macvlan', 'veth').
336
337              · LXC_NET_PARENT: the parent device on the host.  This  is  only
338                set for network types 'mavclan', 'veth', 'phys'.
339
340              · 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
344       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
350       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
354   NEW PSEUDO TTY INSTANCE (DEVPTS)
355       For  stricter isolation the container can have its own private instance
356       of the pseudo tty.
357
358       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
364   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
369       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
384       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
401       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
409       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
419       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
429   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
438       lxc.tty.max
439              Specify the number of tty to make available to the container.
440
441   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
451       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
456   /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
468       lxc.autodev
469              Set this to 0 to stop LXC from mounting and populating a minimal
470              /dev when starting the container.
471
472   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
478       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
488       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
494                           proc proc proc nodev,noexec,nosuid 0 0
495
496
497              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
502              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
506       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
515              dev/null proc/kcore none bind,relative 0 0
516              .fi
517
518              Will expand dev/null to ${LXC_ROOTFS_MOUNT}/dev/null,
519              and mount it to proc/kcore inside the container.
520
521       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
526              · 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
532              · proc:rw: mount
533                /proc as read-write
534
535              · sys:mixed (or sys):
536                mount /sys as read-only but with
537                /sys/devices/virtual/net writable.
538
539              · sys:ro:
540                mount /sys as read-only
541                for security / container isolation purposes.
542
543              · sys:rw: mount
544                /sys as read-write
545
546              · 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
555              · 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
563              · cgroup:ro:
564                similar to cgroup:mixed, but everything will
565                be mounted read-only.
566
567              · 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
575              · 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
582              · 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
590              · cgroup (without specifier):
591                defaults to cgroup:rw if the
592                container retains the CAP_SYS_ADMIN capability,
593                cgroup:mixed otherwise.
594
595              · 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
611              · 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
619              · cgroup-full:ro: similar to
620                cgroup-full:mixed, but everything
621                will be mounted read-only.
622
623              · 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
631              · 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
639              · 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
647              · 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
652       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
657       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
673       Examples:
674
675                     lxc.mount.auto = proc sys cgroup
676                     lxc.mount.auto = proc:rw sys:rw cgroup-full:rw
677
678
679   ROOT FILE SYSTEM
680       The root file system of the container can be different than that of the
681       host system.
682
683       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
688              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
699       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
704       lxc.rootfs.options
705              extra mount options to use when mounting the rootfs.
706
707   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
714       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
722       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
730       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
742   CAPABILITIES
743       The  capabilities can be dropped in the container if this one is run as
744       root.
745
746       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
755       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
762   NAMESPACES
763       A namespace  can  be  cloned  (lxc.namespace.clone),  kept  (lxc.names‐
764       pace.keep) or shared (lxc.namespace.share.[namespace identifier]).
765
766       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
775              To  create  a  new  mount,  net and ipc namespace set lxc.names‐
776              pace.clone=mount net ipc.
777
778       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
787              To keep the network,  user  and  ipc  namespace  set  lxc.names‐
788              pace.keep=user net ipc.
789
790              Note  that sharing pid namespaces will likely not work with most
791              init systems.
792
793              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
797       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
803              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
807              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
811              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
816              In order to inherit namespaces the caller needs to  have  suffi‐
817              cient privilege over the process or container.
818
819              Note  that sharing pid namespaces between system containers will
820              likely not work with most init systems.
821
822              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
826   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
831       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
843   SYSCTL
844       Configure kernel parameters for the container.
845
846       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
854   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
861       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
865              lxc.apparmor.profile = unconfined
866
867              If the apparmor profile should remain unchanged (i.e. if you are
868              nesting containers and are already confined), then use
869
870              lxc.apparmor.profile = unchanged
871
872       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
880              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
886   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
894       lxc.selinux.context
895              Specify the SELinux context under which the container should  be
896              run or unconfined_t. For example
897
898              lxc.selinux.context = system_u:system_r:lxc_t:s0:c22
899
900   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
906       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
912       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
916       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
920             2
921             blacklist
922             mknod errno 0
923
924
925       lxc.seccomp.profile
926              Specify a file containing  the  seccomp  configuration  to  load
927              before the container starts.
928
929   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
939       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
943   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
952       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
959   CONTAINER HOOKS
960       Container  hooks are programs or scripts which can be executed at vari‐
961       ous times in a container's lifetime.
962
963       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
968       · Container name.
969
970       · Section (always 'lxc').
971
972       · The hook type (i.e. 'clone' or 'pre-mount').
973
974       · 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
979       The following environment variables are set:
980
981       · LXC_CGNS_AWARE: indicator whether the container is  cgroup  namespace
982         aware.
983
984       · LXC_CONFIG_FILE: the path to the container configuration file.
985
986       · 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
991       · 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
996       · 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
1001       · LXC_LOG_LEVEL: the container's log level.
1002
1003       · LXC_NAME: is the container's name.
1004
1005       · 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
1011       · LXC_ROOTFS_MOUNT: the path to the mounted root filesystem.
1012
1013       · 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
1017       · LXC_SRC_NAME: in the case of the clone hook,  this  is  the  original
1018         container's name.
1019
1020       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
1024       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
1041       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
1045       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
1053       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
1057       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
1066       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
1070       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
1075       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
1085       lxc.hook.post-stop
1086              A hook to be run in the host's namespace after the container has
1087              been shut down.
1088
1089       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
1093       lxc.hook.destroy
1094              A hook to be run when the container is destroyed.
1095
1096   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
1103       LXC_NAME
1104              The LXC name of the container. Useful for  logging  messages  in
1105              common log environments. [-n]
1106
1107       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
1114       LXC_CONSOLE
1115              The  path  to  the  console output of the container if not NULL.
1116              [-c] [lxc.console.path]
1117
1118       LXC_CONSOLE_LOGPATH
1119              The path to the console log output of the container if not NULL.
1120              [-L]
1121
1122       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
1128       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
1132       LXC_SRC_NAME
1133              Only for the clone hook. Is set to the original container name.
1134
1135       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
1139       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
1145   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
1152       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
1157       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
1165              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
1169       lxc.log.file
1170              The file to which logging info should be written.
1171
1172       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
1178   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
1183       lxc.start.auto
1184              Whether the container should be auto-started.  Valid values  are
1185              0 (off) and 1 (on).
1186
1187       lxc.start.delay
1188              How  long  to  wait  (in seconds) after the container is started
1189              before starting the next one.
1190
1191       lxc.start.order
1192              An integer used to sort  the  containers  when  auto-starting  a
1193              series of containers at once.
1194
1195       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
1201       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
1206   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
1211       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
1222   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
1231       This  configuration parameter can be specified multiple times; once for
1232       each environment variable you wish to configure.
1233
1234       lxc.environment
1235              Specify an environment variable  to  pass  into  the  container.
1236              Example:
1237
1238                            lxc.environment = APP_ENV=production
1239                            lxc.environment = SYSLOG_SERVER=192.0.2.42
1240
1241

EXAMPLES

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
1246   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
1252               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
1261
1262   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
1266               lxc.idmap = u 0 100000 10000
1267               lxc.idmap = g 0 100000 10000
1268
1269
1270   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
1276               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
1282
1283   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
1288               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
1320

SEE ALSO

1322       chroot(1), pivot_root(8), fstab(5), capabilities(7)
1323

SEE ALSO

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

AUTHOR

1331       Daniel Lezcano <daniel.lezcano@free.fr>
1332
1333
1334
1335                                  2018-11-23             lxc.container.conf(5)
Impressum