]> git.proxmox.com Git - pve-docs.git/blobdiff - pct.adoc
pct.adoc: move section Technology to the top
[pve-docs.git] / pct.adoc
index e2b36870d158cea6ee3668387428301c96908157..b55ce1d2c0f828e8031f68175c44be6c8870e4a3 100644 (file)
--- a/pct.adoc
+++ b/pct.adoc
@@ -68,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
 -----------------------
 
@@ -104,98 +130,9 @@ will affect a random unprivileged user, and so would be a generic
 kernel security bug rather than an LXC issue. The LXC team thinks
 unprivileged containers are safe by design.
 
 kernel security bug rather than an LXC issue. The LXC team thinks
 unprivileged containers are safe by design.
 
-[[pct_configuration]]
-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.
-
-
-[[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).
-
 
 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
@@ -262,13 +199,6 @@ NOTE: Container start fails if the configured `ostype` differs from the auto
 detected type.
 
 
 detected type.
 
 
-[[pct_options]]
-Options
-~~~~~~~
-
-include::pct.conf.5-opts.adoc[]
-
-
 [[pct_container_images]]
 Container Images
 ----------------
 [[pct_container_images]]
 Container Images
 ----------------
@@ -634,58 +564,126 @@ attempt with `pct start`, you need to run `pct start` at least once to also
 update the configuration used by `lxc-start`.
 
 
 update the configuration used by `lxc-start`.
 
 
-Files
-------
+[[pct_configuration]]
+Configuration
+-------------
 
 
-`/etc/pve/lxc/<CTID>.conf`::
+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.
 
 
-Configuration file for the container '<CTID>'.
+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
+-----
 
 
-Container Advantages
---------------------
+Blank lines in those files are ignored, and lines starting with a `#`
+character are treated as comments and are also ignored.
 
 
-* Simple, and fully integrated into {pve}. Setup looks similar to a normal
-  VM setup. 
+It is possible to add low-level, LXC style configuration directly, for
+example:
 
 
-** Storage (ZFS, LVM, NFS, Ceph, ...)
+ lxc.init_cmd: /sbin/my_own_init
 
 
-** Network
+or
 
 
-** Authentication
+ lxc.init_cmd = /sbin/my_own_init
 
 
-** Cluster
+Those settings are directly passed to the LXC low-level tools.
 
 
-* Fast: minimal overhead, as fast as bare metal
 
 
-* High density (perfect for idle workloads)
+[[pct_snapshots]]
+Snapshots
+~~~~~~~~~
 
 
-* REST API
+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:
 
 
-* Direct hardware access
+.Container configuration with snapshot
+----
+memory: 512
+swap: 512
+parent: testsnaphot
+...
 
 
+[testsnaphot]
+memory: 512
+swap: 512
+snaptime: 1457170803
+...
+----
 
 
-Technology Overview
--------------------
+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).
 
 
-* Integrated into {pve} graphical user interface (GUI)
 
 
-* LXC (https://linuxcontainers.org/)
+[[pct_options]]
+Options
+~~~~~~~
 
 
-* lxcfs to provide containerized /proc file system
+include::pct.conf.5-opts.adoc[]
 
 
-* AppArmor
 
 
-* CRIU: for live migration (planned)
+Locks
+-----
 
 
-* We use latest available kernels (4.4.X)
+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).
 
 
-* Image based deployment (templates)
+ pct unlock <CTID>
 
 
-* Container setup from host (network, DNS, storage, ...)
+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[]