General settings of a container include
Unprivileged containers use a new kernel feature called user namespaces. The root UID 0 inside the container is mapped to an unprivileged user outside the container. This means that most security issues (container escape, resource abuse, etc.) in these containers will affect a random unprivileged user, and would be a generic kernel security bug rather than an LXC issue. The LXC team thinks unprivileged containers are safe by design.
This is the default option when creating a new container.
If the container uses systemd as an init system, please be aware the systemd version running inside the container should be equal to or greater than 220.
Security in containers is achieved by using mandatory access control AppArmor restrictions, seccomp filters and Linux kernel namespaces. The LXC team considers this kind of container as unsafe, and they will not consider new container escape exploits to be security issues worthy of a CVE and quick fix. That’s why privileged containers should only be used in trusted environments.
You can restrict the number of visible CPUs inside the container using the
cores
option. This is implemented using the Linux cpuset cgroup
(control group).
A special task inside pvestatd
tries to distribute running containers among
available CPUs periodically.
To view the assigned CPUs run the following command:
# pct cpusets --------------------- 102: 6 7 105: 2 3 4 5 108: 0 1 ---------------------
Containers use the host kernel directly. All tasks inside a container are handled by the host CPU scheduler. Proxmox VE uses the Linux CFS (Completely Fair Scheduler) scheduler by default, which has additional bandwidth control options.
|
You can use this option to further limit assigned CPU time. Please note that this is a floating point number, so it is perfectly valid to assign two cores to a container, but restrict overall CPU consumption to half a core. cores: 2 cpulimit: 0.5 |
|
This is a relative weight passed to the kernel scheduler. The larger the number is, the more CPU time this container gets. Number is relative to the weights of all the other running containers. The default is 1024. You can use this setting to prioritize some containers. |
Container memory is controlled using the cgroup memory controller.
|
Limit overall memory usage. This corresponds to the
|
|
Allows the container to use additional swap memory from the host
swap space. This corresponds to the |
The root mount point is configured with the rootfs
property. You can
configure up to 256 additional mount points. The corresponding options are
called mp0
to mp255
. They can contain the following settings:
rootfs
: [volume=]<volume> [,acl=<1|0>] [,mountoptions=<opt[;opt...]>] [,quota=<1|0>] [,replicate=<1|0>] [,ro=<1|0>] [,shared=<1|0>] [,size=<DiskSize>]
mp[n]
: [volume=]<volume> ,mp=<Path> [,acl=<1|0>] [,backup=<1|0>] [,mountoptions=<opt[;opt...]>] [,quota=<1|0>] [,replicate=<1|0>] [,ro=<1|0>] [,shared=<1|0>] [,size=<DiskSize>]
Use volume as container mount point. Use the special syntax STORAGE_ID:SIZE_IN_GiB to allocate a new volume.
acl
=<boolean>
backup
=<boolean>
mountoptions
=<opt[;opt...]>
mp
=<Path>
Path to the mount point as seen from inside the container.
Must not contain any symlinks for security reasons.
quota
=<boolean>
replicate
=<boolean>
(default = 1
)
ro
=<boolean>
shared
=<boolean>
(default = 0
)
Mark this non-volume mount point as available on all nodes.
This option does not share the mount point automatically, it assumes it is shared already!
size
=<DiskSize>
volume
=<volume>
Currently there are three types of mount points: storage backed mount points, bind mounts, and device mounts.
Typical container rootfs
configuration.
rootfs: thin1:base-100-disk-1,size=8G
Storage backed mount points are managed by the Proxmox VE storage subsystem and come in three different flavors:
size=0
triggers a special case where instead of a raw
image a directory is created.
The special option syntax STORAGE_ID:SIZE_IN_GB
for storage backed
mount point volumes will automatically allocate a volume of the specified size
on the specified storage. For example, calling
pct set 100 -mp0 thin1:10,mp=/path/in/container
will allocate a 10GB volume on the storage thin1
and replace the volume ID
place holder 10
with the allocated volume ID, and setup the moutpoint in the
container at /path/in/container
Bind mounts allow you to access arbitrary directories from your Proxmox VE host inside a container. Some potential use cases are:
Bind mounts are considered to not be managed by the storage subsystem, so you cannot make snapshots or deal with quotas from inside the container. With unprivileged containers you might run into permission problems caused by the user mapping and cannot use ACLs.
The contents of bind mount points are not backed up when using vzdump
.
For security reasons, bind mounts should only be established using
source directories especially reserved for this purpose, e.g., a directory
hierarchy under /mnt/bindmounts
. Never bind mount system directories like
/
, /var
or /etc
into a container - this poses a great security risk.
The bind mount source path must not contain any symlinks.
For example, to make the directory /mnt/bindmounts/shared
accessible in the
container with ID 100
under the path /shared
, use a configuration line like
mp0: /mnt/bindmounts/shared,mp=/shared
in /etc/pve/lxc/100.conf
.
Alternatively, use pct set 100 -mp0 /mnt/bindmounts/shared,mp=/shared
to
achieve the same result.
Device mount points allow to mount block devices of the host directly into the
container. Similar to bind mounts, device mounts are not managed by Proxmox VE’s
storage subsystem, but the quota
and acl
options will be honored.
Device mount points should only be used under special circumstances. In most cases a storage backed mount point offers the same performance and a lot more features.
The contents of device mount points are not backed up when using
vzdump
.
You can configure up to 10 network interfaces for a single container.
The corresponding options are called net0
to net9
, and they can contain the
following setting:
net[n]
: name=<string> [,bridge=<bridge>] [,firewall=<1|0>] [,gw=<GatewayIPv4>] [,gw6=<GatewayIPv6>] [,hwaddr=<XX:XX:XX:XX:XX:XX>] [,ip=<(IPv4/CIDR|dhcp|manual)>] [,ip6=<(IPv6/CIDR|auto|dhcp|manual)>] [,mtu=<integer>] [,rate=<mbps>] [,tag=<integer>] [,trunks=<vlanid[;vlanid...]>] [,type=<veth>]
Specifies network interfaces for the container.
bridge
=<bridge>
firewall
=<boolean>
gw
=<GatewayIPv4>
gw6
=<GatewayIPv6>
hwaddr
=<XX:XX:XX:XX:XX:XX>
ip
=<(IPv4/CIDR|dhcp|manual)>
ip6
=<(IPv6/CIDR|auto|dhcp|manual)>
mtu
=<integer> (64 - N)
name
=<string>
rate
=<mbps>
tag
=<integer> (1 - 4094)
trunks
=<vlanid[;vlanid...]>
type
=<veth>
To automatically start a container when the host system boots, select the option Start at boot in the Options panel of the container in the web interface or run the following command:
# pct set CTID -onboot 1
Start and Shutdown Order.
If you want to fine tune the boot order of your containers, you can use the following parameters:
Please note that containers without a Start/Shutdown order parameter will always start after those where the parameter is set, and this parameter only makes sense between the machines running locally on a host, and not cluster-wide.
If you require a delay between the host boot and the booting of the first container, see the section on Proxmox VE Node Management Section 3.10.4, “First Guest Boot Delay”.
You can add a hook script to CTs with the config property hookscript
.
# pct set 100 -hookscript local:snippets/hookscript.pl
It will be called during various phases of the guests lifetime. For an example
and documentation see the example script under
/usr/share/pve-docs/examples/guest-example-hookscript.pl
.