]> git.proxmox.com Git - mirror_lxcfs.git/blob - README.md
Merge pull request #564 from blue-troy/master
[mirror_lxcfs.git] / README.md
1 # lxcfs
2
3 ## Introduction
4 LXCFS is a small FUSE filesystem written with the intention of making Linux
5 containers feel more like a virtual machine. It started as a side-project of
6 `LXC` but is useable by any runtime.
7
8 LXCFS will take care that the information provided by crucial files in `procfs`
9 such as:
10
11 ```
12 /proc/cpuinfo
13 /proc/diskstats
14 /proc/meminfo
15 /proc/stat
16 /proc/swaps
17 /proc/uptime
18 /proc/slabinfo
19 /sys/devices/system/cpu
20 /sys/devices/system/cpu/online
21 ```
22
23 are container aware such that the values displayed (e.g. in `/proc/uptime`)
24 really reflect how long the container is running and not how long the host is
25 running.
26
27 Prior to the implementation of cgroup namespaces by Serge Hallyn `LXCFS` also
28 provided a container aware `cgroupfs` tree. It took care that the container
29 only had access to cgroups underneath it's own cgroups and thus provided
30 additional safety. For systems without support for cgroup namespaces `LXCFS`
31 will still provide this feature but it is mostly considered deprecated.
32
33 ## Upgrading `LXCFS` without restart
34
35 `LXCFS` is split into a shared library (a libtool module, to be precise)
36 `liblxcfs` and a simple binary `lxcfs`. When upgrading to a newer version of
37 `LXCFS` the `lxcfs` binary will not be restarted. Instead it will detect that
38 a new version of the shared library is available and will reload it using
39 `dlclose(3)` and `dlopen(3)`. This design was chosen so that the fuse main loop
40 that `LXCFS` uses will not need to be restarted. If it were then all containers
41 using `LXCFS` would need to be restarted since they would otherwise be left
42 with broken fuse mounts.
43
44 To force a reload of the shared library at the next possible instance simply
45 send `SIGUSR1` to the pid of the running `LXCFS` process. This can be as simple
46 as doing:
47
48 rm /usr/lib64/lxcfs/liblxcfs.so # MUST to delete the old library file first
49 cp liblxcfs.so /usr/lib64/lxcfs/liblxcfs.so # to place new library file
50 kill -s USR1 $(pidof lxcfs) # reload
51
52 ### musl
53
54 To achieve smooth upgrades through shared library reloads `LXCFS` also relies
55 on the fact that when `dlclose(3)` drops the last reference to the shared
56 library destructors are run and when `dlopen(3)` is called constructors are
57 run. While this is true for `glibc` it is not true for `musl` (See the section
58 [Unloading libraries](https://wiki.musl-libc.org/functional-differences-from-glibc.html).).
59 So users of `LXCFS` on `musl` are advised to restart `LXCFS` completely and all
60 containers making use of it.
61
62 ## Building
63
64 In order to build LXCFS install fuse and the fuse development headers according
65 to your distro. LXCFS prefers `fuse3` but does work with new enough `fuse2`
66 versions:
67
68 git clone git://github.com/lxc/lxcfs
69 cd lxcfs
70 meson setup -Dinit-script=systemd --prefix=/usr build/
71 meson compile -C build/
72 sudo meson install -C build/
73
74 ## Usage
75 The recommended command to run lxcfs is:
76
77 sudo mkdir -p /var/lib/lxcfs
78 sudo lxcfs /var/lib/lxcfs
79
80 A container runtime wishing to use `LXCFS` should then bind mount the
81 approriate files into the correct places on container startup.
82
83 ### LXC
84 In order to use lxcfs with systemd-based containers, you can either use
85 LXC 1.1 in which case it should work automatically, or otherwise, copy
86 the `lxc.mount.hook` and `lxc.reboot.hook` files (once built) from this tree to
87 `/usr/share/lxcfs`, make sure it is executable, then add the
88 following lines to your container configuration:
89 ```
90 lxc.mount.auto = cgroup:mixed
91 lxc.autodev = 1
92 lxc.kmsg = 0
93 lxc.include = /usr/share/lxc/config/common.conf.d/00-lxcfs.conf
94 ```
95
96 ## Using with Docker
97
98 ```
99 docker run -it -m 256m --memory-swap 256m \
100 -v /var/lib/lxcfs/proc/cpuinfo:/proc/cpuinfo:rw \
101 -v /var/lib/lxcfs/proc/diskstats:/proc/diskstats:rw \
102 -v /var/lib/lxcfs/proc/meminfo:/proc/meminfo:rw \
103 -v /var/lib/lxcfs/proc/stat:/proc/stat:rw \
104 -v /var/lib/lxcfs/proc/swaps:/proc/swaps:rw \
105 -v /var/lib/lxcfs/proc/uptime:/proc/uptime:rw \
106 -v /var/lib/lxcfs/proc/slabinfo:/proc/slabinfo:rw \
107 -v /var/lib/lxcfs/sys/devices/system/cpu:/sys/devices/system/cpu:rw \
108 ubuntu:18.04 /bin/bash
109 ```
110
111 In a system with swap enabled, the parameter "-u" can be used to set all values in "meminfo" that refer to the swap to 0.
112
113 sudo lxcfs -u /var/lib/lxcfs
114
115 ## Swap handling
116 If you noticed LXCFS not showing any SWAP in your container despite
117 having SWAP on your system, please read this section carefully and look
118 for instructions on how to enable SWAP accounting for your distribution.
119
120 Swap cgroup handling on Linux is very confusing and there just isn't a
121 perfect way for LXCFS to handle it.
122
123 Terminology used below:
124 - RAM refers to `memory.usage_in_bytes` and `memory.limit_in_bytes`
125 - RAM+SWAP refers to `memory.memsw.usage_in_bytes` and `memory.memsw.limit_in_bytes`
126
127 The main issues are:
128 - SWAP accounting is often opt-in and, requiring a special kernel boot
129 time option (`swapaccount=1`) and/or special kernel build options
130 (`CONFIG_MEMCG_SWAP`).
131
132 - Both a RAM limit and a RAM+SWAP limit can be set. The delta however
133 isn't the available SWAP space as the kernel is still free to SWAP as
134 much of the RAM as it feels like. This makes it impossible to render
135 a SWAP device size as using the delta between RAM and RAM+SWAP for that
136 wouldn't account for the kernel swapping more pages, leading to swap
137 usage exceeding swap total.
138
139 - It's impossible to disable SWAP in a given container. The closest
140 that can be done is setting swappiness down to 0 which severly limits
141 the risk of swapping pages but doesn't eliminate it.
142
143 As a result, LXCFS had to make some compromise which go as follow:
144 - When SWAP accounting isn't enabled, no SWAP space is reported at all.
145 This is simply because there is no way to know the SWAP consumption.
146 The container may very much be using some SWAP though, there's just
147 no way to know how much of it and showing a SWAP device would require
148 some kind of SWAP usage to be reported. Showing the host value would be
149 completely wrong, showing a 0 value would be equallty wrong.
150
151 - Because SWAP usage for a given container can exceed the delta between
152 RAM and RAM+SWAP, the SWAP size is always reported to be the smaller of
153 the RAM+SWAP limit or the host SWAP device itself. This ensures that at no
154 point SWAP usage will be allowed to exceed the SWAP size.
155
156 - If the swappiness is set to 0 and there is no SWAP usage, no SWAP is reported.
157 However if there is SWAP usage, then a SWAP device of the size of the
158 usage (100% full) is reported. This provides adequate reporting of
159 the memory consumption while preventing applications from assuming more
160 SWAP is available.