projects / pve-container.git / blame
| 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 | ||
| 26 | /etc/pve/nodes/<nodeid>/lxc/<CTID>/config | |
| 27 | ||
| 28 | There is a symbolic link for the local node at | |
| 29 | ||
| 30 | /etc/pve/lxc => /etc/pve/nodes/<localhost>/lxc | |
| 31 | ||
| 32 | We store PVE related configuration using prefix 'pve', for example: | |
| 33 | ||
| 34 | # lxc config for container 105 | |
| 35 | lxc.include = /usr/share/lxc/config/debian.common.conf | |
| 36 | lxc.utsname = ct1 | |
| 37 | pve.disksize = 8 | |
| 38 | pve.volid = local:105/vm-105-rootfs.raw | |
| 39 | # network config | |
| 40 | lxc.network.type = veth | |
| 41 | pve.network.bridge = vmbr0 | |
| 42 | pve.network.gw = 192.168.2.1 | |
| 43 | lxc.network.hwaddr = 86:5D:0B:28:E6:23 | |
| 44 | pve.network.ip = 192.168.3.106/20 | |
| 45 | lxc.network.name = eth0 | |
| 46 | lxc.network.veth.pair = veth105.0 | |
| 47 | ||
| 48 | Those 'pve.network' entrioes are used by the PVE::LXCSetup classes to | |
| 49 | configure the network inside the containers. | |
| 50 | ||
| 51 | We only allow 'veth' networks, and use 'lxc.network.veth.pair' to | |
| 52 | uniquely identify the network withing the configuration file | |
| 53 | ||
| 54 | veth<vmid>.0 => net0 | |
| 55 | veth<vmid>.1 => net1 | |
| 56 | veth<vmid>.2 => net2 | |
| 57 | ... | |
| 58 | ||
| 59 | ||
| 60 | == CRIU == | |
| 61 | ||
| 62 | CRIU (1.5.2) does not work well with kernel 3.10.0, so checkpoint/restore | |
| 63 | and live migration does not work. | |
| 64 | ||
| 65 | = FAQ = | |
| 66 | ||
| 67 | * Why not LXD | |
| 68 | ||
| 69 | - LXD uses a local database to store configuration files, which simply | |
| 70 | does not work with our distributed configuration file system | |
| 71 | (pmxcfs) | |
| 72 | ||
| 14beba4c DM |
73 | - We want to use our existing libraries (i.e. Storage). Also see: |
| 74 | https://lists.linuxcontainers.org/pipermail/lxc-users/2015-June/009441.html | |
| 75 | where they write: "Lxd will not be as flexible as lxc in many ways, | |
| 76 | including with respect to backing stores." | |
| 77 | ||
| 78 | We have a different goal, and want to support many new storage technologies | |
| 79 | like zfs, ceph, ... | |
| 80 | ||
| d2a1b0d1 DM |
81 | - It is a wrapper around LXC, and only provides a REST API and new CLI |
| 82 | tool. But Proxmox VE already provides a full featured API, and CLI tools | |
| 83 | are automatically generated from that API. |