mirror of
https://git.proxmox.com/git/pve-container.git
synced 2026-03-28 07:50:34 +00:00
No description
de9544a04a
When doing a linked clone of a template, the task log, journal, nor the UPID of the task will log the VMID of the newly created container. We add a log message at the start of the clone. This affects both full and linked clones. Signed-off-by: Maximiliano Sandoval <m.sandoval@proxmox.com> Link: https://lore.proxmox.com/20260316123820.333308-3-m.sandoval@proxmox.com |
||
|---|---|---|
| debian | ||
| src | ||
| .gitignore | ||
| Makefile | ||
| README | ||
= Info for developers = == Command Line Tool == Example: # pct create 200 debian-7.0-standard_7.0-2_i386.tar.gz # pct start 200 # pct enter 200 # pct stop 200 # pct destroy 200 You can get detailed help with: # pct help -v == Container names == We use integers values for container names (and do not allow to use arbitrary names for containers). == LXC Configuration == We store LXC container configurations on the cluster file system: /etc/pve/nodes/lxc/<CTID>.conf There is a symbolic link for the local node at /etc/pve/lxc => /etc/pve/nodes/<localhost>/lxc see man pct.conf for syntax details. == CRIU == CRIU (1.5.2) does not work well with kernel 3.10.0, so checkpoint/restore and live migration does not work. = FAQ = * Why not LXD - LXD uses a local database to store configuration files, which simply does not work with our distributed configuration file system (pmxcfs) - We want to use our existing libraries (i.e. Storage). Also see: https://lists.linuxcontainers.org/pipermail/lxc-users/2015-June/009441.html where they write: "Lxd will not be as flexible as lxc in many ways, including with respect to backing stores." We have a different goal, and want to support many new storage technologies like zfs, ceph, ... - It is a wrapper around LXC, and only provides a REST API and new CLI tool. But Proxmox VE already provides a full featured API, and CLI tools are automatically generated from that API.