[pve-devel] [PATCH docs] rewrite and improve pct documentation

[Aaron Lauterer]

Comments and possible changes inline.

If a paragraph is rewritten, it is done so below the paragraph.

On 12/12/19 6:12 PM, Oguz Bektas wrote:
> * rephrase some parts.
> * update old information
> * add info about pending changes and other "new" features
> 
> Signed-off-by: Oguz Bektas <o.bektas at proxmox.com>
> ---
>   pct.adoc | 411 ++++++++++++++++++++++++++++++++-----------------------
>   1 file changed, 243 insertions(+), 168 deletions(-)
> 
> diff --git a/pct.adoc b/pct.adoc
> index 2f1d329..cd9d9e1 100644
> --- a/pct.adoc
> +++ b/pct.adoc
> @@ -28,32 +28,30 @@ 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
> -simply use the OS of the host they run on. This implies that all
> -containers use the same kernel, and that they can access resources
> -from the host directly.
> -
> -This is great because containers do not waste CPU power nor memory due
> -to kernel emulation. Container run-time costs are close to zero and
> -usually negligible. But there are also some drawbacks you need to
> -consider:
> -
> -* You can only run Linux based OS inside containers, i.e. it is not
> +Containers are a lightweight alternative to fully virtualized VMs.

Starting here, suggestion below this paragraph:
> +Instead of emulating a full Operating System (OS), containers use the
> +kernel of the host they run on. This implies that all containers use
> +the same kernel, and that they can access resources from the host
> +directly.
They use the kernel of the host system that they run on instead of 
emulating a full operating system (OS). This means that containers can 
access resources on the host system directly.


> +
> +Since there is no need for kernel emulation, containers have a significant
> +advantage over virtual machines in terms of CPU and memory overhead. The
> +runtime costs are therefore very low, and usually negligible. However, there
> +are some drawbacks to be considered:
The runtime cost for containers is low, usually negligible, because of 
the low overhead in terms of CPU and memory resources. However, there 
are some drawbacks that need to be considered:

> +
> +* Only Linux distributions can be run in containers, i.e. it is not
s/, i.e. it/. It/
>     possible to run FreeBSD or MS Windows inside.
s/inside/inside a container/
>   
>   * For security reasons, access to host resources needs to be
>     restricted. This is done with AppArmor, SecComp filters and other
s/filters/filters,/ (oxford comma)
> -  kernel features. Be prepared that some syscalls are not allowed
> -  inside containers.
> +  kernel features. Hence, some syscalls are not allowed in containers.
s/Hence, some/Some/
s/in/within/
(Move this sentence before the AppArmor sentence?)

>   
>   {pve} uses https://linuxcontainers.org/[LXC] as underlying container
> -technology. We consider LXC as low-level library, which provides
> -countless options. It would be too difficult to use those tools
> -directly. Instead, we provide a small wrapper called `pct`, the
> -"Proxmox Container Toolkit".
> +technology. 

Starting here, suggestion below paragraph:
> +We consider LXC as low-level library, which provides countless
> +options. To make usage easier, we provide a wrapper called `pct`, the "Proxmox
> +Container Toolkit".
The "Proxmox Container Toolkit" (`pct`) simplifies the usage of LXC 
containers.

>   
> -The toolkit is tightly coupled with {pve}. That means that it is aware
> +The toolkit is tightly coupled with {pve}. This means that it is aware
s/The toolkit/The `pct`/

>   of the cluster setup, and it can use the same network and storage
>   resources as fully virtualized VMs. You can even use the {pve}
>   firewall, or manage containers using the HA framework.
> @@ -62,7 +60,7 @@ Our primary goal is to offer an environment as one would get from a
>   VM, but without the additional overhead. We call this "System
>   Containers".
>   
> -NOTE: If you want to run micro-containers (with docker, rkt, ...), it
> +NOTE: If you want to run micro-containers (with docker, rkt, etc.) it
>   is best to run them inside a VM.
>   
>   
> @@ -79,37 +77,59 @@ Technology Overview
>   
>   * lxcfs to provide containerized /proc file system
>   
> -* AppArmor/Seccomp to improve security
> +* CGroups (control groups) for resource allocation
>   
> -* CRIU: for live migration (planned)
> +* AppArmor/Seccomp to improve security
>   
> -* Runs on modern Linux kernels
> +* Modern Linux kernels
(not sure if we want this new way or want this point at all?)
>   
>   * Image based deployment (templates)
>   
>   * Use {pve} storage library
s/Use/Uses/
>   
> -* Container setup from host (network, DNS, storage, ...)
> +* Container setup from host (network, DNS, storage, etc.)
>   
>   
>   Security Considerations
>   -----------------------
>   
>   Containers use the same kernel as the host, so there is a big attack
Containers use the kernel of the host system. This creates a big attack

> -surface for malicious users. You should consider this fact if you
> -provide containers to totally untrusted people. In general, fully
> +surface for malicious users. This should be considered if containers
> +are provided to totally untrusted people. In general, fully
s/totally untrusted/not trustworthy/

>   virtualized VMs provide better isolation.
Full virtual mchines provide a better isolation.
>   
> -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.
> +However, LXC uses many security features like AppArmor, CGroups and kernel
> +namespaces in order to reduce attack surface.
s/in order//
s/reduce attack/reduce the attack/

> +
> +AppArmor profiles are used to restrict access to possibly dangerous actions.
s/AppArmor/The AppArmor/

> +Some system calls, i.e. `mount`, are prohibited to execute.
s/i.e./for example/
s/to execute/from execution/

> +
> +To trace AppArmor activity, use:
> +
> +----
> +# dmesg | grep apparmor
> +----
> +
> +WARNING: Although it is not recommended, AppArmor can be disabled for
> +a container.

Suggestion below paragraph:
> +This brings some security risks, for example being able
> +to execute some syscalls in containers can lead to privilege
> +escalation in some cases if the system is misconfigured or in case
> +of an upstream LXC or Linux Kernel vulnerability. To disable AppArmor
> +for a container, one can add
This brings security risks with it. Some syscalls can lead to a 
privilege escalation when executed within a container if the system is 
misconfigured or if a LXC or Linux Kernel vulnerability exists.

To disable AppArmor for a container add the following line to the 
container configuration file located at `/etc/pve/lxc/CDID.conf`:
> +
> +----
> +lxc.apparmor_profile = unconfined
> +----
> +
> +to the container configuration file in `/etc/pve/lxc/CTID.conf`.
(remove the above line)

> +
> +Please note that this is not a recommended setup for production use.
s/a recommended setup/recommended
>   
>   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
> +{pve} normally tries to detect the Linux distribution in the container, and
s/normally//

> +modifies some files. Here is a short list of things done at the
s/at the/at/

>   container startup:
>   
>   set /etc/hostname:: to set the container name
> @@ -145,7 +165,9 @@ 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 created via:
>   
> - # touch /etc/.pve-ignore.hosts
> +----
> +# touch /etc/.pve-ignore.hosts
> +----
>   
>   Most modifications are OS dependent, so they differ between different
>   distributions and versions. You can completely disable modifications
> @@ -178,27 +200,29 @@ Container Images
>   
>   Container images, sometimes also referred to as ``templates'' or
>   ``appliances'', are `tar` archives which contain everything to run a
> -container. You can think of it as a tidy container backup. Like most
> -modern container toolkits, `pct` uses those images when you create a
> -new container, for example:
> +container. `pct` uses them when creating a new container, for example:
s/when creating/to create/
>   
> - pct create 999 local:vztmpl/debian-8.0-standard_8.0-1_amd64.tar.gz
> +----
> +# pct create 999 local:vztmpl/debian-10.0-standard_10.0-1_amd64.tar.gz
> +----
>   
> -{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
> -that tool (or the graphical user interface).
> +{pve} itself provides a variety of basic templates for the most common
> +Linux distributions, and they can be downloaded using the GUI or the
s/, and they/. They/

> +`pveam` (short for {pve} Appliance Manager) command line utility.
> +Aside from that, https://www.turnkeylinux.org/[TurnKey Linux]
s/Aside from that,/Additionally,/
> +container templates are also available to download.
>   
> -Our image repositories contain a list of available images, and there
> -is a cron job run each day to download that list. You can trigger that
> -update manually with:
> +List of available templates are updated daily via cron. To trigger it manually:
s/List/The list/
s/are/is/
>   
> - pveam update
> +----
> +# pveam update
> +----
>   
> -After that you can view the list of available images using:
> +You can view the list of available images using:
To view the list of available images run:
>   
> - pveam available
> +----
> +# pveam available
> +----
>   
>   You can restrict this large list by specifying the `section` you are
>   interested in, for example basic `system` images:
> @@ -206,15 +230,24 @@ interested in, for example basic `system` images:
>   .List available system images
>   ----
>   # pveam available --section system
> -system          archlinux-base_2015-24-29-1_x86_64.tar.gz
> -system          centos-7-default_20160205_amd64.tar.xz
> -system          debian-6.0-standard_6.0-7_amd64.tar.gz
> -system          debian-7.0-standard_7.0-3_amd64.tar.gz
> -system          debian-8.0-standard_8.0-1_amd64.tar.gz
> -system          ubuntu-12.04-standard_12.04-1_amd64.tar.gz
> -system          ubuntu-14.04-standard_14.04-1_amd64.tar.gz
> -system          ubuntu-15.04-standard_15.04-1_amd64.tar.gz
> -system          ubuntu-15.10-standard_15.10-1_amd64.tar.gz
> +system          alpine-3.10-default_20190626_amd64.tar.xz
> +system          alpine-3.9-default_20190224_amd64.tar.xz
> +system          archlinux-base_20190924-1_amd64.tar.gz
> +system          centos-6-default_20191016_amd64.tar.xz
> +system          centos-7-default_20190926_amd64.tar.xz
> +system          centos-8-default_20191016_amd64.tar.xz
> +system          debian-10.0-standard_10.0-1_amd64.tar.gz
> +system          debian-8.0-standard_8.11-1_amd64.tar.gz
> +system          debian-9.0-standard_9.7-1_amd64.tar.gz
> +system          fedora-30-default_20190718_amd64.tar.xz
> +system          fedora-31-default_20191029_amd64.tar.xz
> +system          gentoo-current-default_20190718_amd64.tar.xz
> +system          opensuse-15.0-default_20180907_amd64.tar.xz
> +system          opensuse-15.1-default_20190719_amd64.tar.xz
> +system          ubuntu-16.04-standard_16.04.5-1_amd64.tar.gz
> +system          ubuntu-18.04-standard_18.04.1-1_amd64.tar.gz
> +system          ubuntu-19.04-standard_19.04-1_amd64.tar.gz
> +system          ubuntu-19.10-standard_19.10-1_amd64.tar.gz
>   ----
>   
>   Before you can use such a template, you need to download them into one
> @@ -222,54 +255,48 @@ of your storages. You can simply use storage `local` for that
>   purpose. For clustered installations, it is preferred to use a shared
>   storage so that all nodes can access those images.
>   
> - pveam download local debian-8.0-standard_8.0-1_amd64.tar.gz
> +----
> +# pveam download local debian-10.0-standard_10.0-1_amd64.tar.gz
> +----
>   
>   You are now ready to create containers using that image, and you can
>   list all downloaded images on storage `local` with:
>   
>   ----
>   # pveam list local
> -local:vztmpl/debian-8.0-standard_8.0-1_amd64.tar.gz  190.20MB
> +local:vztmpl/debian-10.0-standard_10.0-1_amd64.tar.gz  219.95MB
>   ----
>   
>   The above command shows you the full {pve} volume identifiers. They include
>   the storage name, and most other {pve} commands can use them. For
>   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-10.0-standard_10.0-1_amd64.tar.gz
> +----
>   
>   [[pct_container_storage]]
>   Container Storage
>   -----------------
>   
> -Traditional containers use a very simple storage model, only allowing
> -a single mount point, the root file system. This was further
> -restricted to specific file system types like `ext4` and `nfs`.
> -Additional mounts are often done by user provided scripts. This turned
> -out to be complex and error prone, so we try to avoid that now.
> -
> -Our new LXC based container model is more flexible regarding
> -storage. First, you can have more than a single mount point. This
> -allows you to choose a suitable storage for each application. For
> -example, you can use a relatively slow (and thus cheap) storage for
> -the container root file system. Then you can use a second mount point
> -to mount a very fast, distributed storage for your database
> -application. See section <<pct_mount_points,Mount Points>> for further
> -details.
> -
> -The second big improvement is that you can use any storage type
> -supported by the {pve} storage library. That means that you can store
> -your containers on local `lvmthin` or `zfs`, shared `iSCSI` storage,
> -or even on distributed storage systems like `ceph`. It also enables us
> -to use advanced storage features like snapshots and clones. `vzdump`
> -can also use the snapshot feature to provide consistent container
> -backups.
> -
> -Last but not least, you can also mount local devices directly, or
> -mount local directories using bind mounts. That way you can access
> -local storage inside containers with zero overhead. Such bind mounts
> -also provide an easy way to share data between different containers.
> +Compared to other container models, our LXC based container model is more
> +flexible regarding storage. You can have many mount points.  which allows you > +to choose a suitable storage for each application. For example, you 
can use a
> +relatively slow (and thus cheap) storage for the container root file system.
> +Then you can use a second mount point to mount a very fast, distributed storage
> +for your database application. See section <<pct_mount_points,Mount Points>>
> +for further details.

The {pve} LXC container storage model is more flexible than traditional 
container storage models. A container can have multiple mount points. 
This makes it possible to use the best suited storage for each application.

For example the root file system of the container can be on slow and 
cheap storage while the database can be on fast and distributed storage 
via a second mount point. See section <<pct_mount_points,Mount Points>> 
for further details.

> +
> +You can also use any storage type supported by the {pve} storage library. That
> +means you can store your containers on local `lvmthin` or `zfs`, shared `iSCSI`
> +storage, or even on distributed storage systems like `ceph`. It also enables us
> +to use advanced storage features like snapshots and clones. `vzdump` can also
> +use the snapshot feature to provide consistent container backups.

Any storage type supported by the {pve} storage library can be used. 
This means that containers can be stored on local (for example `lvm`, 
`zfs` or directory), shared external (like `iSCSI`, `NFS`) or even 
distributed storage systems like Ceph. Advanced storage features like 
snapshots or clones can be used if the underlying storage supports them. 
The `vzdump` backup tool can use snapshots to provide consistent 
container backups.

> +
> +Furthermore, you can mount local devices directly, or mount local directories
> +using bind mounts. That way you can access local storage inside containers with
> +zero overhead. Such bind mounts also provide an easy way to share data between
> +different containers.
Furthermore local devices or local directories can be mounted directly 
using 'bind mounts'. This gives access to local resources inside a 
container with practically zero overhead. Bind mounts can be used as an 
easy way to share data between containers.

>   
>   
>   FUSE Mounts
> @@ -289,20 +316,21 @@ Using Quotas Inside Containers
>   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>   
>   Quotas allow to set limits inside a container for the amount of disk
> -space that each user can use.  This only works on ext4 image based
> -storage types and currently does not work with unprivileged
> -containers.
> +space that each user can use.
> +
> +NOTE: This only works on ext4 image based storage types and currently does not
> +work with unprivileged containers.
... and currently only works with privileged containers.

(trying to avoid kind of double negation?)

>   
>   Activating the `quota` option causes the following mount options to be
>   used for a mount point:
>   `usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0`
>   
> -This allows quotas to be used like you would on any other system. You
> +This allows quotas to be used like on any other system. You
>   can initialize the `/aquota.user` and `/aquota.group` files by running
>   
>   ----
> -quotacheck -cmug /
> -quotaon /
> +# quotacheck -cmug /
> +# quotaon /
>   ----
>   
>   and edit the quotas via the `edquota` command. Refer to the documentation
> @@ -315,29 +343,43 @@ the mount point's path instead of just `/`.
>   Using ACLs 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.
> +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.
>   
>   
> -Backup of Containers mount points
> +Backup of Container mount points
>   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>   
> -By default additional mount points besides the Root Disk mount point are not
> -included in backups. You can reverse this default behavior by setting the
> -*Backup* option on a mount point.
> -// see PVE::VZDump::LXC::prepare()
> +To include a mount point in backups, enable the `backup` option for it in the
> +container configuration. For an existing mount point `mp0`
> +
> +----
> +mp0: guests:subvol-100-disk-1,mp=/root/files,size=8G
> +----
> +
> +add `backup=1` to enable it.
> +
> +----
> +mp0: guests:subvol-100-disk-1,mp=/root/files,size=8G,backup=1
> +----
> +
> +NOTE: When creating a new mount point in the GUI, this option is enabled by
> +default.
> +
> +To disable backups for a mount point, add `backup=0` in the way described above,
> +or uncheck the *Backup* checkbox on the GUI.
>   
>   Replication of Containers mount points
>   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>   
> -By default additional mount points are replicated when the Root Disk
> -is replicated. If you want the {pve} storage replication mechanism to skip a
> - mount point when starting  a replication job, you can set the
> -*Skip replication* option on that mount point. +
> +By default, additional mount points are replicated when the Root Disk is
> +replicated. If you want the {pve} storage replication mechanism to skip a mount
> +point when starting a replication job, you can set the *Skip replication*
s/when starting a replication job//

> +option for that mount point. +
>   As of {pve} 5.0, replication requires a storage of type `zfspool`, so adding a
s/, so adding/. Adding

> - mount point to a different type of storage when the container has replication
> - configured requires to *Skip replication* for that mount point.
> +mount point to a different type of storage when the container has replication
> +configured requires to *Skip replication* for that mount point.
s/to *Skip replication*/to have *Skip replication* enabled/
>   
>   
>   [[pct_settings]]
> @@ -361,45 +403,44 @@ General settings of a container include
>   * *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.
> +Unprivileged 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, etc.) in those containers will affect a random unprivileged user, and so
s/those/these/
s/and so/and/

> +would be a generic kernel security bug rather than an LXC issue. The LXC team
> +thinks unprivileged containers are safe by design.
> +
> +This is the default option when creating a new container.
>   
>   NOTE: If the container uses systemd as an init system, please be
>   aware the systemd version running inside the container should be equal
s/equal/equal to/
>   or greater than 220 >
> +
> +Privileged Containers
> +^^^^^^^^^^^^^^^^^^^^^
> +
> +Security is done by dropping capabilities, using mandatory access control
s/Security is done/Security in LXC containers is achieved/
> +(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. 
this part is rewritten below:
> 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.
That's why privileged containers should only be used in trusted 
environments.
> +
>   [[pct_cpu]]
>   CPU
>   ~~~
>   
>   [thumbnail="screenshot/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
> -to distribute running containers among available CPUs. You can view
> -the assigned CPUs using the following command:
> +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 to distribute
> +running containers among available CPUs. You can view the assigned CPUs using
s/You can view the assigned CPUs using/To view the assigned CPUs run/
> +the following command:

>   
>   ----
>   # pct cpusets
> @@ -410,10 +451,10 @@ the assigned CPUs using the following command:
>    ---------------------
>   ----
>   
> -Containers use the host kernel directly, so all task inside a
> -container are handled by the host CPU scheduler. {pve} uses the Linux
> -'CFS' (**C**ompletely **F**air **S**cheduler) scheduler by default,
> -which has additional bandwidth control options.
> +Containers use the host kernel directly, so all tasks inside a container are
s/, so all/. All/
> +handled by the host CPU scheduler. {pve} uses the Linux 'CFS' (**C**ompletely
> +**F**air **S**cheduler) scheduler by default, which has additional bandwidth
> +control options.
>   
>   [horizontal]
>   
> @@ -460,12 +501,12 @@ Mount Points
>   [thumbnail="screenshot/gui-create-ct-root-disk.png"]
>   
>   The root mount point is configured with the `rootfs` property, and you can
s/, and you/. You
> -configure up to 10 additional mount points. The corresponding options
> -are called `mp0` to `mp9`, and they can contain the following setting:
> +configure up to 256 additional mount points. The corresponding options
> +are called `mp0` to `mp255`, and they can contain the following settings:
s/, and they/. They/
>   
>   include::pct-mountpoint-opts.adoc[]
>   
> -Currently there are basically three types of mount points: storage backed
> +Currently there are three types of mount points: storage backed
>   mount points, bind mounts and device mounts.
s/mounts and/mounts, and/ (oxford comma)
>   
>   .Typical container `rootfs` configuration
> @@ -558,26 +599,28 @@ include::pct-network-opts.adoc[]
>   Automatic Start and Shutdown of Containers
>   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>   
> -After creating your containers, you probably want them to start automatically
> +After creating your containers, you might 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:
To automatically start a container when the host system boots select the 
options 'Start at boot' in the 'Options' panel of the container in the 
web interface or run the following command:
>   
> - pct set <ctid> -onboot 1
> +----
> +# pct set CTID -onboot 1
> +----
>   
>   .Start and Shutdown Order
>   // use the screenshot from qemu - its the same
>   [thumbnail="screenshot/gui-qemu-edit-start-order.png"]
>   
>   If you want to fine tune the boot order of your containers, you can use the following
> -parameters :
> +parameters:
>   
>   * *Start/Shutdown order*: Defines the start order priority. E.g. set it to 1 if
s/E.g./For example,/
>   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
> +containers starts. E.g. set it to 240 if you want to wait 240 seconds before starting
s/E.g./For example,/
>   other containers.
>   * *Shutdown timeout*: Defines the duration in seconds {pve} should wait
>   for the container to be offline after issuing a shutdown command.
> @@ -595,7 +638,9 @@ Hookscripts
>   
>   You can add a hook script to CTs with the config property `hookscript`.
>   
> - pct set 100 -hookscript local:snippets/hookscript.pl
> +----
> +# pct set 100 -hookscript local:snippets/hookscript.pl
> +----
>   
>   It will be called during various phases of the guests lifetime.
>   For an example and documentation see the example script under
> @@ -672,10 +717,10 @@ individually
>   Managing Containers with `pct`
>   ------------------------------
>   
> -`pct` is the tool to manage Linux Containers on {pve}. You can create
> -and destroy containers, and control execution (start, stop, migrate,
> -...). You can use pct to set parameters in the associated config file,
> -like network configuration or memory limits.
> +`pct` is the tool to manage {pve} containers. You can create and
> +destroy containers, and control execution (start, stop, reboot,
> +migrate, etc.) You can use pct to set parameters in the associated
> +config file, like network configuration or memory limits.
The "Proxmox Container Toolkit" (`pct`) is the CLI tool to manage {pve} 
containers. It enables you to create and destroy containers as well as 
control the container execution (start, stop, reboot, migrate, etc.). It 
can be used to set parameters in the config file of a container like the 
network configuration or memory limits.
>   
>   
>   CLI Usage Examples
> @@ -684,32 +729,46 @@ CLI Usage Examples
>   Create a container based on a Debian template (provided you have
>   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 create 100 /var/lib/vz/template/cache/debian-10.0-standard_10.0-1_amd64.tar.gz
> +----
>   
>   Start container 100
>   
> - pct start 100
> +----
> +# pct start 100
> +----
>   
>   Start a login session via getty
>   
> - pct console 100
> +----
> +# pct console 100
> +----
>   
>   Enter the LXC namespace and run a shell as root user
>   
> - pct enter 100
> +----
> +# pct enter 100
> +----
>   
>   Display the configuration
>   
> - pct config 100
> +----
> +# pct config 100
> +----
>   
>   Add a network interface called `eth0`, bridged to the host bridge `vmbr0`,
>   set the address and gateway, while it's running
>   
> - pct set 100 -net0 name=eth0,bridge=vmbr0,ip=192.168.15.147/24,gw=192.168.15.1
> +----
> +# pct set 100 -net0 name=eth0,bridge=vmbr0,ip=192.168.15.147/24,gw=192.168.15.1
> +----
>   
>   Reduce the memory of the container to 512MB
>   
> - pct set 100 -memory 512
> +----
> +# pct set 100 -memory 512
> +----
>   
>   
>   Obtaining Debugging Logs
> @@ -719,9 +778,13 @@ 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):
>   
> - lxc-start -n ID -F -l DEBUG -o /tmp/lxc-ID.log
> +----
> +# 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.
> +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`.
>   
> @@ -735,10 +798,12 @@ Migration
>   
>   If you have a cluster, you can migrate your Containers with
>   
> - pct migrate <vmid> <target>
> +----
> +# pct migrate <ctid> <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
> +mount points defined, the migration will copy the content over the network to
>   the target host if the same storage is defined there.
>   
>   If you want to migrate online Containers, the only way is to use
> @@ -773,8 +838,8 @@ 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
> +Those configuration files are simple text files, so you can edit them
/s/Those/The/
s/files, so you/files. You/
> +using a normal text editor (`vi`, `nano`, etc). This is sometimes
>   useful to do small corrections, but keep in mind that you need to
>   restart the container to apply such changes.
>   
> @@ -784,12 +849,16 @@ 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.
>   
> +In cases where a change cannot be hot plugged, it will be registered
> +as a pending change (shown with red color in the GUI). These will only
s/with red/in red/
s/These will only/They will/

> +be applied after rebooting the container.
> +
>   
>   File Format
>   ~~~~~~~~~~~
>   
> -Container configuration files use a simple colon separated key/value
> -format. Each line has the following format:
> +The container configuration file uses a simple colon separated
> +key/value format. Each line has the following format:
>   
>   -----
>   # this is a comment
> @@ -802,11 +871,15 @@ 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
> +----
> +lxc.init_cmd: /sbin/my_own_init
> +----
>   
>   or
>   
> - lxc.init_cmd = /sbin/my_own_init
> +----
> +lxc.init_cmd = /sbin/my_own_init
> +----
>   
>   Those settings are directly passed to the LXC low-level tools.
s/Those/These/
or maybe
s/Those/The/
>   
> @@ -854,9 +927,11 @@ 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>
> +----
> +# pct unlock <CTID>
> +----
>   
> -CAUTION: Only do that if you are sure the action which set the lock is
> +CAUTION: Only do this if you are sure the action which set the lock is
>   no longer running.
>   
>   
>