试图保持在红帽的优雅之中，并且仍然计划系统寿命，这是非常棘手的。
我一直是Linux容器（LXC）的支持者。 我最初的安装是基于从在线教程收集的信息，就像这个和这个一样 。 这以lxc-create ， lxc-start|stop和lxc-destroy命令为中心，并修改了现有的OpenVZ模板 。
这运作良好，并愉快地生产运行。 但是，我提出了一些额外的系统，并决定检查红帽目前关于EL6容器的文档。 我很惊讶地看到他们在这方面的官方立场。
在RHEL 6中是否提供了使用Linux容器所需的LXC工具？ ，Red Hat将LXC描述为技术预览，并build议使用libvirt来pipe理创build和pipe理容器 。
然而，Oracle在Unbreakable Linux中提倡完全不同的容器化技术 。
在libvirt方法中似乎有一些缺失的function，但我最初使用lxc- *命令的方法是一些手动过程…我不能完全知道什么是正确的，或者在EL6上pipe理容器的“接受”方法。
关于当今LXC和RHEL系统的传统观点是什么？
就我个人而言，我觉得目前的设置有点欠缺。 LXC似乎更多地在前列 – 当然更加保持。
你如何执行它们？
提供它作为一个虚拟化选项，我不是。 我发现目前的技术设置不足。
但是，我发现它确实是应用程序级别遏制的好工具。 我们直接使用命名空间和cgroups来为某些用户运行的Web应用程序包含networking和IPC资源。 我们提供我们自己的界面来控制它。 在RHEL7中，我正在考虑将这个function移植到libvirt-lxc因为libvirt-lxc的更新版本支持用户ACL的概念。
对于完全初始化系统的虚拟化，我正在等待RHEL7提供的内容，但是在所有的情况下，我觉得一旦我们稍后再次发布RHEL7，我们可能只会看到一个足够好的解决scheme，只在技术预览状态。
关注systemd-nspawn在未来18个月左右的时间里，告诉我可能取代它的地方是完全使用linux进行虚拟化的最佳工具，不pipe系统开发者是否明确表示它现在不安全！ 如果libvirt最终丢弃了libvirt-lxc并且提供了systemd-nspawn的包装，并且定义了systemd切片，我不会感到惊讶。
另外，在过去的6个月里，在重新实现cgroups作为内核程序员接口而不是文件系统接口（也许使用netlink或者其他的东西，没有检查过）方面，我们要多加小心，所以systemd应该是非常热的在得到那个权利的尾巴很快。
一种方法和另一种方法有什么优点？
我认为LXC选项（不是libvirt-lxc）可以更好地维护。 读过libvirt-lxc源代码后，感觉很慌。 传统的LXC当然有更新的function，经过了更好的testing。 两者都需要一定程度的兼容性，但是我怀疑你会发现LXC比libvirt-lxc选项稍微有点“交钥匙”，特别是在获取发行版的方面。
这些可以共存吗？
当然，请记住，对于所有的意图和目的，两者都在做同样的事情。 组织命名空间，cgroups和挂载点。 所有的原语都是由内核自己处理的。 这两个lxc实现都提供了一个与可用的内核选项接口的机制。
红帽正在进行巨大的集装箱化推动。 他们正在构build一个全新的产品， 红帽企业Linuxprimefaces主机 。
对于一个不那么激进的方法，看看他们的RHEL7 beta 资源pipe理和Linux容器指南 ; 你会注意到它推动libvirt-lxc，并没有提到lxc工具。
lxc- *可执行文件被封装在EPEL的lxc软件包中。 不过这是旧的“长期支持”版本。 在lxc-ls中甚至没有“-f”选项。 我只需要为我的LXC主机安装Ubuntu。
RHELpipe理LXC的方法似乎是通过libvirt-lxc，但显然已被弃用 。
注意到Ubuntu支持许多新的lxc / lxd开发，而Redhat专注于KVM和Docker。