hi, any update here?
On Tue, Jan 14, 2020 at 05:47:01PM +0100, Oguz Bektas wrote: > * rephrase some parts. > * update old information > * add info about pending changes and other "new" features > > Co-Authored-by: Aaron Lauterer <a.laute...@proxmox.com> > Signed-off-by: Oguz Bektas <o.bek...@proxmox.com> > --- > > v1->v2: > changed some of the writing in terms of phrasing and style, with > feedback from aaron. thanks! > > pct.adoc | 442 ++++++++++++++++++++++++++++++++----------------------- > 1 file changed, 259 insertions(+), 183 deletions(-) > > diff --git a/pct.adoc b/pct.adoc > index 2f1d329..f8804e6 100644 > --- a/pct.adoc > +++ b/pct.adoc > @@ -28,32 +28,27 @@ 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. > +Containers are a lightweight alternative to fully virtualized VMs. 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. > > -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: > +The runtime costs 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 be considered: > > -* You can only run Linux based OS inside containers, i.e. it is not > - possible to run FreeBSD or MS Windows inside. > +* Only Linux distributions can be run in containers, i.e. It is not > + possible to run FreeBSD or MS Windows inside a container. > > -* 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. > +* For security reasons, access to host resources needs to be restricted. Some > + syscalls are not allowed within containers. This is done with AppArmor, > SecComp > + filters, and other kernel features. > > {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. 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 `pct` 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 +57,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,38 +74,66 @@ 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 > +* Uses {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 > -virtualized VMs provide better isolation. > +Containers use the kernel of the host system. This creates a big attack > +surface for malicious users. This should be considered if containers > +are provided to untrustworthy people. In general, full > +virtual machines provide better isolation. > + > +However, LXC uses many security features like AppArmor, CGroups and kernel > +namespaces to reduce the attack surface. > + > +AppArmor profiles are used to restrict access to possibly dangerous actions. > +Some system calls, i.e. `mount`, are prohibited from execution. > + > +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 > + > > -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. > +WARNING: Although it is not recommended, AppArmor can be disabled for a > +container. This brings security risks with it. Some syscalls can lead to > +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/CTID.conf`: > + > +---- > +lxc.apparmor_profile = unconfined > +---- > + > +Please note that this is not recommended 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 > -container startup: > +{pve} tries to detect the Linux distribution in the container, and modifies > some > +files. Here is a short list of things done at container startup: > > set /etc/hostname:: to set the container name > > @@ -145,7 +168,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 +203,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 to create 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. They can be downloaded using the GUI or the > +`pveam` (short for {pve} Appliance Manager) command line utility. > +Additionally, 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: > +The list of available templates is updated daily via cron. To trigger it > manually: > > - pveam update > +---- > +# pveam update > +---- > > -After that 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 +233,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 +258,49 @@ 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. > +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. > + > +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, 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 +320,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 only > works > +with privileged 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 +347,42 @@ 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. + > -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. > +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, you can set the *Skip replication* option for that mount point. + > +As of {pve} 5.0, replication requires a storage of type `zfspool`. Adding a > +mount point to a different type of storage when the container has replication > +configured requires to have *Skip replication* enabled for that mount point. > > > [[pct_settings]] > @@ -361,45 +406,43 @@ 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 these containers will affect a random unprivileged user, 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 > +aware the systemd version running inside the container should be equal to > or greater than 220. > > + > +Privileged Containers > +^^^^^^^^^^^^^^^^^^^^^ > + > +Security in containers is achieved by 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. 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. To view the assigned CPUs run > +the following command: > > ---- > # pct cpusets > @@ -410,10 +453,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. 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] > > @@ -459,14 +502,14 @@ 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: > +The root mount point is configured with the `rootfs` property. You can > +configure up to 256 additional mount points. The corresponding options > +are called `mp0` to `mp255`. They can contain the following settings: > > include::pct-mountpoint-opts.adoc[] > > -Currently there are basically three types of mount points: storage backed > -mount points, bind mounts and device mounts. > +Currently there are three types of mount points: storage backed > +mount points, bind mounts, and device mounts. > > .Typical container `rootfs` configuration > ---- > @@ -558,26 +601,27 @@ include::pct-network-opts.adoc[] > 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: > +To automatically start a container when the host system boots, select the > +option '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 > +* *Start/Shutdown order*: Defines the start order priority. For example, 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. For example, 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 +639,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,11 +718,11 @@ 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. > - > +The "Proxmox Container Toolkit" (`pct`) is the command line tool to manage > {pve} > +containers. It enables you to create or 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, for example the network > +configuration or memory limits. > > CLI Usage Examples > ~~~~~~~~~~~~~~~~~~ > @@ -684,32 +730,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 +779,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 +799,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 +839,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 > +The configuration files are simple text files. 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 +850,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 in red color in the GUI). They 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,13 +872,17 @@ 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. > +The settings are passed directly to the LXC low-level tools. > > > [[pct_snapshots]] > @@ -854,9 +928,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 > > _______________________________________________ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel