X-Git-Url: https://git.proxmox.com/?p=pve-docs.git;a=blobdiff_plain;f=pct.adoc;h=7a5e9b705bb6d2ec43c1613f896275bc1fc42ef8;hp=205d5f5adea14ca62ac78e8d7ab525695754b7a4;hb=4f785ca73bb3f0d15e98ee465126ae418d524a14;hpb=3bd9d0cfd637873207e1c28d530caca0ff0d9d42 diff --git a/pct.adoc b/pct.adoc index 205d5f5..7a5e9b7 100644 --- 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. +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 ----------------------- @@ -105,98 +131,8 @@ 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/.conf` file stores container configuration, -where `` 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 -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +------------------------------------ We normally try to detect the operating system type inside the container, and then modify some files inside the container to make @@ -263,13 +199,6 @@ NOTE: Container start fails if the configured `ostype` differs from the auto detected type. -[[pct_options]] -Options -~~~~~~~ - -include::pct.conf.5-opts.adoc[] - - [[pct_container_images]] Container Images ---------------- @@ -353,7 +282,8 @@ 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. +application. See section <> 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 @@ -369,6 +299,60 @@ local storage inside containers with zero overhead. Such bind mounts also provide an easy way to share data between different containers. +FUSE Mounts +~~~~~~~~~~~ + +WARNING: Because of existing issues in the Linux kernel's freezer +subsystem the usage of FUSE mounts inside a container is strongly +advised against, as containers need to be frozen for suspend or +snapshot mode backups. + +If FUSE mounts cannot be replaced by other mounting mechanisms or storage +technologies, it is possible to establish the FUSE mount on the Proxmox host +and use a bind mount point to make it accessible inside the container. + + +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. + +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 +can initialize the `/aquota.user` and `/aquota.group` files by running + +---- +quotacheck -cmug / +quotaon / +---- + +and edit the quotas via the `edquota` command. Refer to the documentation +of the distribution running inside the container for details. + +NOTE: You need to run the above commands for every mount point by passing +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. + + +[[pct_setting]] +Container Settings +------------------ + + +[[pct_mount_points]] Mount Points ~~~~~~~~~~~~ @@ -447,57 +431,9 @@ more features. NOTE: The contents of device mount points are not backed up when using `vzdump`. -FUSE Mounts -~~~~~~~~~~~ - -WARNING: Because of existing issues in the Linux kernel's freezer -subsystem the usage of FUSE mounts inside a container is strongly -advised against, as containers need to be frozen for suspend or -snapshot mode backups. - -If FUSE mounts cannot be replaced by other mounting mechanisms or storage -technologies, it is possible to establish the FUSE mount on the Proxmox host -and use a bind mount point to make it accessible inside the container. - - -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. - -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 -can initialize the `/aquota.user` and `/aquota.group` files by running - ----- -quotacheck -cmug / -quotaon / ----- - -and edit the quotas via the `edquota` command. Refer to the documentation -of the distribution running inside the container for details. - -NOTE: You need to run the above commands for every mount point by passing -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. - - [[pct_container_network]] Container Network ------------------ +~~~~~~~~~~~~~~~~~ You can configure up to 10 network interfaces for a single container. The corresponding options are called `net0` to `net9`, and @@ -635,47 +571,114 @@ attempt with `pct start`, you need to run `pct start` at least once to also update the configuration used by `lxc-start`. -Container Advantages --------------------- +[[pct_configuration]] +Configuration +------------- + +The `/etc/pve/lxc/.conf` file stores container configuration, +where `` 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. -* Simple, and fully integrated into {pve}. Setup looks similar to a normal - VM setup. +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. -** Storage (ZFS, LVM, NFS, Ceph, ...) -** Network +File Format +~~~~~~~~~~~ -** Authentication +Container configuration files use a simple colon separated key/value +format. Each line has the following format: -** Cluster +----- +# this is a comment +OPTION: value +----- -* Fast: minimal overhead, as fast as bare metal +Blank lines in those files are ignored, and lines starting with a `#` +character are treated as comments and are also ignored. -* High density (perfect for idle workloads) +It is possible to add low-level, LXC style configuration directly, for +example: -* REST API + lxc.init_cmd: /sbin/my_own_init -* Direct hardware access +or + lxc.init_cmd = /sbin/my_own_init -Technology Overview -------------------- +Those settings are directly passed to the LXC low-level tools. -* Integrated into {pve} graphical user interface (GUI) -* LXC (https://linuxcontainers.org/) +[[pct_snapshots]] +Snapshots +~~~~~~~~~ -* lxcfs to provide containerized /proc file system +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: -* AppArmor +.Container configuration with snapshot +---- +memory: 512 +swap: 512 +parent: testsnaphot +... -* CRIU: for live migration (planned) +[testsnaphot] +memory: 512 +swap: 512 +snaptime: 1457170803 +... +---- -* We use latest available kernels (4.4.X) +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). -* Image based deployment (templates) -* Container setup from host (network, DNS, storage, ...) +[[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 + +CAUTION: Only do that if you are sure the action which set the lock is +no longer running. ifdef::manvolnum[]