The Lazy System Administrator’s Way to Virtualize

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.

OS-Level Advantages and Disadvantages

Advantages:

Best Performance

Ease of Implementation

Available on all Linux and Unix flavors

Distribution Flexibility

Free

Easy to Manage

Host System Security

Disadvantages:

Single Kernel Restriction

Same OS for all VMs

Virtual Machine Vulnerability

Single Point of Failure

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.

OS-Level VM Security Reminders

Run chrooted Applications as Non-Privileged User

Remove All Privileged Accounts from Shadowed Password File

Include Only Necessary Files

One Service per VM

Comments on "The Lazy System Administrator’s Way to Virtualize"

w7hd

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.

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

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.

Im sorry but i have to absolutely dissagree.
First, its not unsecure if youve done things right. Shure you cannot give shell access, youll have to setup applicationfirewalls and configure your hole system real well.

youve to monitor your filesystem and maybe use vpn solutions for directacces some services for the customers. here also profiling user activities, profiling service activities.

but at the end it can be very secure. much more than a couple of houndres virtual systems for users.

as i said bevore the update problem (special securitiy update) and monitoring problem and do not forget the management of all these

shure in the theory 2 virtual instanzes for 2 users might be more secure and for “self service” customers sometimes right. But multiply it with 100 or 200 oder 2000 and youl see youre running into big problems.

you should not forget that a user is not only a security thread for your system he may also one by his own actions.
you cannot controll all users doing only their alowed busniess, maybe some of them using some kind of filesharing tasks on their virtual machines or something like that

or is used for dos attacs or whatever. try to monitor these things on virtual machines.

shure you can secure each virtual machine in the way i mean to secure a shared one but things changing very fast so you cannot held it up to date once its delivered.

also if your main system get hacked all of your virtual hosts are in danger anyway.

and what you gonna do to supprt all of your 2000 virtual hosts?

i tell you how to support it: you give every customer a webinterface like plexk and let him do his own job (where 70% of normal customers suffer) and sorry but i dont like things like plesk for security and flexibility reasons. many of our services would run if we use these stuff

ok so you delevop your own (maybe directory driven) system. ok thats good for supporting accounts like mail and ftp ob virtual hosts. but what you gonna do with other services you cannot implement?

uhh belive me, we drive both. real secure shared and for customers who really want virtual hosts (and that a long time bevore this hype began) and it isnt that easy, smart and happy new world with virtual hosts.

it is what it is the right solution for the right problems. but not the all in one answer with big big leaks.
shure most of these leaks are system specific/service specific
so have unix/special linux the big problem of missing an standard configuration db like windows servers

if its possible to get all daemons/hosts/services/settings/logs and monitors under one central controll these might be much different

but without that youre running and many (much more than ife described) problems in praxis by betting on the virtual horse.

and dont say everything can be done by own development,… belive me you can solve some of it but far not everything and by the way the own delevelop way is ery expensive in time and money so where is the super big advantage the industry try to sell us?

virtual hosts are no new thing. in fact its a well known old horse with a fresh PR and some new inventions. and again its the right solution for the right problems. like everything in the world theres no absolute truth , no absolute way to go, youll have always to consider deeply and sometimes there maybe 2 or 3 solutions same good at the end of the pro and contra list

I’ve been exploring for a little for any high quality articles or blog posts on this sort of area . Exploring in Yahoo I at last stumbled upon this web site. Reading this information So i’m happy to convey that I have an incredibly good uncanny feeling I discovered exactly what I needed. I most certainly will make sure to do not forget this website and give it a glance regularly.

Awesome blog you have here but I was wanting to know if you knew of any community forums that cover the same topics talked about in this article? I’d really love to be a part of group where I can get feed-back from other experienced people that share the same interest. If you have any suggestions, please let me know. Cheers!