]>
Commit | Line | Data |
---|---|---|
d2a1b0d1 DM |
1 | = Info for developers = |
2 | ||
3 | == Command Line Tool == | |
4 | ||
5 | Example: | |
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 | ||
13 | You can get detailed help with: | |
14 | ||
15 | # pct help -v | |
16 | ||
17 | == Container names == | |
18 | ||
19 | We use integers values for container names (and do not allow to use | |
20 | arbitrary names for containers). | |
21 | ||
22 | == LXC Configuration == | |
23 | ||
24 | We store LXC container configurations on the cluster file system: | |
25 | ||
a9847ff2 | 26 | /etc/pve/nodes/lxc/<CTID>.conf |
d2a1b0d1 DM |
27 | |
28 | There is a symbolic link for the local node at | |
29 | ||
30 | /etc/pve/lxc => /etc/pve/nodes/<localhost>/lxc | |
31 | ||
a9847ff2 | 32 | see man pct.conf for syntax details. |
d2a1b0d1 DM |
33 | |
34 | == CRIU == | |
35 | ||
36 | CRIU (1.5.2) does not work well with kernel 3.10.0, so checkpoint/restore | |
37 | and 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. |