QorIQ嵌入式平台LXC容器配置实战：从内核到网络与资源隔离

1. 项目概述：为什么要在QorIQ上折腾LXC？

在嵌入式开发领域，尤其是像Freescale（现NXP）QorIQ系列这样的高性能多核网络处理器上，我们常常面临一个经典矛盾：一方面，硬件资源（CPU核心、内存、网络接口）越来越丰富，足以支撑多个独立的应用或服务；另一方面，传统的单一系统镜像（Single System Image）部署方式，使得应用之间缺乏强隔离，一个应用的崩溃或资源泄露可能拖垮整个系统，安全性和可靠性都面临挑战。虚拟机（VM）方案如QEMU/KVM虽然隔离性好，但其全虚拟化带来的内存和CPU开销，在资源敏感的嵌入式场景中往往显得过于“笨重”。

这时，Linux容器（LXC）技术就进入了我们的视野。它不是虚拟出一台完整的“电脑”，而是在同一个Linux内核之上，通过内核提供的命名空间（Namespaces）和控制组（cgroups）机制，为进程组创建一个独立的“沙箱”环境。在这个沙箱里，进程拥有独立的进程树、网络栈、挂载点视图，并且其能使用的CPU、内存等资源受到精确的限制和审计。对于QorIQ这类通常运行定制化Linux、需要部署多个网络功能单元（如防火墙、路由、DPI）的平台来说，LXC提供了一种近乎完美的轻量级虚拟化方案：它兼具了良好的隔离性与接近原生进程的性能，资源开销极小。

我最早在P4080和后来的T系列处理器上实践LXC，初衷就是为了将不同的网络处理应用（例如数据平面转发和控制平面管理）进行物理隔离，避免它们相互干扰。经过多个项目的打磨，我发现这套方案不仅稳定，而且在资源利用率和部署灵活性上优势明显。本文将基于Freescale SDK的官方指南，结合我个人的实战经验，深入剖析在QorIQ处理器上配置与应用LXC的完整流程、核心原理以及那些手册上不会写的“坑”与技巧。

2. 环境准备：内核、根文件系统与工具链

在QorIQ平台上玩转LXC，第一步不是直接敲命令，而是打好地基——准备好一个支持所有必要特性的Linux内核和根文件系统。很多初学者在这一步就卡住了，因为默认的SDK配置可能并未完全开启LXC所需的所有选项。

2.1 内核配置：开启命名空间与cgroups的魔法

LXC依赖Linux内核的几大核心特性：控制组（cgroups）用于资源管理，命名空间（Namespaces）用于视图隔离，还有虚拟网络设备、文件能力等。使用SDK的Yocto构建系统时，我们需要确保这些选项被启用。

通常，我们可以通过bitbake linux-qoriq-sdk -c menuconfig命令进入内核配置菜单。以下是必须检查的关键配置项，我建议直接以[*]或<*>的形式编译进内核，而不是作为模块，以减少运行时依赖：

控制组 (cgroups) 支持：这是资源管理的基石。在General setup -> Control Group support路径下，确保以下子项被启用：

• [*] Freezer cgroup subsystem：用于挂起和恢复容器内所有进程，是lxc-freeze和lxc-unfreeze命令的基础。
• [*] Device controller for cgroups：控制容器内进程对设备的访问权限，是安全隔离的重要一环。
• [*] Cpuset support：允许将容器绑定到特定的CPU核心上，对于QorIQ这种多核处理器，实现核心隔离至关重要。
• [*] Simple CPU accounting cgroup subsystem (cpuacct)：用于统计容器的CPU使用情况。
• [*] Group CPU scheduler：即cpusched，用于控制容器的CPU时间片分配。
• [*] Memory Resource Controller for Control Groups：内存控制器，用于限制和统计容器的内存使用。这是防止容器“内存泄漏”拖垮宿主机的关键！

命名空间 (Namespaces) 支持：在General setup -> Namespaces support路径下，确保以下全部启用：

• [*] UTS namespace：隔离主机名和域名。
• [*] IPC namespace：隔离System V IPC和POSIX消息队列。
• [*] PID namespace：为容器提供独立的进程ID空间，容器内PID 1的进程是init。
• [*] Network namespace：提供独立的网络设备、IP栈、路由表、防火墙规则等。这是实现容器网络独立的核心。
• [*] User namespace (EXPERIMENTAL)：隔离用户和组ID。早期SDK版本中可能标记为实验性，但对于提升安全性很有帮助，可根据内核版本决定是否启用。

网络设备驱动：为了让容器拥有独立的网络，需要虚拟网络设备支持。在Device Drivers -> Network device support下：

• <*> MAC-VLAN support和<*> MAC-VLAN based tap driver：用于创建基于MACVLAN的网络接口。
• <*> Virtual ethernet pair device：即veth，用于创建成对的虚拟网卡，一端在容器内，一端在宿主机上，是容器联网最常用的方式。

文件系统与字符设备：

• File systems -> Ext3 extended attributes和Ext3 POSIX Access Control Lists：如果根文件系统是ext3/4，需要这些来支持更丰富的文件属性。
• Device Drivers -> Character devices -> [*] Unix98 PTY support并确保Support multiple instances of devpts被启用：这是为容器提供伪终端（如/dev/tty1）所必需的。

实操心得：内核配置检查编译完内核后，不要急于刷写。可以先在编译输出目录找到.config文件，用grep命令快速检查关键配置，例如：grep -E “CONFIG_CGROUPS|CONFIG_NAMESPACES|CONFIG_VETH|CONFIG_MACVLAN” .config。更稳妥的方法是，将编译好的内核镜像和dtb文件加载到开发板上，直接使用LXC自带的lxc-checkconfig工具进行验证。如果输出中任何一项不是“enabled”，都需要回头检查内核配置。

2.2 根文件系统构建：集成LXC与Busybox

Freescale SDK的Yocto项目使得添加软件包变得非常简单。为了获得一个包含LXC的完整根文件系统，最直接的方法是构建fsl-image-full镜像：bitbake fsl-image-full。这个镜像已经包含了LXC及其依赖。

如果你需要基于一个更精简的镜像（如fsl-image-core）添加LXC，只需在Yocto构建环境的conf/local.conf文件中添加一行：IMAGE_INSTALL_append = ” lxc”。这样，下次构建镜像时，LXC包就会被自动包含进去。

Busybox模板的特别处理：LXC提供了多种模板来创建不同发行版的容器根文件系统，对于嵌入式环境，busybox模板是最轻量、最常用的。但这里有个关键点：为了让模板脚本能正确工作，宿主机上的Busybox必须被编译为静态链接。这是因为模板脚本会在容器内chroot并运行Busybox，如果Busybox动态链接，而容器内没有相应的库文件，就会失败。

确保Busybox静态编译的步骤：

bitbake busybox -c cleansstate bitbake busybox -c menuconfig

在menuconfig界面中，导航至Busybox Settings -> Build Options，选中[*] Build BusyBox as a static binary (no shared libs)。保存退出后，执行bitbake busybox重新编译，最后再重新构建你的根文件系统镜像（如bitbake fsl-image-full）。

2.3 宿主机初始化：挂载cgroup文件系统

当系统启动后，在使用LXC之前，有一个必须执行的步骤：挂载cgroup虚拟文件系统。这是LXC管理容器资源的接口。

通常，我们会在系统启动脚本（如/etc/rc.local）中添加以下命令，确保每次启动都自动完成：

mkdir -p /cgroup mount -t cgroup cgroup /cgroup

执行后，你可以通过ls /cgroup看到诸如cpu、cpuacct、memory、devices等子目录，每个子目录对应一个cgroup控制器。

注意事项：挂载点选择挂载点/cgroup不是硬性规定，你可以选择/sys/fs/cgroup（现代��统的标准位置）。但在一些较旧的SDK或内核版本中，使用/cgroup可能更可靠。关键是确保路径存在且挂载成功。使用mount | grep cgroup命令可以验证是否挂载成功。

3. LXC核心概念与配置解析

在动手创建容器之前，理解LXC的几个核心概念至关重要。这能帮助你在出现问题时，知道该从哪个方向排查。

3.1 命名空间：隔离的魔法墙

可以把命名空间想象成给进程戴上的不同“眼镜”。每类命名空间都提供了一种资源的隔离视图：

• PID命名空间：容器内的进程从1开始重新编号。你在容器内ps看到的PID，在宿主机上对应着完全不同的PID。这实现了进程树的隔离。
• 网络命名空间：容器拥有自己独立的网络设备列表（初始只有lo）、IP地址、路由表、iptables规则。这是实现容器网络独立的关键。通过vethpair，可以将虚拟网卡的一端放入容器的网络命名空间，另一端留在宿主机，再通过桥接或NAT让容器访问外网。
• UTS命名空间：容器可以有自己的主机名（hostname）和域名（domainname），uname -n的输出与宿主机不同。
• IPC命名空间：隔离了System V IPC对象（如消息队列、共享内存）和POSIX消息队列，防止容器间通过此类机制非法通信。
• 挂载命名空间：容器可以有自己独立的文件系统挂载点视图。通过lxc.mount.entry配置，可以将宿主机的特定目录（如/lib）以只读方式“绑定挂载”到容器内，实现库文件共享，而无需在容器内复制一份。

3.2 控制组：资源的紧箍咒

如果说命名空间是“隔离”，那么控制组就是“限制”。cgroup允许你为容器这个进程组设置资源上限：

• cpu和cpuset：cpu控制器通过cpu.shares来分配CPU时间比例；cpuset则更直接，可以将容器绑定到特定的CPU核心上。在QorIQ多核处理器上，我经常用cpuset将某个对延迟敏感的数据平面容器独占绑定到一两个物理核心上，避免其他容器任务对其造成干扰。
• memory：这是最重要的控制器之一。通过设置memory.limit_in_bytes，可以硬性限制容器能使用的最大内存（包括缓存）。设置memory.memsw.limit_in_bytes可以限制内存+交换分区总量。务必设置此限制，这是生产环境避免单个容器耗尽系统内存的保险丝。
• devices：控制容器内进程能否访问特定设备节点（如/dev/mem,/dev/sda）。通过白名单机制，可以严格限制容器内进程的设备访问权限，极大增强安全性。
• freezer：可以挂起（freeze）或恢复（thaw）容器内的所有进程。常用于批量操作容器或检查点（checkpoint）场景。

3.3 配置文件：容器的蓝图

每个容器在/var/lib/lxc/<容器名>/目录下都有一个config配置文件。这个文件定义了容器的所有属性。理解其关键配置项是灵活运用LXC的基础。

一个典型的无网络容器的配置可能如下所示：

lxc.utsname = mycontainer lxc.tty = 4 lxc.pts = 1024 lxc.rootfs = /var/lib/lxc/mycontainer/rootfs lxc.mount.entry = /lib /var/lib/lxc/mycontainer/rootfs/lib none ro,bind 0 0 lxc.mount.entry = /usr/lib /var/lib/lxc/mycontainer/rootfs/usr/lib none ro,bind 0 0 lxc.cgroup.devices.deny = a lxc.cgroup.devices.allow = c 1:3 rwm lxc.cgroup.devices.allow = c 1:5 rwm lxc.cgroup.devices.allow = c 1:8 rwm lxc.cgroup.devices.allow = c 1:9 rwm lxc.cgroup.devices.allow = c 5:1 rwm lxc.cgroup.devices.allow = c 5:2 rwm lxc.cgroup.devices.allow = c 136:* rwm

• lxc.utsname：设置容器的主机名。
• lxc.rootfs：指定容器根文件系统的路径。
• lxc.mount.entry：绑定挂载。上面的例子将宿主机的/lib和/usr/lib以只读（ro）方式挂载到容器内，这样容器内的程序就可以直接使用宿主机的库，无需在每个容器里都放一份，节省了大量空间。
• lxc.cgroup.devices.allow/deny：设备访问控制。先deny all，再按需allow特定设备。上面的例子允许了/dev/null、/dev/zero、/dev/full、/dev/random、/dev/urandom、/dev/tty、/dev/console以及/dev/pts/*等伪终端设备。这是容器安全配置的关键一步，务必根据容器内应用的实际需要，严格限制设备访问。

3.4 能力：细粒度的特权管理

Linux的能力（Capabilities）机制将超级用户特权分解为几十个独立的单元。LXC可以利用这一点，即使容器内的进程以root身份运行，也可以剥夺其部分危险特权。 例如，在配置文件中加入：

lxc.cap.drop = sys_module mknod net_raw sys_rawio

这行配置将丢弃CAP_SYS_MODULE（禁止加载内核模块）、CAP_MKNOD（禁止创建设备节点）、CAP_NET_RAW（禁止原始套接字，防止嗅探）和CAP_SYS_RAWIO（禁止I/O端口操作）等能力。根据Linux-VServer项目的安全建议，一个被严格限制的容器可能只被授予十多项相对安全的能力。对于运行不受信任代码的容器，仔细配置lxc.cap.drop是构建安全沙箱的核心。

4. 完整实战：从创建到管理一个Busybox系统容器

理论讲得再多，不如动手操作一遍。下面我们以创建一个名为testbox的Busybox系统容器为例，走通全流程。

4.1 第一步：环境检查与容器创建

首先，使用lxc-checkconfig验证内核支持是否完整。如果一切正常，输出应全部显示“enabled”。

# lxc-checkconfig --- Namespaces --- Namespaces: enabled Utsname namespace: enabled Ipc namespace: enabled Pid namespace: enabled User namespace: enabled Network namespace: enabled ... --- Control groups --- Cgroup: enabled ...

如果Cgroup namespace: required，说明/cgroup没有挂载，请返回执行挂载步骤。

接下来，使用lxc-create命令创建容器。我们使用busybox模板和一个简单的无网络配置文件。

# lxc-create -n testbox -t busybox -f /usr/share/doc/lxc/examples/lxc-empty-netns.conf

• -n testbox：指定容器名为testbox。
• -t busybox：指定使用busybox模板。模板脚本会为我们在/var/lib/lxc/testbox/rootfs下创建一个最小的Busybox根文件系统。
• -f ...：指定配置文件。lxc-empty-netns.conf是一个预置的配置文件，它创建了一个没有网络命名空间的容器（即与宿主机共享网络）。

命令执行成功后，会提示设置root密码。完成后，容器的目录结构就创建好了。

4.2 第二步：启动容器与初探

使用lxc-start在后台启动容器，并用lxc-console连接其控制台。

# lxc-start -n testbox -d # -d 参数表示后台守护进程模式启动 # lxc-console -n testbox

按下回车激活控制台后，你会进入容器的shell，提示符变为root@testbox:/#。现在，你就在一个独立的容器环境里了。

执行一些命令感受一下隔离性：

• hostname：会显示testbox，而不是宿主机名。
• ps aux：只会看到容器内的几个进程（如init、syslogd、getty、sh），PID都是从1开始编号的。
• ifconfig -a：如果使用empty-netns配置，可能只看到lo回环接口，或者能看到宿主机的所有网络接口（因为网络未隔离）。

在另一个宿主机终端上，使用LXC命令从外部观察容器：

# lxc-ls -l # 列出所有容器及其状态 # lxc-info -n testbox # 查看容器详细信息，如状态、PID # lxc-ps -n testbox # 查看容器内进程（从宿主机视角）

你会发现，lxc-ps显示的容器内进程的PID，与你在容器内用ps看到的PID完全不同。这正是PID命名空间在起作用。

4.3 第三步：配置容器网络（veth + bridge模式）

无网络的容器用处有限。更常见的场景是为容器配置独立的网络。我们采用vethpair + Linux网桥的模式，这是最灵活的方式之一。

1. 创建网桥（在宿主机上操作）：

# brctl addbr br0 # ip addr add 192.168.10.1/24 dev br0 # ip link set br0 up

2. 修改容器配置文件：编辑/var/lib/lxc/testbox/config，将网络部分修改为类似以下内容：

lxc.network.type = veth lxc.network.flags = up lxc.network.link = br0 # 连接到宿主机网桥br0 lxc.network.hwaddr = 00:16:3e:xx:xx:xx # 可选，设置MAC地址 lxc.network.ipv4 = 192.168.10.100/24 # 为容器设置静态IP lxc.network.ipv4.gateway = 192.168.10.1

这里，lxc.network.type = veth告诉LXC创建一个vethpair。一端在容器内（通常命名为eth0），另一端（通常命名为vethXXX）被自动连接到br0网桥上。

3. 重启容器并验证网络：

# lxc-stop -n testbox # lxc-start -n testbox -d # lxc-console -n testbox

在容器控制台内：

root@testbox:/# ip addr show eth0 # 应该能看到配置的IP地址 root@testbox:/# ping 192.168.10.1 # 应该能ping通宿主机网桥地址

在宿主机上，使用brctl show可以看到br0上连接了一个veth接口。

实操心得：网络故障排查如果容器内无法获取IP或无法通信，按以下顺序排查：

1. 检查veth pair：在宿主机执行ip link show，查看是否有veth开头的接口。确认它是否UP，并且是否在br0上（brctl showstp br0）。
2. 检查容器内网卡：在容器内执行ip link show，确认eth0存在且状态为UP。如果没有，可能是LXC的lxc.network配置有误，或者内核不支持veth。
3. 检查iptables：宿主机上的iptables规则可能会阻断桥接网络流量。可以临时清空filter表规则测试：iptables -F（生产环境慎用）。更安全的做法是为br0添加允许转发和进入的规则。
4. 检查路由：在容器内执行ip route，确认默认网关是否正确指向了192.168.10.1。

4.4 第四步：使用cgroups限制容器资源

LXC会在容器启动时自动在/cgroup下为其创建子目录。我们可以直接操作这些目录，或者用lxc-cgroup命令来动态调整资源限制。

例如，限制testbox容器最多只能使用256MB内存：

# lxc-cgroup -n testbox memory.limit_in_bytes 268435456 # 256MB = 256 * 1024 * 1024

将容器绑定到CPU0和CPU1上运行：

# lxc-cgroup -n testbox cpuset.cpus 0-1

查看容器的CPU使用统计：

# lxc-cgroup -n testbox cpuacct.usage # 显示容器消耗的总CPU时间（纳秒） # lxc-cgroup -n testbox cpuacct.usage_percpu # 显示每个CPU上的时间

更推荐的做法是将这些限制写入配置文件，使其在容器创建时就生效。在config文件中添加：

lxc.cgroup.memory.limit_in_bytes = 268435456 lxc.cgroup.memory.memsw.limit_in_bytes = 536870912 # 内存+交换分区总共512MB lxc.cgroup.cpuset.cpus = 0-1

4.5 第五步：容器的生命周期管理

• 暂停与恢复：lxc-freeze -n testbox会挂起容器内所有进程；lxc-unfreeze -n testbox会恢复它们。这比停止再启动要快，适用于临时释放资源或做一致性检查。
• 停止：lxc-stop -n testbox会向容器内的init进程发送SIGTERM信号，等待其优雅关闭所有进程。可以加-k参数强制杀死。
• 销毁：lxc-destroy -n testbox会彻底删除容器的根文件系统和配置目录，操作不可逆，务必谨慎。

5. 高级应用与生产环境考量

掌握了基础操作后，我们可以探讨一些更深入的应用场景和稳定性保障措施。

5.1 应用容器 vs. 系统容器

• 系统容器：我们上面用busybox模板创建的就是一个微型的系统容器，它有自己的init进程（通常是/sbin/init的一个简化版）、服务管理（如syslogd）和getty。它模拟了一个完整的微型操作系统环境。
• 应用容器：使用lxc-execute命令可以直接在容器内运行一个单一程序。例如：

  # lxc-execute -n myapp -- /usr/bin/my_application --daemon

  这种方式更轻量，启动更快，适合部署单个后台服务。此时，容器内的PID 1就是这个应用程序本身。需要特别注意应用程序的信号处理，因为它需要承担init进程的部分职责（如回收僵尸进程）。

5.2 容器根文件系统的构建策略

Busybox模板简单，但功能有限。对于更复杂的应用，你可能需要构建一个更完整的根文件系统。

1. 使用debootstrap等工具：在x86开发机上，可以使用debootstrap为容器构建一个Debian或Ubuntu的根文件系统，然后通过NFS或直接拷贝到目标板的/var/lib/lxc/xxx/rootfs目录下。这需要目标板处理器架构与开发机一致（或使用交叉编译工具链）。
2. 使用Yocto构建：最正统的嵌入式方式。你可以为容器专门创建一个Yocto镜像配方（image recipe），构建出一个极简的根文件系统tar包，然后解压到容器目录。这样可以确保容器与宿主机的库版本完全兼容。
3. 绑定挂载关键目录：如前所述，通过lxc.mount.entry将宿主机的/lib、/usr/lib、甚至/bin、/sbin以只读方式共享给容器，可以极大减少容器根文件系统的体积。但要注意，这降低了隔离性，容器内的程序必须与宿主机库ABI兼容。

5.3 安全加固实践

在嵌入式设备上，安全同样重要。除了前面提到的lxc.cap.drop和设备cgroup控制，还有以下建议：

• 启用用户命名空间：如果内核支持，在配置中添加lxc.id_map = u 0 100000 65536和lxc.id_map = g 0 100000 65536，可以将容器内的root用户映射到宿主机的高位UID（如100000），实现用户权限隔离。这是防止容器突破的重要防线。
• 使用AppArmor或SELinux：为LXC容器配置AppArmor或SELinux策略，可以限制容器内进程的文件系统访问、网络能力等。这需要内核和根文件系统的额外支持。
• 只读根文件系统：如果容器内的应用不需要写入根文件系统，可以在配置中设置lxc.rootfs.options = ro，或者将根文件系统挂载为只读。结合tmpfs挂载到/tmp和/var/tmp，可以为应用提供必要的临时写入空间。

5.4 性能监控与调试

• 资源监控：通过/cgroup/memory/lxc/testbox/memory.usage_in_bytes等文件可以实时读取容器的资源使用情况。也可以使用lxc-cgroup命令查询。
• 日志：容器内进程的输出，默认会混在宿主机的系统日志中（如/var/log/messages）。可以在配置文件中使用lxc.console = none和lxc.console.logfile = /var/log/lxc/testbox.log将容器的控制台输出重定向到独立文件。
• 调试工具：lxc-attach命令（如果SDK版本支持）可以直接进入一个运行中容器的命名空间，就像docker exec一样，非常方便调试。如果不支持，可以通过nsenter命令组合/proc/<pid>/ns目录下的文件来实现类似功能。

6. 常见问题与排查技巧实录

在实际部署中，我踩过不少坑。这里把一些典型问题和解决方法记录下来，希望能帮你节省时间。

问题1：容器启动失败，报错“Failed to create cgroup ...”

• 排查：首先检查/cgroup目录是否成功挂载（mount | grep cgroup）。然后检查该目录的权限，确保root用户有读写权限。有时，某些cgroup子系统（如memory）可能因为内核配置或启动参数未启用。检查/proc/cgroups文件，看所需子系统是否已挂载（非0）。
• 解决：确保内核配置正确，并在启动脚本中正确挂载cgroup。可以尝试手动挂载特定子系统：mount -t cgroup -o memory memory /cgroup/memory。

问题2：容器内网络不通，无法ping通网关或外网

• 排查：这是最常见的问题。按照4.3节的网络故障排查步骤进行。额外检查宿主机是否开启了IP转发：sysctl net.ipv4.ip_forward，需要为1。如果容器需要访问外网，还需在宿主机上设置NAT规则：

  iptables -t nat -A POSTROUTING -s 192.168.10.0/24 -o eth0 -j MASQUERADE

  （假设eth0是宿主机的对外网卡）。
• 解决：确保网桥br0已启动并配置IP；确保veth接口已加入网桥；确保宿主机IP转发和防火墙（iptables）规则配置正确。

问题3：容器启动后，控制台无响应，或者立即退出

• 排查：检查容器配置文件中的lxc.tty和lxc.pts设置是否正确。检查容器根文件系统rootfs中是否有正确的/dev节点（特别是/dev/console,/dev/tty1,/dev/pts/*）。使用lxc-start -n testbox -F -l DEBUG在前台启动并输出详细调试日志，观察错误输出。
• 解决：确保busybox模板正确创建了设备节点。有时需要手动在容器rootfs中创建/dev目录并挂载devtmpfs或使用mknod创建设备。更简单的方法是确保宿主机内核配置了CONFIG_DEVTMPFS和CONFIG_DEVTMPFS_MOUNT，并在容器配置中添加lxc.mount.entry = /dev /var/lib/lxc/testbox/rootfs/dev none bind,optional 0 0（注意，这会共享宿主机的/dev，降低安全性）。

问题4：容器内进程内存使用超出限制，但未被杀死

• 排查：cgroup的memory.limit_in_bytes限制的是用户内存+内核数据结构（如slab）等。如果进程大量使用文件缓存，这些缓存可能被计入memory.usage_in_bytes，但当系统内存紧张时，内核会优先回收缓存，所以不一定会触发OOM Killer。真正触发OOM的是memory.memsw.limit_in_bytes（内存+交换分区）。
• 解决：同时设置memory.limit_in_bytes和memory.memsw.limit_in_bytes。注意，如果系统未启用交换分区，设置memsw限制可能无效。对于关键容器，可以设置memory.oom_control = 1来完全禁用OOM Killer对该容器的干预（风险自负）。

问题5：在多核QorIQ处理器上，容器性能不达预期

• 排查：检查容器是否被正确地绑定到了CPU核心上。使用lxc-cgroup -n testbox cpuset.cpus查看绑定情况。使用top或htop在宿主机观察，容器进程是否只在指定的核心上运行。
• 解决：使用cpuset.cpus将容器绑定到物理核心。注意处理器的NUMA架构，如果可能，将容器绑定到同一个NUMA节点内的核心，并分配该节点本地内存（通过cpuset.mems），可以获得最佳性能。避免将单个容器绑定到超线程（SMT）的逻辑核心对上，这可能引入资源争用。

通过以上步骤和要点，你应该能够在QorIQ平台上顺利地部署和管理LXC容器。这套轻量级虚拟化方案，为嵌入式系统带来了前所未有的灵活性、隔离性和资源利用率，是构建下一代高可靠、易维护的嵌入式软件架构的利器。