1 = Info for developers =
3 == Command Line Tool ==
7 # pct create 200 debian-7.0-standard_7.0-2_i386.tar.gz
13 You can get detailed help with:
19 We use integers values for container names (and do not allow to use
20 arbitrary names for containers).
22 == LXC Configuration ==
24 We store LXC container configurations on the cluster file system:
26 /etc/pve/nodes/<nodeid>/lxc/<CTID>/config
28 There is a symbolic link for the local node at
30 /etc/pve/lxc => /etc/pve/nodes/<localhost>/lxc
32 We store PVE related configuration using prefix 'pve', for example:
34 # lxc config for container 105
35 lxc.include = /usr/share/lxc/config/debian.common.conf
38 pve.volid = local:105/vm-105-rootfs.raw
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
48 Those 'pve.network' entrioes are used by the PVE::LXCSetup classes to
49 configure the network inside the containers.
51 We only allow 'veth' networks, and use 'lxc.network.veth.pair' to
52 uniquely identify the network withing the configuration file
62 CRIU (1.5.2) does not work well with kernel 3.10.0, so checkpoint/restore
63 and live migration does not work.
69 - LXD uses a local database to store configuration files, which simply
70 does not work with our distributed configuration file system
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."
78 We have a different goal, and want to support many new storage technologies
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.