As a SysAdmin I have been using OpenVZ since it was introduced, and trust me it has not always been this easy. I used to take care of 20 physical servers with yearly replacement of about 5 machines. Since some of the servers are running different Linux distributions and different hardware it was decided that to standardize all servers, OpenVZ was to be deployed so that all of them are running Debian stable.
OpenVZ is container-based virtualization for Linux and it only separates the different guest servers in terms of resources. This differ from other implementations such as VMware, Xen, and VirtualBox where these involve hardware virtualization. Because of this, the guests called VE or VPS have the same kernel version and can only run Linux. What distribution as guest? The choice is yours.
Undoubtedly most of you have heard of Virtuozzo – it’s running OpenVZ. As a matter of fact the company that produces Virtuozzo is the one funding and supporting the development of OpenVZ.
The fact that it can run any distribution you like means that you can study and learn how to maintain different distributions. Even the littlest difference can confuse a rookie SysAdmin, for example:
- Debian apache’s init script is distributed as
/etc/init.d/apache
and/etc/init.d/apache2
while in CentOS it’s called/etc/init.d/httpd
- In Debian to change init scripts and runlevels we use update-rc.d while in CentOS we use chkconfig even though they both do the same exact thing
There are many other differences in terms of implementation that I rather not discuss here.
Click on Continue Reading if you’re interested to read more…
Enter OpenVZ
In the early days to have an OpenVZ kernel running stably there are problems which are case by case basis. Sometimes a kernel compilation is needed, sometimes the userspace utility vzctl
needs to be recompiled, sometimes a hack is needed to make sure that memory was allocated correctly, etc.
Sometimes, if we’re lucky we can install the provided RPMs (for CentOS) and also use the third party repository for Debian.
I was excited a few days ago that OpenVZ-enabled kernel has now entered the official Debian repository. Bravo! Debian Kernel Team.
Priority: optional
Section: admin
Installed-Size: 57964
Maintainer: Debian Kernel Team <debian – [email protected]>
Architecture: i386
Source: linux-2.6
Version: 2.6.26-4
Provides: linux-image, linux-image-2.6, linux-modules-2.6.26-1-openvz-686
Depends: module-init-tools, vzctl, initramfs-tools (>= 0.55) | yaird (>= 0.0.13) | linux-initramfs-tool
Pre-Depends: debconf | debconf-2.0
Recommends: libc6-i686
Suggests: linux-doc-2.6.26, grub | lilo
Conflicts: initramfs-tools (<<0.55), yaird (<< 0.0.13)
Size: 20244714
Description: Linux 2.6.26 image on PPro/Celeron/PII/PIII/P4, OpenVZ support
This package provides the binary image and pre-built loadable modules for
Linux kernel 2.6.26 on Pentium Pro/Celeron/Pentium II/Pentium III/Pentium
4 machines.
.
This kernel includes support for OpenVZ container-based virtualization.
And since I was also installing Hardy Heron, I was also impressed that OpenVZ is already in the “universe” component (does not have guarantees of support). Back when I was using Feisty Fawn I had to use the kernel package from debian.systs.org.
Enter Ubuntu
$ sudo apt-cache search openvz
$ sudo apt-get -s install linux-openvz
Why Is The Official Packages Better?
The official packages are better in terms of the customizations done on the distribution you are using (the host). For example Red Hat / CentOS is excellent in hardware support (you’ll understand the pain if you have new or exotic hardware). There are lots other kernel customizations that are being done by distributions that are beyond my understanding. True, Linux is the kernel and vanilla kernel will work but certain distribution features might be muted, if not causing errors.
And of course, I was stuck using 2.6.18 for a while because that’s the stable version of the OpenVZ kernel available from the “3rd party” OpenVZ, when people are already jumping on the 2.6.24 bandwagon.
– –
As for now, I am waiting for the OpenVZ kernel installation to be completed on my Ubuntu and I believe it will be honky-dory. Since Ubuntu documentation has described installing OpenVZ I think I will not replicate their (very good) document here.
You are, however welcome to ask questions that I may know how to answer based on my experience with OpenVZ. Be warned that I don’t know everything, and am just a learner like you.
Does it mean that the guest OS is using exactly the same hardware as the host OS?
The guest OS does not even care about the hardware so hardware dependent layers such as sound will not work out of the box. But the guest can access certain /dev nodes on the host for example for X to display on pty8, and sound – but we must give proper permissions.