trusty (5) lxc.container.conf.5.gz

Provided by: lxc_1.0.10-0ubuntu1.1_amd64 bug

NAME

       lxc.container.conf - LXC container configuration file

DESCRIPTION

       The  linux  containers  (lxc) are always created before being used. This creation defines a set of system
       resources to be virtualized / isolated when a process is using the container. By default, the pids,  sysv
       ipc  and  mount  points  are  virtualized  and  isolated.  The  other  system resources are shared across
       containers, until they are explicitly defined in the configuration file. For  example,  if  there  is  no
       network  configuration, the network will be shared between the creator of the container and the container
       itself, but if the network is specified, a new network  stack  is  created  for  the  container  and  the
       container can no longer use the network of its ancestor.

       The  configuration  file  defines  the  different  system  resources to be assigned for the container. At
       present, the utsname, the network, the mount points, the root file system, the user  namespace,  and  the
       control groups are supported.

       Each  option  in  the  configuration file has the form key = value fitting in one line. The '#' character
       means the line is a comment. List options, like capabilities and cgroups options, can  be  used  with  no
       value to clear any previously defined values of that option.

   CONFIGURATION
       In  order  to  ease  administration  of  multiple  related containers, it is possible to have a container
       configuration file cause another file to be loaded. For instance, network configuration can be defined in
       one  common  file  which is included by multiple containers. Then, if the containers are moved to another
       host, only one file may need to be updated.

       lxc.include
              Specify the file to be included. The included file must be in the  same  valid  lxc  configuration
              file format.

   ARCHITECTURE
       Allows  one  to  set  the  architecture  for  the container. For example, set a 32bits architecture for a
       container running 32bits binaries on a 64bits host. This fixes the container scripts which  rely  on  the
       architecture to do some work like downloading the packages.

       lxc.arch
              Specify the architecture for the container.

              Valid options are x86, i686, x86_64, amd64

   HOSTNAME
       The  utsname  section  defines the hostname to be set for the container. That means the container can set
       its own hostname without changing the one from the system.  That  makes  the  hostname  private  for  the
       container.

       lxc.utsname
              specify the hostname for the container

   HALT SIGNAL
       Allows  one to specify signal name or number, sent by lxc-stop to the container's init process to cleanly
       shutdown the container. Different init systems could use different  signals  to  perform  clean  shutdown
       sequence.  This  option  allows  the signal to be specified in kill(1) fashion, e.g. SIGPWR, SIGRTMIN+14,
       SIGRTMAX-10 or plain number. The default signal is SIGPWR.

       lxc.haltsignal
              specify the signal used to halt the container

   STOP SIGNAL
       Allows one to specify signal name or number, sent by lxc-stop to forcibly shutdown  the  container.  This
       option  allows signal to be specified in kill(1) fashion, e.g. SIGKILL, SIGRTMIN+14, SIGRTMAX-10 or plain
       number.  The default signal is SIGKILL.

       lxc.stopsignal
              specify the signal used to stop the container

   NETWORK
       The network section defines how the network is virtualized in the container. The  network  virtualization
       acts at layer two. In order to use the network virtualization, parameters must be specified to define the
       network interfaces of the container. Several virtual interfaces can be assigned and used in  a  container
       even if the system has only one physical network interface.

       lxc.network
              may be used without a value to clear all previous network options.

       lxc.network.type
              specify  what  kind  of  network  virtualization  to  be  used  for  the  container.  Each  time a
              lxc.network.type field is found a new round of network configuration begins. In this way,  several
              network virtualization types can be specified for the same container, as well as assigning several
              network interfaces for one container. The different virtualization types can be:

              none: will cause the container to share the host's network namespace. This means the host  network
              devices  are  usable  in  the  container.  It  also means that if both the container and host have
              upstart as init, 'halt' in a container (for instance) will shut down the host.

              empty: will create only the loopback interface.

              veth: a virtual ethernet pair device is created with one side assigned to the  container  and  the
              other  side  attached  to a bridge specified by the lxc.network.link option.  If the bridge is not
              specified, then the veth pair device will be created but not attached to any  bridge.   Otherwise,
              the  bridge  has  to be created on the system before starting the container.  lxc won't handle any
              configuration outside of the container.  By default, lxc chooses a name  for  the  network  device
              belonging to the outside of the container, but if you wish to handle this name yourselves, you can
              tell lxc to set a specific name with the lxc.network.veth.pair  option  (except  for  unprivileged
              containers where this option is ignored for security reasons).

              vlan: a vlan interface is linked with the interface specified by the lxc.network.link and assigned
              to the container. The vlan identifier is specified with the option lxc.network.vlan.id.

              macvlan: a macvlan interface is linked with the interface specified by  the  lxc.network.link  and
              assigned  to  the  container.  lxc.network.macvlan.mode specifies the mode the macvlan will use to
              communicate between different macvlan on the same upper device. The accepted  modes  are  private,
              the device never communicates with any other device on the same upper_dev (default), vepa, the new
              Virtual Ethernet Port Aggregator (VEPA) mode, it assumes that  the  adjacent  bridge  returns  all
              frames  where both source and destination are local to the macvlan port, i.e. the bridge is set up
              as a reflective relay. Broadcast frames coming in from the upper_dev get flooded  to  all  macvlan
              interfaces  in  VEPA  mode,  local  frames  are  not delivered locally, or bridge, it provides the
              behavior of a simple bridge between different macvlan interfaces on the same port. Frames from one
              interface  to another one get delivered directly and are not sent out externally. Broadcast frames
              get flooded to all other bridge ports and to the external interface, but when they come back  from
              a  reflective relay, we don't deliver them again. Since we know all the MAC addresses, the macvlan
              bridge mode does not require learning or STP like the bridge module does.

              phys: an already  existing  interface  specified  by  the  lxc.network.link  is  assigned  to  the
              container.

       lxc.network.flags
              specify an action to do for the network.

              up: activates the interface.

       lxc.network.link
              specify the interface to be used for real network traffic.

       lxc.network.mtu
              specify the maximum transfer unit for this interface.

       lxc.network.name
              the  interface  name  is  dynamically  allocated,  but  if  another  name  is  needed  because the
              configuration files being used by the container use a generic name, eg.  eth0,  this  option  will
              rename the interface in the container.

       lxc.network.hwaddr
              the  interface  mac  address  is dynamically allocated by default to the virtual interface, but in
              some cases, this is needed to resolve a mac address conflict or to always have the same link-local
              ipv6  address.   Any  "x"  in address will be replaced by random value, this allows setting hwaddr
              templates.

       lxc.network.ipv4
              specify the ipv4 address to assign to the virtualized interface.  Several  lines  specify  several
              ipv4  addresses.   The address is in format x.y.z.t/m, eg. 192.168.1.123/24. The broadcast address
              should be specified on the same line, right after the ipv4 address.

       lxc.network.ipv4.gateway
              specify the ipv4 address to use as the gateway inside the container.  The  address  is  in  format
              x.y.z.t,  eg.   192.168.1.123.   Can  also  have  the  special value auto, which means to take the
              primary address from the bridge interface (as specified by the lxc.network.link  option)  and  use
              that as the gateway. auto is only available when using the veth and macvlan network types.

       lxc.network.ipv6
              specify  the  ipv6  address  to assign to the virtualized interface. Several lines specify several
              ipv6 addresses.  The address is in format x::y/m, eg. 2003:db8:1:0:214:1234:fe0b:3596/64

       lxc.network.ipv6.gateway
              specify the ipv6 address to use as the gateway inside the container.  The  address  is  in  format
              x::y,  eg.  2003:db8:1:0::1  Can also have the special value auto, which means to take the primary
              address from the bridge interface (as specified by the lxc.network.link option) and  use  that  as
              the gateway. auto is only available when using the veth and macvlan network types.

       lxc.network.script.up
              add  a  configuration option to specify a script to be executed after creating and configuring the
              network used from the host side. The following arguments are passed to the script: container  name
              and config section name (net) Additional arguments depend on the config section employing a script
              hook; the following are  used  by  the  network  system:  execution  context  (up),  network  type
              (empty/veth/macvlan/phys),  Depending  on  the  network  type,  other  arguments  may  be  passed:
              veth/macvlan/phys. And finally (host-sided) device name.

              Standard output from the script is logged at debug level.  Standard error is not logged,  but  can
              be captured by the hook redirecting its standard error to standard output.

       lxc.network.script.down
              add  a  configuration option to specify a script to be executed before destroying the network used
              from the host side. The following arguments are passed to the script: container  name  and  config
              section  name (net) Additional arguments depend on the config section employing a script hook; the
              following  are  used  by  the   network   system:   execution   context   (down),   network   type
              (empty/veth/macvlan/phys),  Depending  on  the  network  type,  other  arguments  may  be  passed:
              veth/macvlan/phys. And finally (host-sided) device name.

              Standard output from the script is logged at debug level.  Standard error is not logged,  but  can
              be captured by the hook redirecting its standard error to standard output.

   NEW PSEUDO TTY INSTANCE (DEVPTS)
       For stricter isolation the container can have its own private instance of the pseudo tty.

       lxc.pts
              If  set,  the  container will have a new pseudo tty instance, making this private to it. The value
              specifies the maximum number of pseudo ttys allowed for a pts instance  (this  limitation  is  not
              implemented yet).

   CONTAINER SYSTEM CONSOLE
       If  the  container is configured with a root filesystem and the inittab file is setup to use the console,
       you may want to specify where the output of this console goes.

       lxc.console.logfile
              Specify a path to a file where the console output will be written.

       lxc.console
              Specify a path to a device to which the console will be attached. The keyword 'none'  will  simply
              disable  the console. This is dangerous once if have a rootfs with a console device file where the
              application can write, the messages will fall in the host.

   CONSOLE THROUGH THE TTYS
       This option is useful if the container is configured with a root filesystem and the inittab file is setup
       to launch a getty on the ttys. The option specifies the number of ttys to be available for the container.
       The number of gettys in the inittab file of the container should not be greater than the number  of  ttys
       specified  in  this  option, otherwise the excess getty sessions will die and respawn indefinitely giving
       annoying messages on the console or in /var/log/messages.

       lxc.tty
              Specify the number of tty to make available to the container.

   CONSOLE DEVICES LOCATION
       LXC consoles are provided through Unix98 PTYs created on the host  and  bind-mounted  over  the  expected
       devices  in  the  container.  By default, they are bind-mounted over /dev/console and /dev/ttyN. This can
       prevent package upgrades in the guest. Therefore you can specify a directory location (under  /dev  under
       which  LXC  will  create  the  files  and bind-mount over them. These will then be symbolically linked to
       /dev/console and /dev/ttyN.  A package upgrade can then succeed as it is able to remove and  replace  the
       symbolic links.

       lxc.devttydir
              Specify a directory under /dev under which to create the container console devices.

   /DEV DIRECTORY
       By  default,  lxc creates a few symbolic links (fd,stdin,stdout,stderr) in the container's /dev directory
       but does not automatically create device node entries. This allows the container's /dev to be set  up  as
       needed  in  the  container rootfs. If lxc.autodev is set to 1, then after mounting the container's rootfs
       LXC will mount a fresh tmpfs under /dev (limited to 500k) and fill in a minimal set of  initial  devices.
       This  is  generally  required  when  starting  a container containing a "systemd" based "init" but may be
       optional at other times. Additional devices in the containers /dev directory may be created  through  the
       use of the lxc.hook.autodev hook.

       lxc.autodev
              Set this to 1 to have LXC mount and populate a minimal /dev when starting the container.

   ENABLE KMSG SYMLINK
       Enable creating /dev/kmsg as symlink to /dev/console. This defaults to 1.

       lxc.kmsg
              Set this to 0 to disable /dev/kmsg symlinking.

   MOUNT POINTS
       The mount points section specifies the different places to be mounted. These mount points will be private
       to the container and won't be visible by the processes running outside of the container. This  is  useful
       to mount /etc, /var or /home for examples.

       NOTE - LXC will generally ensure that mount targets and relative bind-mount sources are properly confined
       under the container root, to avoid attacks involving over-mounting host directories and files.  (Symbolic
       links  in  absolute  mount  sources  are  ignored) However, if the container configuration first mounts a
       directory which is under the control of the container user, such as /home/joe, into the container at some
       path,  and  then  mounts  under  path,  then  a TOCTTOU attack would be possible where the container user
       modifies a symbolic link under his home directory at just the right time.

       lxc.mount
              specify a file location in the fstab format, containing the mount information.  The  mount  target
              location  can  and  in  most  cases  should  be a relative path, which will become relative to the
              mounted container root. For instance,

              proc proc proc nodev,noexec,nosuid 0 0
              .fi

              Will mount a proc filesystem under the container's /proc,
              regardless of where the root filesystem comes from. This
              is resilient to block device backed filesystems as well as
              container cloning.

              Note that when mounting a filesystem from an
              image file or block device the third field (fs_vfstype)
              cannot be auto as with
              mount(8)
              but must be explicitly specified.

       lxc.mount.entry
              specify a mount point corresponding to a line in the
              fstab format.
              Moreover lxc add two options to mount.
              optional don't fail if mount does not work.
              create=dir or create=file
              to create dir (or file) when the point will be mounted.

       lxc.mount.auto
              specify which standard kernel file systems should be
              automatically mounted. This may dramatically simplify
              the configuration. The file systems are:

              • proc:mixed (or proc):
                mount /proc as read-write, but
                remount /proc/sys and
                /proc/sysrq-trigger read-only
                for security / container isolation purposes.

              • proc:rw: mount
                /proc as read-write

              • sys:ro (or sys):
                mount /sys as read-only
                for security / container isolation purposes.

              • sys:rw: mount
                /sys as read-write

              • cgroup:mixed:
                mount a tmpfs to /sys/fs/cgroup,
                create directories for all hierarchies to which
                the container is added, create subdirectories
                there with the name of the cgroup, and bind-mount
                the container's own cgroup into that directory.
                The container will be able to write to its own
                cgroup directory, but not the parents, since they
                will be remounted read-only

              • cgroup:ro: similar to
                cgroup:mixed, but everything will
                be mounted read-only.

              • cgroup:rw: similar to
                cgroup:mixed, but everything will
                be mounted read-write. Note that the paths leading
                up to the container's own cgroup will be writable,
                but will not be a cgroup filesystem but just part
                of the tmpfs of /sys/fs/cgroupcgroup (without specifier):
                defaults to cgroup:rw if the
                container retains the CAP_SYS_ADMIN capability,
                cgroup:mixed otherwise.

              • cgroup-full:mixed:
                mount a tmpfs to /sys/fs/cgroup,
                create directories for all hierarchies to which
                the container is added, bind-mount the hierarchies
                from the host to the container and make everything
                read-only except the container's own cgroup. Note
                that compared to cgroup, where
                all paths leading up to the container's own cgroup
                are just simple directories in the underlying
                tmpfs, here
                /sys/fs/cgroup/$hierarchy
                will contain the host's full cgroup hierarchy,
                albeit read-only outside the container's own cgroup.
                This may leak quite a bit of information into the
                container.

              • cgroup-full:ro: similar to
                cgroup-full:mixed, but everything
                will be mounted read-only.

              • cgroup-full:rw: similar to
                cgroup-full:mixed, but everything
                will be mounted read-write. Note that in this case,
                the container may escape its own cgroup. (Note also
                that if the container has CAP_SYS_ADMIN support
                and can mount the cgroup filesystem itself, it may
                do so anyway.)

              • cgroup-full (without specifier):
                defaults to cgroup-full:rw if the
                container retains the CAP_SYS_ADMIN capability,
                cgroup-full:mixed otherwise.

       Note that if automatic mounting of the cgroup filesystem
       is enabled, the tmpfs under
       /sys/fs/cgroup will always be
       mounted read-write (but for the :mixed
       and :ro cases, the individual
       hierarchies,
       /sys/fs/cgroup/$hierarchy, will be
       read-only). This is in order to work around a quirk in
       Ubuntu's
       mountall(8)
       command that will cause containers to wait for user
       input at boot if
       /sys/fs/cgroup is mounted read-only
       and the container can't remount it read-write due to a
       lack of CAP_SYS_ADMIN.

       Examples:

                     lxc.mount.auto = proc sys cgroup
                     lxc.mount.auto = proc:rw sys:rw cgroup-full:rw

   ROOT FILE SYSTEM
       The root file system of the container can be different than that of the host system.

       lxc.rootfs
              specify the root file system for the container. It can be an image file, a directory  or  a  block
              device. If not specified, the container shares its root file system with the host.

       lxc.rootfs.mount
              where  to  recursively  bind  lxc.rootfs  before  pivoting.  This  is  to  ensure  success  of the
              pivot_root(8) syscall. Any directory suffices, the default should generally work.

       lxc.rootfs.options
              extra mount options to use when mounting the rootfs.

       lxc.pivotdir
              where to pivot the original root file system under lxc.rootfs, specified relatively to  that.  The
              default  is mnt.  It is created if necessary, and also removed after unmounting everything from it
              during container setup.

   CONTROL GROUP
       The control group section contains the configuration for the different subsystem. lxc does not check  the
       correctness  of the subsystem name. This has the disadvantage of not detecting configuration errors until
       the container is started, but has the advantage of permitting any future subsystem.

       lxc.cgroup.[subsystem name]
              specify the control group value to be set. The subsystem name is the literal name of  the  control
              group  subsystem.  The  permitted  names  and  the  syntax of their values is not dictated by LXC,
              instead it depends on the features of the Linux kernel  running  at  the  time  the  container  is
              started, eg. lxc.cgroup.cpuset.cpus

   CAPABILITIES
       The capabilities can be dropped in the container if this one is run as root.

       lxc.cap.drop
              Specify the capability to be dropped in the container. A single line defining several capabilities
              with a space separation is allowed. The format is the lower  case  of  the  capability  definition
              without   the   "CAP_"   prefix,  eg.  CAP_SYS_MODULE  should  be  specified  as  sys_module.  See
              capabilities(7).  If used with no value, lxc will clear any drop capabilities specified up to this
              point.

       lxc.cap.keep
              Specify the capability to be kept in the container. All other capabilities will be dropped.

   APPARMOR PROFILE
       If  lxc  was compiled and installed with apparmor support, and the host system has apparmor enabled, then
       the apparmor profile under which  the  container  should  be  run  can  be  specified  in  the  container
       configuration. The default is lxc-container-default.

       lxc.aa_profile
              Specify  the  apparmor  profile  under  which  the  container  should  be run. To specify that the
              container should be unconfined, use

              lxc.aa_profile = unconfined

   SELINUX CONTEXT
       If lxc was compiled and installed with SELinux support, and the host system has SELinux enabled, then the
       SELinux  context under which the container should be run can be specified in the container configuration.
       The  default  is  unconfined_t,  which  means  that  lxc  will  not  attempt  to  change  contexts.   See
       /usr/share/lxc/selinux/lxc.te for an example policy and more information.

       lxc.se_context
              Specify the SELinux context under which the container should be run or unconfined_t. For example

              lxc.se_context = system_u:system_r:lxc_t:s0:c22

   SECCOMP CONFIGURATION
       A  container  can be started with a reduced set of available system calls by loading a seccomp profile at
       startup. The seccomp configuration file must begin with a version number on the first line, a policy type
       on the second line, followed by the configuration.

       Versions 1 and 2 are currently supported. In version 1, the policy is a simple whitelist. The second line
       therefore must read "whitelist", with the rest of the file containing one  (numeric)  sycall  number  per
       line.  Each  syscall  number  is  whitelisted,  while every unlisted number is blacklisted for use in the
       container

       In version 2, the policy may be blacklist or whitelist, supports per-rule and per-policy default actions,
       and supports per-architecture system call resolution from textual names.

       An example blacklist policy, in which all system calls are allowed except for mknod, which will simply do
       nothing and return 0 (success), looks like:

       2
       blacklist
       mknod errno 0
       .fi

       lxc.seccomp
              Specify a file containing the seccomp configuration to
              load before the container starts.

   UID MAPPINGS
       A container can be started in a private user namespace with user and group id mappings. For instance, you
       can  map  userid  0 in the container to userid 200000 on the host. The root user in the container will be
       privileged in the container, but unprivileged on the host. Normally a system container will want a  range
       of  ids,  so you would map, for instance, user and group ids 0 through 20,000 in the container to the ids
       200,000 through 220,000.

       lxc.id_map
              Four values must be provided. First a character, either 'u', or 'g', to specify  whether  user  or
              group  ids  are  being  mapped.  Next  is  the  first  userid as seen in the user namespace of the
              container. Next is the userid as seen on the host. Finally,  a  range  indicating  the  number  of
              consecutive ids to map.

   CONTAINER HOOKS
       Container hooks are programs or scripts which can be executed at various times in a container's lifetime.

       When  a  container  hook  is  executed,  information is passed both as command line arguments and through
       environment variables.  The arguments are:

       • Container name.

       • Section (always 'lxc').

       • The hook type (i.e. 'clone' or 'pre-mount').

       • Additional arguments In the case of the clone hook, any extra arguments passed to lxc-clone will appear
         as further arguments to the hook.

       The following environment variables are set:

       • LXC_NAME: is the container's name.

       • LXC_ROOTFS_MOUNT: the path to the mounted root filesystem.

       • LXC_CONFIG_FILE: the path to the container configuration file.

       • LXC_SRC_NAME: in the case of the clone hook, this is the original container's name.

       • LXC_ROOTFS_PATH:  this  is  the  lxc.rootfs  entry for the container. Note this is likely not where the
         mounted rootfs is to be found, use LXC_ROOTFS_MOUNT for that.

       Standard output from the hooks is logged at debug level.  Standard  error  is  not  logged,  but  can  be
       captured by the hook redirecting its standard error to standard output.

       lxc.hook.pre-start
              A hook to be run in the host's namespace before the container ttys, consoles, or mounts are up.

       lxc.hook.pre-mount
              A  hook  to  be  run  in  the container's fs namespace but before the rootfs has been set up. This
              allows for manipulation of the rootfs, i.e. to mount an encrypted filesystem. Mounts done in  this
              hook  will  not  be  reflected  on  the  host  (apart  from  mounts  propagation), so they will be
              automatically cleaned up when the container shuts down.

       lxc.hook.mount
              A hook to be run in the container's namespace  after  mounting  has  been  done,  but  before  the
              pivot_root.

       lxc.hook.autodev
              A  hook  to  be  run in the container's namespace after mounting has been done and after any mount
              hooks have run, but before the pivot_root, if lxc.autodev == 1.  The purpose of this  hook  is  to
              assist in populating the /dev directory of the container when using the autodev option for systemd
              based  containers.  The  container's  /dev  directory  is  relative  to  the   ${LXC_ROOTFS_MOUNT}
              environment variable available when the hook is run.

       lxc.hook.start
              A  hook  to be run in the container's namespace immediately before executing the container's init.
              This requires the program to be available in the container.

       lxc.hook.post-stop
              A hook to be run in the host's namespace after the container has been shut down.

       lxc.hook.clone
              A hook to be run when  the  container  is  cloned  to  a  new  one.   See  lxc-clone(1)  for  more
              information.

   CONTAINER HOOKS ENVIRONMENT VARIABLES
       A  number  of  environment  variables  are  made  available to the startup hooks to provide configuration
       information and assist in the functioning of the hooks. Not all variables are valid in all  contexts.  In
       particular,  all  paths are relative to the host system and, as such, not valid during the lxc.hook.start
       hook.

       LXC_NAME
              The LXC name of the container. Useful for logging messages in common log environments. [-n]

       LXC_CONFIG_FILE
              Host relative path to the container configuration file. This gives the container to reference  the
              original,  top  level,  configuration  file  for  the  container in order to locate any additional
              configuration information not otherwise made available. [-f]

       LXC_CONSOLE
              The path to the console output of the container if not NULL.  [-c] [lxc.console]

       LXC_CONSOLE_LOGPATH
              The path to the console log output of the container if not NULL.  [-L]

       LXC_ROOTFS_MOUNT
              The mount location to which the container is initially bound.  This will be the host relative path
              to  the  container  rootfs for the container instance being started and is where changes should be
              made for that instance.  [lxc.rootfs.mount]

       LXC_ROOTFS_PATH
              The host relative path to the container root which has been mounted to the rootfs.mount  location.
              [lxc.rootfs]

   LOGGING
       Logging  can  be  configured on a per-container basis. By default, depending upon how the lxc package was
       compiled, container startup is logged only at the ERROR level, and logged  to  a  file  named  after  the
       container (with '.log' appended) either under the container path, or under /var/log/lxc.

       Both  the  default  log  level  and  the  log  file can be specified in the container configuration file,
       overriding the default behavior. Note that the configuration file entries can in turn  be  overridden  by
       the command line options to lxc-start.

       lxc.loglevel
              The  level  at  which  to log. The log level is an integer in the range of 0..8 inclusive, where a
              lower number means more verbose debugging. In particular 0 = trace, 1 =  debug,  2  =  info,  3  =
              notice,  4  =  warn,  5 = error, 6 = critical, 7 = alert, and 8 = fatal. If unspecified, the level
              defaults to 5 (error), so that only errors and above are logged.

              Note that when a script (such as either a hook script or a network interface up or down script) is
              called, the script's standard output is logged at level 1, debug.

       lxc.logfile
              The file to which logging info should be written.

   AUTOSTART
       The  autostart  options  support marking which containers should be auto-started and in what order. These
       options may be used by LXC tools directly or by external tooling provided by the distributions.

       lxc.start.auto
              Whether the container should be auto-started.  Valid values are 0 (off) and 1 (on).

       lxc.start.delay
              How long to wait (in seconds) after the container is started before starting the next one.

       lxc.start.order
              An integer used to sort the containers when auto-starting a series of containers at once.

       lxc.group
              A multi-value key (can be used multiple times) to put the container in a  container  group.  Those
              groups can then be used (amongst other things) to start a series of related containers.

   AUTOSTART AND SYSTEM BOOT
       Each  container  can  be part of any number of groups or no group at all.  Two groups are special. One is
       the NULL group, i.e. the container does not belong to any group. The other group is the "onboot" group.

       When the system boots with the LXC service enabled, it will first attempt to  boot  any  containers  with
       lxc.start.auto  ==  1  that  is  a  member  of  the  "onboot"  group.  The  startup  will  be in order of
       lxc.start.order.  If an lxc.start.delay has been specified, that delay will be honored before  attempting
       to  start  the  next  container  to  give  the  current container time to begin initialization and reduce
       overloading the host system. After starting the members of  the  "onboot"  group,  the  LXC  system  will
       proceed  to  boot containers with lxc.start.auto == 1 which are not members of any group (the NULL group)
       and proceed as with the onboot group.

EXAMPLES

       In addition to the few examples given below, you will find some other examples of configuration  file  in
       /usr/share/doc/lxc/examples

   NETWORK
       This  configuration  sets  up a container to use a veth pair device with one side plugged to a bridge br0
       (which has been configured before on the system by the administrator). The virtual network device visible
       in the container is renamed to eth0.

               lxc.utsname = myhostname
               lxc.network.type = veth
               lxc.network.flags = up
               lxc.network.link = br0
               lxc.network.name = eth0
               lxc.network.hwaddr = 4a:49:43:49:79:bf
               lxc.network.ipv4 = 10.2.3.5/24 10.2.3.255
               lxc.network.ipv6 = 2003:db8:1:0:214:1234:fe0b:3597

   UID/GID MAPPING
       This  configuration  will  map  both  user  and group ids in the range 0-9999 in the container to the ids
       100000-109999 on the host.

               lxc.id_map = u 0 100000 10000
               lxc.id_map = g 0 100000 10000

   CONTROL GROUP
       This configuration will setup several control groups for the application, cpuset.cpus restricts usage  of
       the  defined  cpu,  cpus.share  prioritize  the  control  group, devices.allow makes usable the specified
       devices.

               lxc.cgroup.cpuset.cpus = 0,1
               lxc.cgroup.cpu.shares = 1234
               lxc.cgroup.devices.deny = a
               lxc.cgroup.devices.allow = c 1:3 rw
               lxc.cgroup.devices.allow = b 8:0 rw

   COMPLEX CONFIGURATION
       This example show a complex configuration making a complex  network  stack,  using  the  control  groups,
       setting a new hostname, mounting some locations and a changing root file system.

               lxc.utsname = complex
               lxc.network.type = veth
               lxc.network.flags = up
               lxc.network.link = br0
               lxc.network.hwaddr = 4a:49:43:49:79:bf
               lxc.network.ipv4 = 10.2.3.5/24 10.2.3.255
               lxc.network.ipv6 = 2003:db8:1:0:214:1234:fe0b:3597
               lxc.network.ipv6 = 2003:db8:1:0:214:5432:feab:3588
               lxc.network.type = macvlan
               lxc.network.flags = up
               lxc.network.link = eth0
               lxc.network.hwaddr = 4a:49:43:49:79:bd
               lxc.network.ipv4 = 10.2.3.4/24
               lxc.network.ipv4 = 192.168.10.125/24
               lxc.network.ipv6 = 2003:db8:1:0:214:1234:fe0b:3596
               lxc.network.type = phys
               lxc.network.flags = up
               lxc.network.link = dummy0
               lxc.network.hwaddr = 4a:49:43:49:79:ff
               lxc.network.ipv4 = 10.2.3.6/24
               lxc.network.ipv6 = 2003:db8:1:0:214:1234:fe0b:3297
               lxc.cgroup.cpuset.cpus = 0,1
               lxc.cgroup.cpu.shares = 1234
               lxc.cgroup.devices.deny = a
               lxc.cgroup.devices.allow = c 1:3 rw
               lxc.cgroup.devices.allow = b 8:0 rw
               lxc.mount = /etc/fstab.complex
               lxc.mount.entry = /lib /root/myrootfs/lib none ro,bind 0 0
               lxc.rootfs = /mnt/rootfs.complex
               lxc.cap.drop = sys_module mknod setuid net_raw
               lxc.cap.drop = mac_override

SEE ALSO

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

SEE ALSO

       lxc(7),  lxc-create(1),  lxc-destroy(1),  lxc-start(1), lxc-stop(1), lxc-execute(1), lxc-console(1), lxc-
       monitor(1), lxc-wait(1), lxc-cgroup(1),  lxc-ls(1),  lxc-info(1),  lxc-freeze(1),  lxc-unfreeze(1),  lxc-
       attach(1), lxc.conf(5)

AUTHOR

       Daniel Lezcano <daniel.lezcano@free.fr>

                                                   2017-08-01                              lxc.container.conf(5)