Container-Based OS Virtualization

Isolation and Virtualization

While all the previous subjects document the changes required to an OS to even allow for containers, what we haven't discussed are the actual measures taken to create a seemingly separate OS environment for each container. This is handled by what we will call the "virtualization additions" of OpenVZ to the kernel. We put them in a slightly different group, because they are what actual make containers "look like" containers to their users.

As we know by now, to the kernel "containers" are nothing more than groups of processes with groups of users, using slightly different kinds of resource management and scheduling. They exist in an otherwise perfectly normal unified user space. To make a container look like a confined but complete space to users, some barriers need to be put in place to prevent them from seeing the complete picture. To this extent, virtualization is integrated into all parts of the OS.

For example, container-users (as well as their processes) can see only a standard root-directory structure, complete with virtualized /proc and /sys, adapted to include only their personal usage. Because each container has its own config files under /etc and contained processes are able to see only their own versions of these folders, users are able to change all configuration files and affect only their own setup.

In the above pictures, we can see a view of the container's directory structure, as seen from the host container, along with a view of the container's virtualized /proc from inside the container. Likewise, containers make use of virtualized process IDs, so a container user's process tree looks just like a normal tree. As each container has its own init process, the user's view of the tree is limited to that personal init and its child processes.

In this picture, we can see a full view of the host system's process tree (some processes are edited out to remove clutter). The inits below the original init are process groups for each of our containers. In the second picture, we can see the view of one of these containers' own process tree, namely the one running apache. As can also be seen in the picture, the process IDs inside the container are virtualized: while the init's PID is in reality 10371, the container believes it to be 1.

Moreover, network virtualization is implemented to allow each container to have its own (or even multiple) IP address. Traffic is isolated per container so that traffic snooping is impossible, and users can even set up their own firewall rules from within the container.

To this extent, OpenVZ makes use of two kinds of virtualized network interfaces: venet and veth. The first is the default used by every container and is a standard virtual device with limited options, mostly used to allow containers to have their own static IP address. veth is the heavyweight alternative, sporting its own MAC address, allowing it to be used in fully customized per-container network configurations.

In the above picture, we can see the two different kinds of interface implemented into containers. venet has no actual MAC address, and thus cannot be used in custom network configurations. The veth interface behaves just like a regular interface would, though it is a real heavyweight in comparison.