Revision as of 02:14, January 31, 2014

Introduction

OpenVZ (see wiki.openvz.org) is an OS-level server virtualization solution,
built on Linux. OpenVZ allows the creation of isolated, secure virtual Linux containers (called "VE"s) on a single physical server. Each container has its own local uptime, power state, network interfaces, resource limits and isolated portion of the host's filesystem. OpenVZ is often described as "chroot on steroids."

Funtoo supports OpenVZ in the following ways:

Building of OpenVZ templates using Metro, our distribution build tool.

Improvement of vzctl, by developing an improved/patched version hosted on GitHub.

Integration of Funtoo Linux Networking support into vzctl (these patches have been accepted upstream by the OpenVZ project.)

Improvement of vzctl startup scripts to do things like properly initialize veth and vzeventd.

Integrating additional patches into openvz-rhel6-stable and openvz-rhel5-stable ebuilds in order to ensure production-quality OpenVZ functionality.

Maintaining compatibility with production RHEL5-based OpenVZ kernels, as well as instructions on how to get Funtoo Linux set up for these kernels in our RHEL5 Kernel HOWTO. (Note: openvz-rhel6-kernel RHEL6-based kernel is now the recommended kernel for deploying OpenVZ.)

Recommended Versions

For setting up OpenVZ on Funtoo Linux so that you can create Linux-based containers, an x86-64bit version of Funtoo Linux is strongly recommended. The openvz-rhel6-stable ebuild is the recommended kernel to use. If you emerge this kernel with the binary USE flag enabled, it will build a binary kernel and initrd using the default Red Hat configuration which should boot on nearly all hardware. After emerging, you will need to edit /etc/boot.conf, run boot-update, and reboot into the new OpenVZ kernel.

Alternatively, you could emerge openvz-rhel5-stable with the binary USE flag enabled to use the older RHEL5-based OpenVZ kernel. This requires additional steps which are covered in the RHEL5 Kernel HOWTO.

You will also need to emerge vzctl, which are the OpenVZ userspace tools.

Configuration

After booting into an OpenVZ-enabled kernel, OpenVZ can be enabled as follows:

# emerge vzctl
# rc-update add vz default
# rc

Funtoo Linux OpenVZ Templates

The Funtoo Linux stage directory also contains Funtoo Linux OpenVZ templates in the openvz/ directory. These can be used as follows:

Starting the Container

Networking

veth networking

OpenVZ has two types of networking. The first is called "veth", which provides the VE with a virtual ethernet interface. This allows the VE to do things like broadcasting and multicasting, which means that DHCP can be used. The best way to set up veth networking is to use a bridge on the physical host machine. For the purposes of this example, we'll assume your server has a wired eth0 interface that provides Internet connectivity - it does not need to have an IP address. To configure a bridge, we will create a network interface called "br0", a bridge device, and assign your static ip to br0 rather than eth0. Then, we will configure eth0 to come up, but without an IP, and add it as a "slave" of bridge br0. Once br0 is configured, we can add other network interfaces (each configured to use a unique static IP address) as slaves of bridge br0, and these devices will be able to communicate out over your Ethernet link.

Let's see how this works.

Network - Before

Before the bridge is configured, we probably have an /etc/conf.d/netif.eth0 that looks like this:

{{{body}}}

Network - After

To get the bridge-based network configured, first connect to a physical terminal or management console, as eth0 will be going down
for a bit as we make these changes.

We are now going to set up a bridge with eth0's IP address, and add eth0 to the bridge with no IP. Then we can throw container interfaces into the bridge and then can all communicate out using eth0.

We will mv netif.eth0 netif.br0, and then edit the file so it looks like this (first line modified, new line added at end):

{{{body}}}

If you want to bridge the wlan0 device, you'll need the additional wpa_supplicant flag -b br0.
In most cases for wlan0 it is much better to use a route:

The result of these changes is that you now have initscripts to create a "br0" interface (with static IP), with "eth0" as its slave (with no IP). Networking should still work as before, but now you are ready to provide bridged connectivity to your virtual containers since you can add their "veth" interfaces to "br0" and they will be bridged to your existing network.

Using The Bridge

Once the VE is started, the network interface inside the VE will be called "eth0", and the network interface on the host system will be named "veth100.0". Because we specified "br0" after the 4 commas, vzctl will automatically add our new "veth100.0" interface to bridge br0 for us. We can see this by typing "brctl show" after we have started the VE by typing "vzctl start 100".

VE Configuration

You will also need to manually configure the VE to acquire/use a valid IP address - DHCP or static assignment will both work; typically, this is done by starting the VE with "vzctl start 100" and then typing "vzctl enter 100", which will give you a root shell inside the VE. Then, once you have configured the network, you can ensure that the VE is accessible remotely via SSH. Note that once inside the VE (with "vzctl enter 100"), you configure the VE's network interface as you would on a regular Linux distribution - the VE will be bridged into your LAN, so it can talk to your DHCP server, and can use an IP address that it acquires via DHCP or it can use a static address.

venet networking

"venet" is OpenVZ's other form of host networking. It can be easier to configure than veth, but does not allow the use of broadcast or multicast, so DHCP is not possible on the VE side. For this reason, an IP address must be statically assigned to the VE, as follows:

When using venet, OpenVZ will handle the process of ensuring the VE has its network properly configured at boot. As of vzctl-3.0.24.2-r4 in Funtoo Linux, Funtoo Linux VEs should be properly auto-configured when using venet.

With venet, there is no need to add any interfaces to a bridge - OpenVZ treats venet interfaces as virtual point-to-point interfaces so that traffic is automatically routed properly from the VE to the host system, out the default route of the host system if necessary.