[pve-devel] [PATCH docs] rewrite and improve pct documentation
Oguz Bektas
o.bektas at proxmox.com
Thu Dec 12 18:12:07 CET 2019
* 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.
+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.
+
+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:
+
+* Only Linux distributions can be run in containers, i.e. it is not
possible to run FreeBSD or MS Windows inside.
* For security reasons, access to host resources needs to be
restricted. This is done with AppArmor, SecComp filters and other
- kernel features. Be prepared that some syscalls are not allowed
- inside containers.
+ kernel features. Hence, some syscalls are not allowed in containers.
{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. 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 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
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
* Image based deployment (templates)
* Use {pve} storage library
-* 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
-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
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
-usage quite secure.
+However, LXC uses many security features like AppArmor, CGroups and kernel
+namespaces in order to reduce attack surface.
+
+AppArmor profiles are used to restrict access to possibly dangerous actions.
+Some system calls, i.e. `mount`, are prohibited to execute.
+
+To trace AppArmor activity, use:
+
+----
+# dmesg | grep apparmor
+----
+
+WARNING: Although it is not recommended, AppArmor can be disabled for
+a container. 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
+
+----
+lxc.apparmor_profile = unconfined
+----
+
+to the container configuration file in `/etc/pve/lxc/CTID.conf`.
+
+Please note that this is not a recommended setup for production use.
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
+modifies some files. Here is a short list of things done at the
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:
- 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
+`pveam` (short for {pve} Appliance Manager) command line utility.
+Aside from that, https://www.turnkeylinux.org/[TurnKey Linux]
+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:
- pveam update
+----
+# pveam update
+----
-After that you can view the list of available images using:
+You can view the list of available images using:
- 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.
+
+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.
+
+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.
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.
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*
+option for that mount point. +
As of {pve} 5.0, replication requires a storage of type `zfspool`, so adding a
- 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.
[[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
+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
or greater than 220.
+
+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.
+
[[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
+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
+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
-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:
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.
.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:
- 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
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
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.
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
+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
+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.
@@ -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.
--
2.20.1
More information about the pve-devel
mailing list