Consolidate: Put Your Servers into a VirtualBox VM

Rather than installing a server, such as a web server, directly onto your main computer, why not install it in a VM? This sort of setup has a few advantages of security and convenience. These days, spreading resources out into the cloud is the in-thing, but consolidation is often underexploited. Hosting a server in a virtualizer such as VirtualBox is often a good approach for casual or occasional server needs on a home network.
This is an outline of a setup that makes use of Debian, running Apache, installed onto a VirtualBox VM. If you would like to install a different type of server, but you haven't done this sort of job before, it might be a good idea to follow through with the Apache example as it is a simple way of testing the networking side of things.
As I said, consolidation is underrated concept these days. Often, when people talk about keeping an old machine up and running, in a cupboard, just to run a web server, I wonder if their main machine has CPU cycles, memory, storage or even whole CPU cores going spare. Unless your needs are great, it's doubtful that an external source could provide resources more efficiently than a little extra load on your main box.
Why put the server in a VM?
Obviously, some server tasks are mission critical and need a dedicated machine for greater reliability, but if you have only a casual or occasional need to employ a server, ask yourself how often your desktop machine totally falls over. Modern operating systems have reached the point where if my main box completely locked up I'd suspect a hardware fault.
Of course, you could always install the server directly onto your main desktop, but that can bring its own problems. Package management makes it easy to add and remove server software, but as often as not, you end up having to make some small changes to your machine to accommodate a server. Also, if your locally hosted server is exploited in some way, it could bring your main computer into the line of fire.
Another advantage of keeping your server locked up inside a VM is that it makes the server environment portable. It's easy to copy a hard disk image and import it into VirtualBox. This means that your servers don't need to be set up and configured from scratch when you move over to a new machine. Virtualizers also allow you to shut down or pause your server environment or snapshot a working setup that can be reverted to in the event of a mishap.

Setting it up
Installing a server such as Apache in a VirtualBox VM doesn't differ greatly from installing it natively. Begin with a suitable Linux installation. It might be a good idea to choose something a bit lighter than a mainstream desktop distribution in order to conserve resources on the host machine. Debian with a lightweight window manager could be a good start (see my guide). If you're familiar with the command line interface for the server that you want to deploy, an install without a graphical environment can be ideal.
The important VirtualBox networking setting that you have to select is “bridged” rather than the default of “NAT”. By default, VirtualBox VMs present the guest operating system with a networking setup that works well enough for a web browser, or similar, to connect to the outside world. Selecting “bridged” networking makes the VM appear as though it is simply another computer attached to your network via an Ethernet cable.
One consequence of using bridged networking is that your network will have to supply the VM with an IP address. If your router has DHCP enabled, it should set the VM up in the same way that it would any other computer on the network. To check to see if the VM has an IP address, make yourself root and type:
su root [enter password]
ifconfig
On a fairly fresh install, details for two network interfaces, eth0 and lo, should be listed. To ensure that the VM can communicate with the outside world, the second line of the eth0 description should start with something something like:
inet addr:192.168.1.12
If the VM hasn't been assigned an IP address at all by your router, look up the instructions to assign a static address for your choice of guest operating system (Debian instructions here, for example).
Once that’s working, the hard part is over. Next install Apache in the normal way:
su root
apt-get install apache2
Apache pretty much sets itself up, these days. First, test that it is running and can be accessed from other machines on the network such as your host machine. Point the browser to the IP address that you obtained from running ifconfig on the guest VM. Hopefully, this will display the “It works!” message from Apache.
VirtualBox hosting a Debian guest. The install is slimline as I opted not to bother with a graphical environment. Firefox successfully finds the Apache install. I asked an IRC buddy to make sure that it could be seen from the Internet.
Next, setup port forwarding for your router so that machines on the Internet can reach your server VM. If you don't know how to do this, consult the instructions for your router. Specifically, you need to forward external requests to port 80 to port 80 on the IP address assigned to the VM.
The VirtualBox website.

1. A main machine MAY have extra CPU cores and cycles to take on the load of an additional Apache server. However, the virtual machine itself saps up huge amounts of system memory and processing power. Let us not forget.

2. If the main box has a hardware failure, all VMs running on it go down as well.

In other words, dependency is not a wise step. Servers, wherever possible must be separate physical entities. VM machines are best used for testing environments to save costs. They are not an alternative to real world server solutions especially ones offering support to mission critical applications or ones with high availability and high load requirements.

Also, you detailed out how to install Apache, but left out the part on the VM installation.

I have run Winxp and win7 vboxes on my Ubuntu laptop and they have been amazingly solid. I also have three vbox servers running on a Win 2003 standard edit server and they have run without failure for over a year - day in day out. Vbox is excellent but I wonder how long it will be available.

A question: instead of setting networking to "bridged" and forward the router's requests on port 80 to the guest's port 80, couldn't it be set to "NAT" forwarding the router requests to the host's port 80 and using the VBox port forwarding to redirected it again to guest's port 8080?
Especially concerning security, which is the better practice?

Personally I use VirtualBox for different purposes such as testing new distributions, new softwares... the only problem I see with VirtualBox is that it was Sun ... and now Oracle. What's the future of this product then!?

I use virtualbox for personal server. If you have installed a server distro without GUI you can run it as a headless server, it's easy to make a virtual machine this way, just read the virtualbox manual. I use one server for my personal web page with few users. One server for long boring jobs such as encoding terabyte of movies to highest quality, you can also put one for a virtual desktop, the possibilities are endless, well... not endless, it depends how much RAM you have.:)

Good article, Michael. We continue to follow similar paths -- I've got a VirtualBox article coming up soon too. I've been using VB here for several years now, it's a good product. I hope Oracle doesn't kill it or otherwise put it at risk. I don't trust Oracle.

VBox is a great product and it would be a shame if Oracle were to crap that up with their new "I wanna be like SCO" mantra.
I can just see them turning VBox into a paid product with a crippled free version remaining.
That or suing everyone who ever touched it.

So far the only coding effort I've seen Oracle put into anything is writing scripts to strip out Sun's name and logo from everything and slap theirs in it's place. Even the new OpenOffice icons are ugly.

Here's to hoping a great product stays great and free with it's new overlords.

I have found VB to be...testy. Sometimes it works and sometimes it doesn't. Some guests spin up without problems and other die horrible deaths without any reason behind the guest going away.

If you just want a server, doing simple things, in a development environment, it might work for you. If you want to use it for more sophisticated, long term production operations, I wouldn't bet the farm on it.

What OS are the host and guests running? I've been running the latest VB, 3.2.8 currently, on a Linux Mint (Ubuntu derivative) host here at the home office. The main guest that I use is a Windows XP image that has been rock steady under VB for 3 years, but I've also run other guests like various Ubuntus, and ChromeOS never have had a problem. Well, except for this one bug that sometimes caused local file access to be slow from within the XP image to the host filesystem. But that bug has been fixed for nearly a year now.

At work -- my company offices are on the east coast, 2,000 miles away from my Santa Fe home office -- I have several VB hosts running guests in production which have also been rock solid for several years. I maintain them via VNC, but about the only maintenance they need is to have updates installed as they are released.

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.