OpenVZ [LWN.net]

OpenVZ

Posted Aug 6, 2008 14:26 UTC (Wed) by michaelkjohnson (subscriber, #41438)
In reply to: Also absent... by dowdle
Parent article: Building custom appliance distributions with rBuilder

Because I am not an OpenVZ expert, I'm responding only because you ask me specifically... I have not worked with OpenVZ, I have merely read some docs, so I reserve the right to be completely and utterly wrong! In particular, it is not obvious to me from the OpenVZ documentation whether there needs to be OpenVZ-specific program content within an OpenVZ guest container. I am operating on the assumption that the guest container does not require additional code. That caution aside:

Conary "groups" effectively play a similar role to OpenVZ "templates", and one image type rBuilder builds is a compressed tar archive. Because rPath Linux uses network and initscripts configuration in the RH style, the instructions for modifying the contents of any RH-based OS, including CentOS, should be relevant for modifying the contents of that tarball to make a valid cached template.

rBuilder itself is not directly related to two other ways that rPath's technology could potentially interface/interact with OpenVZ:

Packaging with Conary the necessary tools (which I presume to be vzpkg, vzctl, vzquota and any necessary dependencies, as well as an OpenVZ kernel) to use an rPath Linux-based operating system an OpenVZ host.
Changes to OpenVZ tools to work with Conary: The vzpkgcache utility itself knowing how to use Conary to populate a template -- something like conary update group-myappliance=myproduct.rpath.org@me:1 --root /path/to/vz/chroot which -- vzpkgcache could then deploy as it normally does. Additionally, vzpkg having Conary-specific functionality, such as passing through conary commands as it does for rpm and dpkg, and maybe recognizing system image tarballs and/or URLs to tarballs as a template source, similar to package lists.

As far as I know, the contents of an OpenVZ guest do not need to be related to the contents of the host except inasmuch as they are running under the same kernel image. So a Novell-based or Fedora-based or anything-else-based host with the OpenVZ tools installed should be able to deploy rPath-based images in an OpenVZ container.

If OpenVZ containers require specific code customization for OpenVZ, we certainly have a way to deal with it (we call it "flavors", and we have xen and vmware flavors among others). It does seem, though, that some of the customization is site-specific, which makes me think that since there is site-specific customization anyway, there's not a lot of value to match the cost of maintaining extra flavors in the base OS.

I certainly welcome responses and corrections.

(Log in to post comments)

tarball images

Posted Aug 8, 2008 12:48 UTC (Fri) by michaelkjohnson (subscriber, #41438) [Link]

rBuilder is able to create tarball images, but not every product has tarball images created by its developers. There are a lot of image types and not all are relevant to every product. Furthermore, just because a tarball image has been created does not mean that it would be the correct images for deploying under OpenVZ. I have built them for deployment as Xen domU instances. I would suspect that for OpenVZ you do not want Xen-specific tools and configuration.

I was addressing the question of whether rBuilder provides the capability to support building OpenVZ guest images. As far as I can tell, the base technical capability of building tarball images provides what is needed, and the rest is just a new OS Template.

The rPath Linux 2 release you link to, announced on our blog and described at our wiki, is intended to be a base OS from which to create your own works, and so has a rather small sample of image types built. It's certainly not exhaustive; we created what we thought would be the most commonly-used types. Perhaps we should consider adding tarball images to those types -- the question would then be: tarball images of what? The most common deployment scenario to date for a tarball image has been a Xen domU. It's not that hard to convert a Xen domU tarball to a non-Xen install (the exact command depends on the image installed), but that doesn't preclude releasing non-Xen tarball images. It's essentially a question of sufficient interest to make it worth doing the extra work for each new release to add the image type to the build script.

Outputing OpenVZ compatible .tar.gz files for use inside of containers

Posted Aug 8, 2008 16:11 UTC (Fri) by dowdle (subscriber, #659) [Link]

MKJ,

Thanks for replying. I don't think there is much interest in rPath / rBuilder generating an
OS image for an OpenVZ host node... what we would like see added would be the ability for your
users to output OpenVZ compatible OS Templates for running inside of containers. These "OS
Templates" of which I speak are nothing more than a .tar.gz file of an installed Linux
distribution with the desired applications installed and perhaps some application
configuration modifications.

How does the OpenVZ OS Template differ from simply .tar.gz'ing up the root filesystem of a
Linux distribution from a physical machine? OpenvZ OS Templates are subsets of those mostly
with unneeded software and services removed. For example, there is only one kernel running on
the system and it is on the host node and is not needed in the container so that is
stripped... as are unnecessary services like udev, usually anything related to a desktop
environment, etc. That's probably getting into the details that you don't care about.

Most of the configuration settings that would make a container unique (hostname, ip address,
and DNS settings, desired resource settings) are stored are not stored within the OS Template
but in a container specific configuration file on the host node. When a container is created
from an OS Template and started, values are read from the container's configuration file on
the host node and config files inside of the container are modified to give the container its
unique network settings and resources.

I believe you asked if there was any OpenVZ specific software installed inside of the
containers. The answer to that would be no... BUT as I mentioned, a typical Linux
distribution's default set of packages has been trimmed down quite a bit.

Did I address the issues you needed additional information on?

BTW, kolyshkin is Kir Kolyshkin who is the OpenVZ Project manager.

OpenVZ OS Templates and rBuilder

Posted Aug 8, 2008 22:14 UTC (Fri) by michaelkjohnson (subscriber, #41438) [Link]

OpenvZ OS Templates are subsets of those mostly with unneeded software and services removed.

In a nutshell, that's also essentially what appliance images created on rBuilder are.

I'll provide more detail. There are two key Conary technology concepts that matter here, flavors and groups. I'll start with groups.

In legacy packaging systems, you have lists of packages, which may be nested and/or grouped in various ways. Examples include RH/Fedora "comps.xml" and Debian "tasks". In all of these cases is that this list is essentially a form of source code. There is some client software that process that list and makes install-time decisions about versions of each individual package -- rather like compiling at install time, but the thing that is being compiled is a list instead of program source code.

By contrast, Conary builds lists of packages into a complete list of exact versions of all the contents, and so a single version of a "group" tells you the exact contents of every single file on the filesystem. So Conary compiles the list source code into a binary representation as a packaging action and stores it on the repository server; it's not a client install-time action.

Flavors describe all the different things that can happen when building a version. This includes things like x86 vs. x86_64 (instruction set architecture) and configuration characteristics that can include whether the binary is built for (say) VMware or Xen, as well as whether tcpwrappers, kerberos, and/or emacs support should be built into binaries. The combination of all these configuration elements is called a flavor.

Putting this together: Individual packages have flavors, and so do groups. Because a group specifies all the files included in the image, building an additional flavor of a group not only has a QA cost, but also simply takes significant build time; it adds complexity all around. This means that we do not lightly add new group flavors to the set of flavors we explicitly provide as part of our base operating system.

rBuilder can already create a .tar.gz file of a fairly minimal installation. We've been building images with "Just Enough OS" since before the "JeOS" term was coined. The normal way that you create a group that defines your own image is to say that you want a minimal functional operating system, plus the things you need, plus whatever is needed to satisfy the requirements of the things that you list explicitly. This means that the images are already quite small. One of the features of the second version of our operating system is that we cut roughly in half the size of the base functional operating system. In fact, we don't include a normal desktop in that version of our operating system at all -- we have GNOME bits only as needed to be able to build the Anaconda installer. However, we don't have a set of groups of our base operating system that are missing the kernel entirely. You can, when building your own groups that define your own images, specify a flavor that explicitly omits elements that are normally part of the base platform, such as the kernel, in order to optimize them for deployment as OpenVZ OS Templates.

So, from the information you've given me here, our images are actually pretty good bases to be deployed under OpenVZ, and if someone wants to further optimize versions of their images to be deployed under OpenVZ, they need merely to add a few lines in their group definitions and build an additional "flavor" or two, and build tarball images to match.

Hope that helps, and nice to (virtually) meet you!