X
Tech

To VM or not VM?

I have been experimenting with Sun's VirtualBox version 3.1.
Written by Xwindowsjunkie , Contributor

I have been experimenting with Sun's VirtualBox version 3.1.2 virtual machine package on Ubuntu 9.1 as host OS. I've also tried the "same" version on WIndows XP Pro SP3. Various desktop OS VMs have been installed and tested on it. I've tried out a number of Linux distributions and Windows XP Pro and Win 7 RC in virtual machines.

I also tried using VMWare's Workstation. Ease of use slightly favored VirtualBox although the feature set of VMWare Workstation is superior. For my little investigations either would work well enough.

Looking at all the desktop Linux distributions, I was interested in what special features or application focus in the distribution would enable or enhance certain applications or purposes. For instance, which Linux distros supported multi-media better than others? Would running a netbook version of a distro operate more efficiently in a VM than the full desktop version? Would a server version offer even better operation?

At home there's a new-to-me refurbished DELL GX620 with a Pentium D CPU and 4GB of RAM. Ubuntu and Windows operating systems reside on a 320 GB SATA drive. Storage is handled with a 500GB internal SATA drive and a 1Terabyte external USB2 drive. Currently the system dual-boots with grub into Ubuntu 9.1(default) with Windows XP Pro SP3 as the alternate.

I'm trying to figure out if there's any purpose or advantage to using a virtual machine architecture for a home server system with a heterogeneous mix of Windows and Linux clients. Lots of advertising being done by Microsoft, Novell, IBM and others make big deals out of supporting mixed systems usually with virtual servers. So far the only place it makes much sense are those situations where a server with little client traffic would otherwise sit idle a lot of the time. Or perhaps a VM server could be used to maintain some legacy application used by very few.

Intuitively there are some other potential advantages:

Increased security for the VM client is perhaps not so obvious. It should be possible to write firewall rules on both the host OS and the client VM to prevent any unwanted IP traffic in either direction. Remote log-ons could be forced to operate entirely within a VM without direct access to the host system. Virtual machines running applications that should not be allowed Internet access can be prevented from getting through the firewall yet still have access to the “local” workgroup.

Backup services could be handled by virtual machines configured specifically for each client. These backup servers could be run at any convenient time for the client instead of a block of time late at night. A small application can tell the server when the screen saver is running indicating an idle time and picking up where the backup last left off.

Print services although typically handled by shared printer services could be managed through virtual machines native to the client OS. This would allow the printer users to be printer administrators in the VM without giving them access to printer drivers or operating system privileges on the host OS.

Currently my experience shows that VM servers are in play at work since certain internal web servers or applications seem to always require a bit of “wake-up” time to get moving in the morning. It usually takes a few seconds, usually less than 10 for some applications to “go live”. If there is a interaction between the VM and an external client running on another system, the wake-up time will need to be dealt with by the client. Maybe use a software ping to alert the host OS to wake-up the VM, then wait and come back with an active function request.

Some things I've learned so far:

The nice thing about using desktop Linux distributions is that most of the desktop distros have related server versions. So you can go gui or not-gui for the specific VM. Try out the application with the graphical interface (if there is one) and later deploy it with the command line or server version of the application. Although a server version is optimized for typical server functionality, you're building something in the VM that is going to be much more function specific than the usual server distro.

At least for me, using Synaptic Package Manager instead of apt-get on the command line is a lot easier when starting with a full desktop image. Every time you remove something from the VM being prepped, you can more easily see what's left in the gui window.

A lot of times its easier to start with everything in the operating system image (usually the desktop image is fully loaded) and work backwards deleting the unnecessary items (actually un-installing them) until you've broken something. Then the answer is to put that one item back you've just deleted, you're done.

The alternative, assembling system functions from a blank slate, is that you start with an operating system image that might not work to begin with. You stumble your way through until you have added all the required dependencies just to get the system up and running.

Either way eventually you strip or build the operating system in each VM to the absolute bare essentials for the specific application or application group it will support.

Obviously the kernel needs to be in the OS image being built or minimized.

Generally the chosen Linux or Windows operating system will have a generic set of drivers for the virtual hardware to be supported by the VM. Hardware devices you want to “remove” needs to be turned off in the VM before the operating system software is installed. That doesn't guarantee that the drivers aren't installed, it just means the device will be disabled. An example is that Windows XP Pro will always install the floppy disk driver even when there isn't a floppy drive in the system and its been turned off in the BIOS.

Usually each VM will require at least some TCP/IP networking to communicate with or through the host. Each VM should have its own firewall rules.

An alternative to networking is to set the host up with storage that is shared with all the virtual machines. For the Linux VMs put the /home/username folders on it. Share the same folders as Everyone shares for the Windows variants virtual machines.

So far the best thing I've learned is that a bunch of VMs are the best way to try out different Linux versions.

Editorial standards