X-Git-Url: https://git.proxmox.com/?p=pve-docs.git;a=blobdiff_plain;f=pct.adoc;h=b55ce1d2c0f828e8031f68175c44be6c8870e4a3;hp=bc6d59733a05ce3e41a111b9850c371983acfdc8;hb=99f6ae1a7fd9ec8bb911deea84614439403bfb02;hpb=083adc34fd184d167931aee00a48f1fd79848d93 diff --git a/pct.adoc b/pct.adoc index bc6d597..b55ce1d 100644 --- a/pct.adoc +++ b/pct.adoc @@ -1,7 +1,9 @@ +[[chapter_pct]] ifdef::manvolnum[] -PVE({manvolnum}) -================ +pct(1) +====== include::attributes.txt[] +:pve-toplevel: NAME ---- @@ -9,7 +11,7 @@ NAME pct - Tool to manage Linux Containers (LXC) on Proxmox VE -SYNOPSYS +SYNOPSIS -------- include::pct.1-synopsis.adoc[] @@ -22,8 +24,11 @@ ifndef::manvolnum[] Proxmox Container Toolkit ========================= include::attributes.txt[] +:pve-toplevel: endif::manvolnum[] - +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 @@ -63,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 ----------------------- @@ -100,96 +131,8 @@ kernel security bug rather than an LXC issue. The LXC team thinks unprivileged containers are safe by design. -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. - - -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 @@ -256,12 +199,7 @@ NOTE: Container start fails if the configured `ostype` differs from the auto detected type. -Options -~~~~~~~ - -include::pct.conf.5-opts.adoc[] - - +[[pct_container_images]] Container Images ---------------- @@ -273,7 +211,7 @@ new container, for example: pct create 999 local:vztmpl/debian-8.0-standard_8.0-1_amd64.tar.gz -Proxmox itself ships a set of basic templates for most common +{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 @@ -328,6 +266,7 @@ example you can delete that image later with: pveam remove local:vztmpl/debian-8.0-standard_8.0-1_amd64.tar.gz +[[pct_container_storage]] Container Storage ----------------- @@ -485,6 +424,7 @@ ACLs allow you to set more detailed file ownership than the traditional user/ group/others model. +[[pct_container_network]] Container Network ----------------- @@ -606,60 +546,144 @@ Reduce the memory of the container to 512MB pct set 100 -memory 512 -Files ------- +Obtaining Debugging Logs +~~~~~~~~~~~~~~~~~~~~~~~~ -`/etc/pve/lxc/.conf`:: +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): -Configuration file for the container ''. + 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. -Container Advantages --------------------- +The collected debug log is written to `/tmp/lxc-ID.log`. -* Simple, and fully integrated into {pve}. Setup looks similar to a normal - VM setup. +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`. -** Storage (ZFS, LVM, NFS, Ceph, ...) -** Network +[[pct_configuration]] +Configuration +------------- -** Authentication +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. -** Cluster +NOTE: CTIDs < 100 are reserved for internal purposes, and CTIDs need to be +unique cluster wide. -* Fast: minimal overhead, as fast as bare metal +.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 +---- -* High density (perfect for idle workloads) +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. -* REST API +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. -* Direct hardware access +File Format +~~~~~~~~~~~ -Technology Overview -------------------- +Container configuration files use a simple colon separated key/value +format. Each line has the following format: -- Integrated into {pve} graphical user interface (GUI) +----- +# this is a comment +OPTION: value +----- -- LXC (https://linuxcontainers.org/) +Blank lines in those files are ignored, and lines starting with a `#` +character are treated as comments and are also ignored. -- cgmanager for cgroup management +It is possible to add low-level, LXC style configuration directly, for +example: -- lxcfs to provive containerized /proc file system + lxc.init_cmd: /sbin/my_own_init -- apparmor +or -- CRIU: for live migration (planned) + lxc.init_cmd = /sbin/my_own_init -- We use latest available kernels (4.4.X) +Those settings are directly passed to the LXC low-level tools. -- Image based deployment (templates) -- Container setup from host (Network, DNS, Storage, ...) +[[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). + + +[[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[] + +Files +------ + +`/etc/pve/lxc/.conf`:: + +Configuration file for the container ''. + + include::pve-copyright.adoc[] endif::manvolnum[]