创build一个只用于包pipe理的“主”OpenVZ客人是否可行？在其他几个OpenVZ客户机上使用像mount --bind这样的东西，可以诱骗他们使用主客人安装的环境？
这样做的目的是让用户可以维护自己的容器，并且与主开发环境保持同步，这样他们将永远拥有最新和最大的需求，而不用担心太多的系统pipe理。 如果他们需要安装自己的软件包，可以把它们放在/ opt或者/ usr / local（或者设置一个path到他们的主目录）？
换个angular度来说，我想要几个（开发者的）OpenVZ客户，它们的/ bin，/ usr（等等）实际上是指与可以启动安装的主OpenVZ客户相同的磁盘位置并更新所有这些OpenVZ客户共享的环境共享包。
对于它的价值，我们正在运行Debian 6。
编辑：
我试过以这种方式挂载（绑定，只读）/ bin，/ lib，/ sbin，/ usr，它拒绝启动容器，说明文件已经挂载或者正在使用中：
Starting container ... vzquota : (error) Quota on syscall for id 1102: Device or resource busy vzquota : (error) Possible reasons: vzquota : (error) - Container's root is already mounted vzquota : (error) - there are opened files inside Container's private area vzquota : (error) - your current working directory is inside Container's vzquota : (error) private area vzquota : (error) Currently used file(s): /var/lib/vz/private/1102/sbin /var/lib/vz/private/1102/usr /var/lib/vz/private/1102/lib /var/lib/vz/private/1102/bin vzquota on failed [3]
如果我卸载这四个卷，并启动guest虚拟机，然后在guest虚拟机启动后挂载它们，则guest虚拟机永远不会看到它们挂载。
根据评论，这个问题与我（也许是其他人）所期望的有些不同：“维护”的使用与容器内的软件包无关，而是与其各自的configuration有关。
这使得这个过程更加困难，但仍然有可能。 例如：
正如你所说的，你将需要共享一个二进制文件（例如/usr/bin ），这将是确保他们可以共享所有软件包的第一步 – 这将允许安装的二进制文件一应俱全到所有的其他容器。
您需要确保在mount --bind – 在适当的/etc/vz/<veid>.conf文件的ROOT目录中执行此操作。
例如， mount --bind /some/mount/point/bin /vz/root/1/bin
这些支架是干净的（如何确保在机器第一次启动后它们在那里）？ 为此，OpenVZ以脚本的forms提供启动和停止钩子。 假设你在/etc/vz/conf ，你可以有：
/etc/vz/conf/<veid>.mount – 这是起始钩子：在容器运行时调用 /etc/vz/conf/<veid>.umount – 这是停止钩子：当容器closures后调用 他们的名字来源于他们的技术定义：OpenVZ mounts /vz/private/<veid>到/vz/root/<veid> ，这就是它的挂钩（假设默认目录）。
在评论中，你曾经质疑过一个优点是他们可以configuration他们的服务器，比如mysql.cnf或者httpd.conf / apache2.conf 。 我可以看到的唯一问题是，您需要确保在安装软件包时，这些configuration文件将在每个容器中进行设置。 您可以尝试在写入共享上共享安装副本 。
这个问题正是要分享哪些目录。 Apache在/etc/httpd和MySQL在/etc/mysql – 所以你需要确保你复制这些股票文件，否则这个想法将无法正常工作。 就我个人而言，我会检查由您的'全球'包pipe理员安装的.deb文件，并提取出不共享到个别容器的任何目录。 但是，这只是单一的做法 – 我相信还有更多。
我想到的一件事是你可以直接replace软件包附带的二进制文件和库，但是你需要观察软件包pipe理器在安装之后是否重新启动服务
您正在装载private ，您需要装载到/var/lib/vz/root/1102/bin目录（假设这是根指向您vz的.conf文件中的位置）。
杰伊有正确的答案来执行它，但你不知道是否你想升级人员的容器，而东西运行。
我认为你仍然希望将系统目录以只读方式装载到它们的容器中，但是你想要对这些系统目录进行版本控制，并且希望它们将自己的软件安装到他们的主目录或者从容器外绑定的地方。
当用户需要最新版本时，应使用更新的模板重新创build其CT。 每次升级时，都可以将其保存为CT模板。 这使系统保持稳定，但他们可以随时要求升级。