lxcfs下载lxcfs源代码下载

lxcfs

C#源码

LXC

下载

LXCFS

介绍

LXCFS是一个编写的小型保险丝文件系统，目的是使Linux容器更像虚拟机。它是从LXC的侧面项目开始的，但可在任何运行时使用。

LXCF将注意procfs中关键文件提供的信息，例如：

 /proc/cpuinfo
/proc/diskstats
/proc/meminfo
/proc/stat
/proc/swaps
/proc/uptime
/proc/slabinfo
/sys/devices/system/cpu/online

集装箱知道显示的值（例如/proc/uptime ）确实反映了容器正在运行多长时间，而不是主机运行的时间。

在实现Serge Hallyn LXCFS的Cgroup名称空间之前，还提供了一个容器Aware cgroupfs树。注意该容器只能访问其自己的CGroups下方的CGroups，因此提供了额外的安全性。对于不支持Cgroup名称空间的系统， LXCFS仍将提供此功能，但大多被认为是弃用的。

升级`LXCFS`而无需重新启动

LXCFS分为共享库（确切地说是Libtool模块） liblxcfs和一个简单的二进制lxcfs 。升级到较新版本的LXCFS时， lxcfs二进制将不会重新启动。相反，它将检测到共享库的新版本可用，并将使用dlclose(3)和dlopen(3)重新加载它。选择了此设计，以便不需要重新启动LXCFS使用的保险丝主循环。如果是使用LXCFS的所有容器，则需要重新启动，因为否则它们将留下保险丝折叠式安装座。

要在下一个可能的实例中强制共享库的重新加载，只需将SIGUSR1发送到运行LXCFS进程的PID即可。这可以和这样做一样简单：

 rm /usr/lib64/lxcfs/liblxcfs.so # MUST to delete the old library file first
cp liblxcfs.so /usr/lib64/lxcfs/liblxcfs.so # to place new library file
kill -s USR1 $(pidof lxcfs) # reload

musl

为了通过共享库重新加载实现平稳的升级， LXCFS也取决于以下事实：当dlclose(3)删除最后一个对共享库灾难的引用时，运行了dlopen(3)时称为构造函数。虽然对于glibc来说是正确的，但对于musl而言，这是不正确的（请参阅“卸载库”。）。因此，建议musl上的LXCFS用户完全重新启动LXCFS ，并使用所有容器。

建筑

为了构建LXCFS，请根据您的发行版安装保险丝和保险丝开发标头。 LXCFS更喜欢fuse3但确实可以与新的fuse2版本一起使用：

 git clone git://github.com/lxc/lxcfs
cd lxcfs
meson setup -Dinit-script=systemd --prefix=/usr build/
meson compile -C build/
sudo meson install -C build/

要使用消毒器构建，您必须指定-Db_sanitize=...选项到meson setup 。例如，启用Asan和Ubsan：

 meson setup -Dinit-script=systemd --prefix=/usr build/ -Db_sanitize=address,undefined
meson compile -C build/

用法

运行LXCFS的推荐命令是：

 sudo mkdir -p /var/lib/lxcfs
sudo lxcfs /var/lib/lxcfs

希望使用LXCFS容器运行时应将其固定在容器启动的正确位置中。

LXC

为了将LXCF与基于系统的容器一起使用，您可以使用LXC 1.1在这种情况下可以自动工作，或者在其他情况下复制lxc.mount.hook和lxc.reboot.hook /usr/share/lxcfs

 lxc.mount.auto = cgroup:mixed
lxc.autodev = 1
lxc.kmsg = 0
lxc.include = /usr/share/lxc/config/common.conf.d/00-lxcfs.conf

与Docker一起使用

 docker run -it -m 256m --memory-swap 256m 
      -v /var/lib/lxcfs/proc/cpuinfo:/proc/cpuinfo:rw 
      -v /var/lib/lxcfs/proc/diskstats:/proc/diskstats:rw 
      -v /var/lib/lxcfs/proc/meminfo:/proc/meminfo:rw 
      -v /var/lib/lxcfs/proc/stat:/proc/stat:rw 
      -v /var/lib/lxcfs/proc/swaps:/proc/swaps:rw 
      -v /var/lib/lxcfs/proc/uptime:/proc/uptime:rw 
      -v /var/lib/lxcfs/proc/slabinfo:/proc/slabinfo:rw 
      -v /var/lib/lxcfs/sys/devices/system/cpu:/sys/devices/system/cpu:rw 
      ubuntu:18.04 /bin/bash

在启用交换的系统中，可以使用参数“ -u”来设置“ meminfo”中的所有值，该值指的是互换为0。

sudo lxcfs -u/var/lib/lxcfs

交换处理

如果您注意到LXCF在系统上交换时未在容器中显示任何交换，请仔细阅读本节，并查找有关如何启用交换的说明。

在Linux上交换CGroup处理非常令人困惑，而LXCF的处理方式并不是一个完美的方法。

以下术语：

RAM memory.limit_in_bytes memory.usage_in_bytes
RAM+交换参考memory.memsw.usage_in_bytes and memory.memsw.limit_in_bytes

主要问题是：

交换会计通常是选择加入的，需要特殊的内核启动时间选项（ swapaccount=1 ）和/或特殊的内核构建选项（ CONFIG_MEMCG_SWAP ）。
可以设置RAM限制和RAM+交换限制。但是，三角洲并不是可用的交换空间，因为内核仍然可以自由交换最大的RAM。这使得不可能使用RAM和RAM+交换之间的三角洲进行交换设备尺寸，因为这不会说明内核交换更多页面，从而导致交换使用率超过交换总额。
在给定的容器中禁用交换是不可能的。可以完成的最接近的是将交换设置为0，这严重限制了交换页面的风险，但不会消除它。

结果，LXCF必须做出一些妥协，如下：

当未启用交换会计时，根本没有报告交换空间。这仅仅是因为没有办法知道掉期消耗。但是，容器可能会使用一些交换，但根本无法知道其中的多少并显示交换设备需要报告某种交换用法。显示主机值将是完全错误的，显示0值是相等的错误。
由于给定容器的互换使用量可以超过RAM和RAM+交换之间的增量，因此据报道，交换大小始终是RAM+交换限制的较小或主机交换设备本身的较小。这样可以确保绝对不允许使用交换量超过掉期大小。
如果将交换设置为0，并且没有互换用法，则不会报告交换。但是，如果使用互换，则报告使用使用尺寸的交换设备（100％满）。这提供了足够的报告记忆消耗，同时防止应用程序假设有更多交换。

问题报告

核心转储

如果发生LXCFS崩溃，对于我们来说，拥有LXCFS过程内存的核心转储对于我们来说非常有用。

请检查/var/crash和coredumpctl list以防万一您已经有lxcfs核心转储文件
如果没有，您可以使用以下方式从系统中收集它：

在运行LXCFS的机器上，执行为root：

 # save an old core_pattern setting value:
cat /proc/sys/kernel/core_pattern > /root/core_pattern.old_value.bak

# set a new one to collect all core dumps:
echo '|/bin/sh -c $@ -- eval exec gzip --fast > /var/crash/core-%e.%p.gz' > /proc/sys/kernel/core_pattern

# wait for the next LXCFS crash and check
ls -lah /var/crash

# there should be a file with a name like "core-lxcfs.80581.gz". Please, upload it somewhere and share with us.

# restore the old "core_pattern" value:
cat /root/core_pattern.old_value.bak > /proc/sys/kernel/core_pattern

展开

附加信息