+[[chapter_pct]]
ifdef::manvolnum[]
-PVE({manvolnum})
-================
+pct(1)
+======
include::attributes.txt[]
+:pve-toplevel:
NAME
----
pct - Tool to manage Linux Containers (LXC) on Proxmox VE
-SYNOPSYS
+SYNOPSIS
--------
include::pct.1-synopsis.adoc[]
Proxmox Container Toolkit
=========================
include::attributes.txt[]
+:pve-toplevel:
endif::manvolnum[]
-
+ifdef::wiki[]
+:title: Linux Container
+endif::wiki[]
Containers are a lightweight alternative to fully virtualized
VMs. Instead of emulating a complete Operating System (OS), containers
AppArmor, CGroups and PID and user namespaces, which makes containers
usage quite secure. We distinguish two types of containers:
-Privileged containers
+
+Privileged Containers
~~~~~~~~~~~~~~~~~~~~~
Security is done by dropping capabilities, using mandatory access
trusted environment, or when no untrusted task is running as root in
the container.
-Unprivileged containers
+
+Unprivileged Containers
~~~~~~~~~~~~~~~~~~~~~~~
This kind of containers use a new kernel feature called user
-namespaces. The root uid 0 inside the container is mapped to an
+namespaces. The root UID 0 inside the container is mapped to an
unprivileged user outside the container. This means that most security
issues (container escape, resource abuse, ...) in those containers
will affect a random unprivileged user, and so would be a generic
unprivileged containers are safe by design.
+Guest Operating System Configuration
+------------------------------------
+
+We normally try to detect the operating system type inside the
+container, and then modify some files inside the container to make
+them work as expected. Here is a short list of things we do at
+container startup:
+
+set /etc/hostname:: to set the container name
+
+modify /etc/hosts:: to allow lookup of the local hostname
+
+network setup:: pass the complete network setup to the container
+
+configure DNS:: pass information about DNS servers
+
+adapt the init system:: for example, fix the number of spawned getty processes
+
+set the root password:: when creating a new container
+
+rewrite ssh_host_keys:: so that each container has unique keys
+
+randomize crontab:: so that cron does not start at the same time on all containers
+
+Changes made by {PVE} are enclosed by comment markers:
+
+----
+# --- BEGIN PVE ---
+<data>
+# --- END PVE ---
+----
+
+Those markers will be inserted at a reasonable location in the
+file. If such a section already exists, it will be updated in place
+and will not be moved.
+
+Modification of a file can be prevented by adding a `.pve-ignore.`
+file for it. For instance, if the file `/etc/.pve-ignore.hosts`
+exists then the `/etc/hosts` file will not be touched. This can be a
+simple empty file creatd via:
+
+ # touch /etc/.pve-ignore.hosts
+
+Most modifications are OS dependent, so they differ between different
+distributions and versions. You can completely disable modifications
+by manually setting the `ostype` to `unmanaged`.
+
+OS type detection is done by testing for certain files inside the
+container:
+
+Ubuntu:: inspect /etc/lsb-release (`DISTRIB_ID=Ubuntu`)
+
+Debian:: test /etc/debian_version
+
+Fedora:: test /etc/fedora-release
+
+RedHat or CentOS:: test /etc/redhat-release
+
+ArchLinux:: test /etc/arch-release
+
+Alpine:: test /etc/alpine-release
+
+Gentoo:: test /etc/gentoo-release
+
+NOTE: Container start fails if the configured `ostype` differs from the auto
+detected type.
+
+
+[[pct_configuration]]
Configuration
-------------
running containers. This feature is called "hot plug", and there is no
need to restart the container in that case.
+
File Format
~~~~~~~~~~~
Container configuration files use a simple colon separated key/value
format. Each line has the following format:
- # this is a comment
- OPTION: value
+-----
+# this is a comment
+OPTION: value
+-----
Blank lines in those files are ignored, and lines starting with a `#`
character are treated as comments and are also ignored.
Those settings are directly passed to the LXC low-level tools.
+
+[[pct_snapshots]]
Snapshots
~~~~~~~~~
file. For example, after creating a snapshot called ``testsnapshot'',
your configuration file will look like this:
-.Container Configuration with Snapshot
+.Container configuration with snapshot
----
memory: 512
swap: 512
time stamp (Unix epoch).
-Guest Operating System Configuration
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-We normally try to detect the operating system type inside the
-container, and then modify some files inside the container to make
-them work as expected. Here is a short list of things we do at
-container startup:
-
-set /etc/hostname:: to set the container name
-
-modify /etc/hosts:: to allow lookup of the local hostname
-
-network setup:: pass the complete network setup to the container
-
-configure DNS:: pass information about DNS servers
-
-adapt the init system:: for example, fix the number of spawned getty processes
-
-set the root password:: when creating a new container
-
-rewrite ssh_host_keys:: so that each container has unique keys
-
-randomize crontab:: so that cron does not start at the same time on all containers
-
-Changes made by {PVE} are enclosed by comment markers:
-
-----
-# --- BEGIN PVE ---
-<data>
-# --- END PVE ---
-----
-
-Those markers will be inserted at a reasonable location in the
-file. If such a section already exists, it will be updated in place
-and will not be moved.
-
-Modification of a file can be prevented by adding a `.pve-ignore.`
-file for it. For instance, if the file `/etc/.pve-ignore.hosts`
-exists then the `/etc/hosts` file will not be touched. This can be a
-simple empty file creatd via:
-
- # touch /etc/.pve-ignore.hosts
-
-Most modifications are OS dependent, so they differ between different
-distributions and versions. You can completely disable modifications
-by manually setting the `ostype` to `unmanaged`.
-
-OS type detection is done by testing for certain files inside the
-container:
-
-Ubuntu:: inspect /etc/lsb-release (`DISTRIB_ID=Ubuntu`)
-
-Debian:: test /etc/debian_version
-
-Fedora:: test /etc/fedora-release
-
-RedHat or CentOS:: test /etc/redhat-release
-
-ArchLinux:: test /etc/arch-release
-
-Alpine:: test /etc/alpine-release
-
-Gentoo:: test /etc/gentoo-release
-
-NOTE: Container start fails if the configured `ostype` differs from the auto
-detected type.
-
+[[pct_options]]
Options
~~~~~~~
include::pct.conf.5-opts.adoc[]
+[[pct_container_images]]
Container Images
----------------
pct create 999 local:vztmpl/debian-8.0-standard_8.0-1_amd64.tar.gz
-Proxmox itself ships a set of basic templates for most common
+{pve} itself ships a set of basic templates for most common
operating systems, and you can download them using the `pveam` (short
for {pve} Appliance Manager) command line utility. You can also
download https://www.turnkeylinux.org/[TurnKey Linux] containers using
The above command shows you the full {pve} volume identifiers. They include
the storage name, and most other {pve} commands can use them. For
-examply you can delete that image later with:
+example you can delete that image later with:
pveam remove local:vztmpl/debian-8.0-standard_8.0-1_amd64.tar.gz
+[[pct_container_storage]]
Container Storage
-----------------
Currently there are basically three types of mount points: storage backed
mount points, bind mounts and device mounts.
-.Typical Container `rootfs` configuration
+.Typical container `rootfs` configuration
----
rootfs: thin1:base-100-disk-1,size=8G
----
-Storage backed mount points
+Storage Backed Mount Points
^^^^^^^^^^^^^^^^^^^^^^^^^^^
Storage backed mount points are managed by the {pve} storage subsystem and come
in three different flavors:
-- Image based: These are raw images containing a single ext4 formatted file
+- Image based: these are raw images containing a single ext4 formatted file
system.
-- ZFS Subvolumes: These are technically bind mounts, but with managed storage,
+- ZFS subvolumes: these are technically bind mounts, but with managed storage,
and thus allow resizing and snapshotting.
- Directories: passing `size=0` triggers a special case where instead of a raw
image a directory is created.
-Bind mount points
+Bind Mount Points
^^^^^^^^^^^^^^^^^
Bind mounts allow you to access arbitrary directories from your Proxmox VE host
achieve the same result.
-Device mount points
+Device Mount Points
^^^^^^^^^^^^^^^^^^^
Device mount points allow to mount block devices of the host directly into the
NOTE: The contents of device mount points are not backed up when using `vzdump`.
-FUSE mounts
+FUSE Mounts
~~~~~~~~~~~
WARNING: Because of existing issues in the Linux kernel's freezer
and use a bind mount point to make it accessible inside the container.
-Using quotas inside containers
+Using Quotas Inside Containers
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Quotas allow to set limits inside a container for the amount of disk
the mount point's path instead of just `/`.
-Using ACLs inside containers
+Using ACLs Inside Containers
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-The standard Posix Access Control Lists are also available inside containers.
+The standard Posix **A**ccess **C**ontrol **L**ists are also available inside containers.
ACLs allow you to set more detailed file ownership than the traditional user/
group/others model.
+[[pct_container_network]]
Container Network
-----------------
Backup and Restore
------------------
+
Container Backup
~~~~~~~~~~~~~~~~
...). You can use pct to set parameters in the associated config file,
like network configuration or memory limits.
+
CLI Usage Examples
~~~~~~~~~~~~~~~~~~
Create a container based on a Debian template (provided you have
-already downloaded the template via the webgui)
+already downloaded the template via the web interface)
pct create 100 /var/lib/vz/template/cache/debian-8.0-standard_8.0-1_amd64.tar.gz
pct set 100 -memory 512
-Files
-------
+Obtaining Debugging Logs
+~~~~~~~~~~~~~~~~~~~~~~~~
-`/etc/pve/lxc/<CTID>.conf`::
+In case `pct start` is unable to start a specific container, it might be
+helpful to collect debugging output by running `lxc-start` (replace `ID` with
+the container's ID):
-Configuration file for the container '<CTID>'.
+ lxc-start -n ID -F -l DEBUG -o /tmp/lxc-ID.log
+
+This command will attempt to start the container in foreground mode, to stop the container run `pct shutdown ID` or `pct stop ID` in a second terminal.
+
+The collected debug log is written to `/tmp/lxc-ID.log`.
+
+NOTE: If you have changed the container's configuration since the last start
+attempt with `pct start`, you need to run `pct start` at least once to also
+update the configuration used by `lxc-start`.
+
+Locks
+-----
+
+Container migrations, snapshots and backups (`vzdump`) set a lock to
+prevent incompatible concurrent actions on the affected container. Sometimes
+you need to remove such a lock manually (e.g., after a power failure).
+
+ pct unlock <CTID>
+
+CAUTION: Only do that if you are sure the action which set the lock is
+no longer running.
Container Advantages
Technology Overview
-------------------
-- Integrated into {pve} graphical user interface (GUI)
+* Integrated into {pve} graphical user interface (GUI)
-- LXC (https://linuxcontainers.org/)
+* LXC (https://linuxcontainers.org/)
-- cgmanager for cgroup management
+* lxcfs to provide containerized /proc file system
-- lxcfs to provive containerized /proc file system
+* AppArmor
-- apparmor
+* CRIU: for live migration (planned)
-- CRIU: for live migration (planned)
+* We use latest available kernels (4.4.X)
-- We use latest available kernels (4.4.X)
+* Image based deployment (templates)
-- Image based deployment (templates)
-
-- Container setup from host (Network, DNS, Storage, ...)
+* Container setup from host (network, DNS, storage, ...)
ifdef::manvolnum[]
+
+Files
+------
+
+`/etc/pve/lxc/<CTID>.conf`::
+
+Configuration file for the container '<CTID>'.
+
+
include::pve-copyright.adoc[]
endif::manvolnum[]