Do you need to setup a new application or service in a virtual environment using a current version of Linux or Unix and don’t want to expend a lot of energy or money? If so, then OS-level virtualization deserves a second look. OS-level virtualization or operating system level virtualization means that a single kernel is shared amongst all virtual machine (VM) instances though each VM is separated logically from all other instances. This is the most basic type of virtualization available and is the path of least resistance for getting those applications up and running quickly and securely.
OS-level virtualization might have the most synonyms of any other type of virtualization. It’s known as shared-kernel virtualization, system-level virtualization, containers, zones, jails, change rooted (chroot) jails, virtual private server virtualization, and maybe others. Whatever you call it, you will call it the best performing virtualization strategy you’ve ever encountered. The overtly lazy among you may refer to it simply as jails.This type of virtualization shares not only the kernel with its VMs but also the disk, memory, and basic filesystem structure giving it the best performance of any of its counterparts.
In a world where everyone wants to sell you something; OS-level virtualization is free (Free as in no cost — since I’ve never had any of that free beer I’ve heard so much about). The capability to create a jail comes with your operating system and requires very little time or effort from a system administrator to setup. In a nutshell, the administrator creates a directory tree to house an application, populates it with libraries, binaries, and other supporting files, edits the configuration files to point to the jailed application using the chroot utility, and finally starts the application inside the jail.
The jail provides the necessary environment to run the application with no extras. A user on the jailed system is limited to that environment and isn’t aware of the host at all.
And, if you’re somewhat lazy about security, this type of virtualization provides a high level of security for the host system. Protecting the host system from attacks is the number one reason for implementing OS-level virtualization. The theory is that, if the VM falls prey to a hack attack and is compromised, your host system is preserved since the attacker remains jailed in the application VM with only the credentials of the non-privileged application user.
You aren’t limited to the particular Linux distribution running on your host, though your VMs are limited to the host’s running kernel. Any distribution that can use your running kernel can be used in a VM. To run different distributions in your VMs, you’ll need to use an add-on product such as OpenVZ, Linux-Vserver, or FreeVPS.
There are some limitations to OS-level virtualization despite high number of plus-side attributes. The single kernel restriction may disuade you from using this method since all of your VMs depend on that single kernel for operational stability. It is the only kernel that receives an update and you can’t experiment with alternative kernels. The shared kernel is a single point of failure for all VMs on the host system. This is a significant drawback to this virtualization technology and the seriousness shouldn’t go unrecognized.
One of the advantages that I listed states that using chrooted applications provides extra security for the host machine. It does. It does not, however do so for the VM. The VM is still just as vulnerable as it ever was. The purpose behind using jailed applications is not to necessarily protect the VM but to protect the host. We aren’t sacrificing the VM. We are protecting it by using a non-privileged account to run the application, limiting the number of users on the VM, and changing the VM’s root password to something different from the host’s.
Some of you might find it too restrictive to use a single operating system for every service. OS-level virtualization does have that shortcoming. You can’t, for example, run Windows VMs, Solaris/OpenSolaris VMs, or support any operating system that can’t use the host’s running kernel.
OS-level virtualization is an easy and inexpensive way to add an extra layer of protection for your host systems in spite of the few drawbacks to the technology. It’s a bonus feature of all Unix and Linux systems and one that you should add to your virtualization strategy. Consider it strongly for mail, DNS, web, services that don’t necessarily need their own fully virtualized VM, and for services whose compromise would make other data and services vulnerable.
An example of an actual installation would make this REALLY valuable. The devil is always in the details.
Chroot is fantastic! I use it to “virtualize” separate linux distribution environments on my running Ubuntu 8.10 (64 bit) system.
As I type I’m rebuilding a customized slackware 12.1 kernel in one of my chroot environments. I use it as a psuedo-cross compile environment for a SBC target. Combine that with “mount -o bind” and I can have all my development files on my native system and mount them into the chroot for building.
Here’s how I setup my chroots (slackware 11.0 and 12.1): http://slackworld.berlios.de/2007/chroot_howto.html
The same can be done for .rpm based distros or .deb based.
I have to comment on one point made in the article: “The single kernel restriction may disuade you from using this method since all of your VMs depend on that single kernel for operational stability. It is the only kernel that receives an update and you can’t experiment with alternative kernels. The shared kernel is a single point of failure for all VMs on the host system. This is a significant drawback to this virtualization technology and the seriousness shouldn’t go unrecognized.”
The linux kernel gets more testing than VMware or any other VM solution. I trust its stability more than ANY VM out there.
In addition, the Linux development process is wide open and highly optimized. Git is an amazing SCM tool. I’ve used a bunch of other SCM tools and Git spanks them all. Linux kernel developers are highly talented, have a great process and the best (I think) SCM tool made.
@w7hd
I agree. The Devil is in the Deatils.
For the most common uses virtualization isnt useable anyway.
i also cant understand why the virtualization thing is now so much pushed.
virtualization is a technical method to solve some things but far far far not the all in one solution and sadly but true for the most users (special all small companys) its not necessary and often not useable.
sometimes its the best solution, sometimes (more often) its not.
And do not forget. Every single instanze want to have same amount f time for management (monitoring/updates…) than a classic shared system. Most of my customers profit from our well optimzed and monitored shared systems instead of getting their own virtserver where they have to invest again much time for the management (or money to us)
shared systems (one of the biggest advantages of linux) have a huge adanvantage agianst virtualized ones. shure there are reasons for them no question
but far not that important that the industry try to sell us.
@w7hd,
You’re right, an example would be nice but these short articles are not appropriate for that kind of detail. An article describing that level of detail would need between 2K to 3K words.
For a good look at a chrooted Apache, check this link: Apache Chroot How To
@bofh999
Virtualization is great for ISPs. Most large-scale use some form of virtualization since dedicating entire systems is too costly and sharing services between lots of customers is, well, not very secure.
OS-Level virtualization for ISPs is a very efficient and secure way to provide services to clients–it still offers the “shared” resources concept with a far higher level of security and partitioning.