]> git.proxmox.com Git - pve-container.git/blame - README
add termproxy api call for lxc
[pve-container.git] / README
CommitLineData
d2a1b0d1
DM
1= Info for developers =
2
3== Command Line Tool ==
4
5Example:
6
7 # pct create 200 debian-7.0-standard_7.0-2_i386.tar.gz
8 # pct start 200
9 # pct enter 200
10 # pct stop 200
11 # pct destroy 200
12
13You can get detailed help with:
14
15 # pct help -v
16
17== Container names ==
18
19We use integers values for container names (and do not allow to use
20arbitrary names for containers).
21
22== LXC Configuration ==
23
24We store LXC container configurations on the cluster file system:
25
a9847ff2 26 /etc/pve/nodes/lxc/<CTID>.conf
d2a1b0d1
DM
27
28There is a symbolic link for the local node at
29
30 /etc/pve/lxc => /etc/pve/nodes/<localhost>/lxc
31
a9847ff2 32see man pct.conf for syntax details.
d2a1b0d1
DM
33
34== CRIU ==
35
36CRIU (1.5.2) does not work well with kernel 3.10.0, so checkpoint/restore
37and live migration does not work.
38
39= FAQ =
40
41* Why not LXD
42
43- LXD uses a local database to store configuration files, which simply
44 does not work with our distributed configuration file system
45 (pmxcfs)
46
14beba4c
DM
47- We want to use our existing libraries (i.e. Storage). Also see:
48 https://lists.linuxcontainers.org/pipermail/lxc-users/2015-June/009441.html
49 where they write: "Lxd will not be as flexible as lxc in many ways,
50 including with respect to backing stores."
51
52 We have a different goal, and want to support many new storage technologies
53 like zfs, ceph, ...
54
d2a1b0d1
DM
55- It is a wrapper around LXC, and only provides a REST API and new CLI
56 tool. But Proxmox VE already provides a full featured API, and CLI tools
57 are automatically generated from that API.