Home / server / Questions / 404151
Accepted
andyortlieb
Asked: 2012-07-03 10:12:13 +0800 CST

Sharing disk volumes across OpenVZ guests to reduce Package Management Overhead

  • 772

Is it feasible to create a single "master" OpenVZ guest who would only be used for package management, and use something like mount --bind on several other OpenVZ guests sort of trick them into using the environment installed by the master guest?

The point of this would be so that users can maintain their own containers, and yet stay in sync with the master development environment, so they'll always have the latest & greatest requirements without worrying too much about system administration. If they need to install their own packages, could put them in /opt, or /usr/local (or set a path to their home directory)?

To rephrase, I would like several (developer's, for example) OpenVZ guests whose /bin, /usr (and so on...) actually refer to the same disk location as that of a master OpenVZ guest who can be started up to install and update common packages for the environment to be shared by all of this group of OpenVZ guests.

For what it's worth, we're running Debian 6.

Edit:

I have tried mounting (bind, and readonly) /bin, /lib, /sbin, /usr in this fashion and it refuses to start the containers stating that files are already mounted or otherwise in use:

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]

If I unmount these four volumes, and start the guest, and then mount them after the guest has started, the guest never sees them mounted.

linux debian mount package-management openvz

2 Answers

  1. Best Answer

    Based on the comments, the question is a little different to what I (and maybe others) expected: the use of "maintain" doesn't relate to the packages within the containers, but their individual configuration.

    This makes the process more difficult, but still possible. For example:

    Mounting the directories

    As you've said, you'll need to share a mount for the binaries (such as /usr/bin) which would be the first step in ensuring they can share all the packages - this will allow the installed binaries to be readily available to all of the other containers.

    You need to ensure that when you mount --bind - you do this on the ROOT directory in your appropriate /etc/vz/<veid>.conf file.

    For example, mount --bind /some/mount/point/bin /vz/root/1/bin

    It's also essential that these mounts are clean (how to do you ensure that they are there after the machine boots the first time?). To do this, OpenVZ offers start and stop hooks in the form of scripts. Assuming you are working within /etc/vz/conf, you can have:

    • /etc/vz/conf/<veid>.mount - this is the start hook: called once the container is running
    • /etc/vz/conf/<veid>.umount - this is the stop hook: called once the container has shut down

    Their names are derived from their technical definitions: OpenVZ mounts /vz/private/<veid> onto /vz/root/<veid> so that's what it's hooking (assuming the default directories).

    Configuration

    In the comments, you've queried that one advantage would be that they could configure their server how they like (e.g. mysql.cnf or httpd.conf/apache2.conf). The only issue I could see with this is you need to ensure that when you install the packages, these configuration files are setup inside each of the containers. You could try sharing a mount copy on write share.

    The issue with this is exactly which directories to share. Apache it over at /etc/httpd and MySQL at /etc/mysql - so you need to be sure that you copy these stock files over or this idea won't work. Personally I'd inspect at the .deb files that are installed by your 'global' package admin, and extract out any directories that aren't shared into individual containers. But, this is just a single way of doing it - I'm sure there are a fair few more.

    Gotchas

    One thing I came up with is that you can just straight replace the binaries and libraries that come with a package, but you need to observe whether or not the package manager restarts services after installing it

    Error in your post

    You are mounting on private, you need to mount on the /var/lib/vz/root/1102/bin directory (assuming that's where the root points to in your vz's .conf file).

    • 2

  2. Jay has the correct answer for implementing it as you ask, but I'm not sure if you want to upgrade people's containers while stuff is running.

    I think you still want to mount system directories as read-only in their containers, but you want to version those system directories and you want them to install their own software into their home directory or somewhere that is bind mounted from outside their container.

    When the user wants the latest version, you should recreate their CT using your updated template. Each time you upgrade, you can save it as a CT template. This keeps their systems stable, but they can ask for an upgrade at anytime.

    • 1