Add storage level.

[pve-docs.git] / pct.adoc

diff --git a/pct.adoc b/pct.adoc
index b5d7c67832f6b36630d8b2a746682d2463920f64..4ca8d7ee6fb8f3af79985f789f8e05d90f65d58d 100644 (file)
--- a/pct.adoc
+++ b/pct.adoc
@@ -2,7 +2,6 @@
 ifdef::manvolnum[]
 pct(1)
 ======
 ifdef::manvolnum[]
 pct(1)
 ======

-include::attributes.txt[]

 :pve-toplevel:
 
 NAME
 :pve-toplevel:
 
 NAME


@@ -23,7 +22,6 @@ endif::manvolnum[]
 ifndef::manvolnum[]
 Proxmox Container Toolkit
 =========================
 ifndef::manvolnum[]
 Proxmox Container Toolkit
 =========================

-include::attributes.txt[]

 :pve-toplevel:
 endif::manvolnum[]
 ifdef::wiki[]
 :pve-toplevel:
 endif::manvolnum[]
 ifdef::wiki[]


@@ -104,32 +102,7 @@ virtualized VMs provide better isolation.
 
 The good news is that LXC uses many kernel security features like
 AppArmor, CGroups and PID and user namespaces, which makes containers
 
 The good news is that LXC uses many kernel security features like
 AppArmor, CGroups and PID and user namespaces, which makes containers

-usage quite secure. We distinguish two types of containers:
-
-
-Privileged Containers
-~~~~~~~~~~~~~~~~~~~~~
-
-Security is done by dropping capabilities, using mandatory access
-control (AppArmor), SecComp filters and namespaces. The LXC team
-considers this kind of container as unsafe, and they will not consider
-new container escape exploits to be security issues worthy of a CVE
-and quick fix. So you should use this kind of containers only inside a
-trusted environment, or when no untrusted task is running as root in
-the container.
-
-
-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
-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
-kernel security bug rather than an LXC issue. The LXC team thinks
-unprivileged containers are safe by design.
-
+usage quite secure.

 
 Guest Operating System Configuration
 ------------------------------------
 
 Guest Operating System Configuration
 ------------------------------------


@@ -347,14 +320,61 @@ ACLs allow you to set more detailed file ownership than the traditional user/
 group/others model.
 
 
 group/others model.
 
 

-[[pct_setting]]
+[[pct_settings]]

 Container Settings
 ------------------
 
 Container Settings
 ------------------
 

+[[pct_general]]
+General Settings
+~~~~~~~~~~~~~~~~
+
+[thumbnail="gui-create-ct-general.png"]
+
+General settings of a container include
+
+* the *Node* : the physical server on which the container will run
+* the *CT ID*: a unique number in this {pve} installation used to identify your container
+* *Hostname*: the hostname of the container
+* *Resource Pool*: a logical group of containers and VMs
+* *Password*: the root password of the container
+* *SSH Public Key*: a public key for connecting to the root account over SSH
+* *Unprivileged container*: this option allows to choose at creation time
+if you want to create a privileged or unprivileged container.
+
+
+Privileged Containers
+^^^^^^^^^^^^^^^^^^^^^
+
+Security is done by dropping capabilities, using mandatory access
+control (AppArmor), SecComp filters and namespaces. The LXC team
+considers this kind of container as unsafe, and they will not consider
+new container escape exploits to be security issues worthy of a CVE
+and quick fix. So you should use this kind of containers only inside a
+trusted environment, or when no untrusted task is running as root in
+the container.
+
+
+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
+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
+kernel security bug rather than an LXC issue. The LXC team thinks
+unprivileged containers are safe by design.
+
+NOTE: If the container uses systemd as an init system, please be
+aware the systemd version running inside the container should be equal
+or greater than 220.
+

 [[pct_cpu]]
 CPU
 ~~~
 
 [[pct_cpu]]
 CPU
 ~~~
 

+[thumbnail="gui-create-ct-cpu.png"]
+

 You can restrict the number of visible CPUs inside the container using
 the `cores` option. This is implemented using the Linux 'cpuset'
 cgroup (**c**ontrol *group*). A special task inside `pvestatd` tries
 You can restrict the number of visible CPUs inside the container using
 the `cores` option. This is implemented using the Linux 'cpuset'
 cgroup (**c**ontrol *group*). A special task inside `pvestatd` tries


@@ -398,6 +418,8 @@ prioritize some containers.
 Memory
 ~~~~~~
 
 Memory
 ~~~~~~
 

+[thumbnail="gui-create-ct-memory.png"]
+

 Container memory is controlled using the cgroup memory controller.
 
 [horizontal]
 Container memory is controlled using the cgroup memory controller.
 
 [horizontal]


@@ -415,6 +437,8 @@ swap`).
 Mount Points
 ~~~~~~~~~~~~
 
 Mount Points
 ~~~~~~~~~~~~
 

+[thumbnail="gui-create-ct-root-disk.png"]
+

 The root mount point is configured with the `rootfs` property, and you can
 configure up to 10 additional mount points. The corresponding options
 are called `mp0` to `mp9`, and they can contain the following setting:
 The root mount point is configured with the `rootfs` property, and you can
 configure up to 10 additional mount points. The corresponding options
 are called `mp0` to `mp9`, and they can contain the following setting:


@@ -494,6 +518,8 @@ NOTE: The contents of device mount points are not backed up when using `vzdump`.
 Network
 ~~~~~~~
 
 Network
 ~~~~~~~
 

+[thumbnail="gui-create-ct-network.png"]
+

 You can configure up to 10 network interfaces for a single
 container. The corresponding options are called `net0` to `net9`, and
 they can contain the following setting:
 You can configure up to 10 network interfaces for a single
 container. The corresponding options are called `net0` to `net9`, and
 they can contain the following setting:


@@ -501,6 +527,43 @@ they can contain the following setting:
 include::pct-network-opts.adoc[]
 
 
 include::pct-network-opts.adoc[]
 
 

+[[pct_startup_and_shutdown]]
+Automatic Start and Shutdown of Containers
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+After creating your containers, you probably want them to start automatically
+when the host system boots. For this you need to select the option 'Start at
+boot' from the 'Options' Tab of your container in the web interface, or set it with
+the following command:
+
+ pct set <ctid> -onboot 1
+
+.Start and Shutdown Order
+// use the screenshot from qemu - its the same
+[thumbnail="gui-qemu-edit-start-order.png"]
+
+If you want to fine tune the boot order of your containers, you can use the following
+parameters :
+
+* *Start/Shutdown order*: Defines the start order priority. E.g. set it to 1 if
+you want the CT to be the first to be started. (We use the reverse startup
+order for shutdown, so a container with a start order of 1 would be the last to
+be shut down)
+* *Startup delay*: Defines the interval between this container start and subsequent
+containers starts . E.g. set it to 240 if you want to wait 240 seconds before starting
+other containers.
+* *Shutdown timeout*: Defines the duration in seconds {pve} should wait
+for the container to be offline after issuing a shutdown command.
+By default this value is set to 60, which means that {pve} will issue a
+shutdown request, wait 60s for the machine to be offline, and if after 60s
+the machine is still online will notify that the shutdown action failed.
+
+Please note that containers without a Start/Shutdown order parameter will always
+start after those where the parameter is set, and this parameter only
+makes sense between the machines running locally on a host, and not
+cluster-wide.
+
+

 Backup and Restore
 ------------------
 
 Backup and Restore
 ------------------
 


@@ -629,6 +692,26 @@ 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`.
 
 attempt with `pct start`, you need to run `pct start` at least once to also
 update the configuration used by `lxc-start`.
 

+[[pct_migration]]
+Migration
+---------
+
+If you have a cluster, you can migrate your Containers with
+
+ pct migrate <vmid> <target>
+
+This works as long as your Container is offline. If it has local volumes or
+mountpoints defined, the migration will copy the content over the network to
+the target host if there is the same storage defined.
+
+If you want to migrate online Containers, the only way is to use
+restart migration. This can be initiated with the -restart flag and the optional
+-timeout parameter.
+
+A restart migration will shut down the Container and kill it after the specified
+timeout (the default is 180 seconds). Then it will migrate the Container
+like an offline migration and when finished, it starts the Container on the
+target node.

 
 [[pct_configuration]]
 Configuration
 
 [[pct_configuration]]
 Configuration