]> git.proxmox.com Git - pve-docs.git/blobdiff - pct.adoc
pct.adoc: move section Technology to the top
[pve-docs.git] / pct.adoc
index bc6d59733a05ce3e41a111b9850c371983acfdc8..b55ce1d2c0f828e8031f68175c44be6c8870e4a3 100644 (file)
--- a/pct.adoc
+++ b/pct.adoc
@@ -1,7 +1,9 @@
+[[chapter_pct]]
 ifdef::manvolnum[]
 ifdef::manvolnum[]
-PVE({manvolnum})
-================
+pct(1)
+======
 include::attributes.txt[]
 include::attributes.txt[]
+:pve-toplevel:
 
 NAME
 ----
 
 NAME
 ----
@@ -9,7 +11,7 @@ NAME
 pct - Tool to manage Linux Containers (LXC) on Proxmox VE
 
 
 pct - Tool to manage Linux Containers (LXC) on Proxmox VE
 
 
-SYNOPSYS
+SYNOPSIS
 --------
 
 include::pct.1-synopsis.adoc[]
 --------
 
 include::pct.1-synopsis.adoc[]
@@ -22,8 +24,11 @@ ifndef::manvolnum[]
 Proxmox Container Toolkit
 =========================
 include::attributes.txt[]
 Proxmox Container Toolkit
 =========================
 include::attributes.txt[]
+:pve-toplevel:
 endif::manvolnum[]
 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
 
 Containers are a lightweight alternative to fully virtualized
 VMs. Instead of emulating a complete Operating System (OS), containers
@@ -63,6 +68,32 @@ NOTE: If you want to run micro-containers (with docker, rkt, ...), it
 is best to run them inside a VM.
 
 
 is best to run them inside a VM.
 
 
+Technology Overview
+-------------------
+
+* LXC (https://linuxcontainers.org/)
+
+* Integrated into {pve} graphical user interface (GUI)
+
+* Easy to use command line tool `pct`
+
+* Access via {pve} REST API
+
+* lxcfs to provide containerized /proc file system
+
+* AppArmor/Seccomp to improve security
+
+* CRIU: for live migration (planned)
+
+* Use latest available kernels (4.4.X)
+
+* Image based deployment (templates)
+
+* Use {pve} storage library
+
+* Container setup from host (network, DNS, storage, ...)
+
+
 Security Considerations
 -----------------------
 
 Security Considerations
 -----------------------
 
@@ -100,96 +131,8 @@ kernel security bug rather than an LXC issue. The LXC team thinks
 unprivileged containers are safe by design.
 
 
 unprivileged containers are safe by design.
 
 
-Configuration
--------------
-
-The `/etc/pve/lxc/<CTID>.conf` file stores container configuration,
-where `<CTID>` is the numeric ID of the given container. Like all
-other files stored inside `/etc/pve/`, they get automatically
-replicated to all other cluster nodes.
-
-NOTE: CTIDs < 100 are reserved for internal purposes, and CTIDs need to be
-unique cluster wide.
-
-.Example Container Configuration
-----
-ostype: debian
-arch: amd64
-hostname: www
-memory: 512
-swap: 512
-net0: bridge=vmbr0,hwaddr=66:64:66:64:64:36,ip=dhcp,name=eth0,type=veth
-rootfs: local:107/vm-107-disk-1.raw,size=7G
-----
-
-Those configuration files are simple text files, and you can edit them
-using a normal text editor (`vi`, `nano`, ...). This is sometimes
-useful to do small corrections, but keep in mind that you need to
-restart the container to apply such changes.
-
-For that reason, it is usually better to use the `pct` command to
-generate and modify those files, or do the whole thing using the GUI.
-Our toolkit is smart enough to instantaneously apply most changes to
-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
------
-
-Blank lines in those files are ignored, and lines starting with a `#`
-character are treated as comments and are also ignored.
-
-It is possible to add low-level, LXC style configuration directly, for
-example:
-
- lxc.init_cmd: /sbin/my_own_init
-
-or
-
- lxc.init_cmd = /sbin/my_own_init
-
-Those settings are directly passed to the LXC low-level tools.
-
-
-Snapshots
-~~~~~~~~~
-
-When you create a snapshot, `pct` stores the configuration at snapshot
-time into a separate snapshot section within the same configuration
-file. For example, after creating a snapshot called ``testsnapshot'',
-your configuration file will look like this:
-
-.Container configuration with snapshot
-----
-memory: 512
-swap: 512
-parent: testsnaphot
-...
-
-[testsnaphot]
-memory: 512
-swap: 512
-snaptime: 1457170803
-...
-----
-
-There are a few snapshot related properties like `parent` and
-`snaptime`. The `parent` property is used to store the parent/child
-relationship between snapshots. `snaptime` is the snapshot creation
-time stamp (Unix epoch).
-
-
 Guest Operating System Configuration
 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
 
 We normally try to detect the operating system type inside the
 container, and then modify some files inside the container to make
@@ -256,12 +199,7 @@ NOTE: Container start fails if the configured `ostype` differs from the auto
 detected type.
 
 
 detected type.
 
 
-Options
-~~~~~~~
-
-include::pct.conf.5-opts.adoc[]
-
-
+[[pct_container_images]]
 Container Images
 ----------------
 
 Container Images
 ----------------
 
@@ -273,7 +211,7 @@ new container, for example:
 
  pct create 999 local:vztmpl/debian-8.0-standard_8.0-1_amd64.tar.gz
 
 
  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
 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
@@ -328,6 +266,7 @@ example you can delete that image later with:
  pveam remove local:vztmpl/debian-8.0-standard_8.0-1_amd64.tar.gz
 
 
  pveam remove local:vztmpl/debian-8.0-standard_8.0-1_amd64.tar.gz
 
 
+[[pct_container_storage]]
 Container Storage
 -----------------
 
 Container Storage
 -----------------
 
@@ -485,6 +424,7 @@ ACLs allow you to set more detailed file ownership than the traditional user/
 group/others model.
 
 
 group/others model.
 
 
+[[pct_container_network]]
 Container Network
 -----------------
 
 Container Network
 -----------------
 
@@ -606,60 +546,144 @@ Reduce the memory of the container to 512MB
  pct set 100 -memory 512
 
 
  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.
 
 
-Container Advantages
---------------------
+The collected debug log is written to `/tmp/lxc-ID.log`.
 
 
-* Simple, and fully integrated into {pve}. Setup looks similar to a normal
-  VM setup. 
+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`.
 
 
-** Storage (ZFS, LVM, NFS, Ceph, ...)
 
 
-** Network
+[[pct_configuration]]
+Configuration
+-------------
 
 
-** Authentication
+The `/etc/pve/lxc/<CTID>.conf` file stores container configuration,
+where `<CTID>` is the numeric ID of the given container. Like all
+other files stored inside `/etc/pve/`, they get automatically
+replicated to all other cluster nodes.
 
 
-** Cluster
+NOTE: CTIDs < 100 are reserved for internal purposes, and CTIDs need to be
+unique cluster wide.
 
 
-* Fast: minimal overhead, as fast as bare metal
+.Example Container Configuration
+----
+ostype: debian
+arch: amd64
+hostname: www
+memory: 512
+swap: 512
+net0: bridge=vmbr0,hwaddr=66:64:66:64:64:36,ip=dhcp,name=eth0,type=veth
+rootfs: local:107/vm-107-disk-1.raw,size=7G
+----
 
 
-* High density (perfect for idle workloads)
+Those configuration files are simple text files, and you can edit them
+using a normal text editor (`vi`, `nano`, ...). This is sometimes
+useful to do small corrections, but keep in mind that you need to
+restart the container to apply such changes.
 
 
-* REST API
+For that reason, it is usually better to use the `pct` command to
+generate and modify those files, or do the whole thing using the GUI.
+Our toolkit is smart enough to instantaneously apply most changes to
+running containers. This feature is called "hot plug", and there is no
+need to restart the container in that case.
 
 
-* Direct hardware access
 
 
+File Format
+~~~~~~~~~~~
 
 
-Technology Overview
--------------------
+Container configuration files use a simple colon separated key/value
+format. Each line has the following format:
 
 
-- Integrated into {pve} graphical user interface (GUI)
+-----
+# this is a comment
+OPTION: value
+-----
 
 
-- LXC (https://linuxcontainers.org/)
+Blank lines in those files are ignored, and lines starting with a `#`
+character are treated as comments and are also ignored.
 
 
-- cgmanager for cgroup management
+It is possible to add low-level, LXC style configuration directly, for
+example:
 
 
-- lxcfs to provive containerized /proc file system
+ lxc.init_cmd: /sbin/my_own_init
 
 
-- apparmor
+or
 
 
-- CRIU: for live migration (planned)
+ lxc.init_cmd = /sbin/my_own_init
 
 
-- We use latest available kernels (4.4.X)
+Those settings are directly passed to the LXC low-level tools.
 
 
-- Image based deployment (templates)
 
 
-- Container setup from host (Network, DNS, Storage, ...)
+[[pct_snapshots]]
+Snapshots
+~~~~~~~~~
+
+When you create a snapshot, `pct` stores the configuration at snapshot
+time into a separate snapshot section within the same configuration
+file. For example, after creating a snapshot called ``testsnapshot'',
+your configuration file will look like this:
+
+.Container configuration with snapshot
+----
+memory: 512
+swap: 512
+parent: testsnaphot
+...
+
+[testsnaphot]
+memory: 512
+swap: 512
+snaptime: 1457170803
+...
+----
+
+There are a few snapshot related properties like `parent` and
+`snaptime`. The `parent` property is used to store the parent/child
+relationship between snapshots. `snaptime` is the snapshot creation
+time stamp (Unix epoch).
+
+
+[[pct_options]]
+Options
+~~~~~~~
+
+include::pct.conf.5-opts.adoc[]
+
+
+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.
 
 
 ifdef::manvolnum[]
 
 
 ifdef::manvolnum[]
+
+Files
+------
+
+`/etc/pve/lxc/<CTID>.conf`::
+
+Configuration file for the container '<CTID>'.
+
+
 include::pve-copyright.adoc[]
 endif::manvolnum[]
 
 include::pve-copyright.adoc[]
 endif::manvolnum[]