VirtualBox

I've been a big fan of virtualization for a few years, especially after VMWARE released their Server product for free. I've used it on several projects for things like software development, software testing, OS testing, and "trial runs" for new product testing. I haven't really liked Microsoft's Virutal PC product, mostly because of the restrictions they had on it early on.

These days, virtualization is really taking off. I think this is largely because the virtualization products and commodity hardware are catching up with the hype. With disk, processor, and memory as cheap as it is, you can build several screaming fast, isolated, virtual servers running foreign OSes on one physical server for less than you'd think.

Always looking for something newer and "free-er", I decided to give innotek's (http://www.virtualbox.org) VirtualBox a try. An open source version is available, but you have to go with binaries if you want some of the special new features such as the RDP server.

I went with the binaries because the project I'm working on was to find a way to allow remote access to Quickbooks without installing a Windows Server Terminal Server or another PC by better utilizing an existing Ubuntu server running SAMBA. The binaries provided for RDP access without having to allow it from XP.

I figured if I could use the Ubuntu server to run a virtual XP box, I could provide a single remote user with access to the local network, QB running natively, and allow it to connect to the current QB database server running on an XP workstation. If that worked, I could try to switch the database to run on the virtual box itself and get the data back on the server where it belongs and like it was before the client upgraded to QB 2007 (which required the data be on the local disk of a QB-database-server-capable XP box).

If this works, the cost to the client will be for one license for XP or about $140. This will save them about $500 for a dedicated XP box with remote control (plus the power to run it 24x7 for the occassional use it might get from the remote user) or even $2000 for a system and software to run Windows Server with Terminal Server for 5 users, given that architectually they really want to move the database off an XP box and onto a real server.

So, here's my process...

The Evaluation Project

Server: Dell Ubuntu 6.06 LTS with 2GB of memory, running Samba
Client: Remote XP system accessing the internet via satellite-based ISP
Software: Running mainly XP and Quickbooks 2007 (QB database is hosted on another network client running XP)

The server will run the virtual XP box upon boot. The remote client will connect using RDP (the RDP client that comes with XP) via the internet, thru a hole in the network firewall, to the server, and to the virtual XP box. The virtual XP box will run Quickbooks which will connect to the database running on an already existing QB database host system.

For those not familiar with RDP, it is the protocol used by Microsoft's Terminal Services. Virtualbox lets you use RDP to communicate with the virtual machine running on a different system.

Project steps:

• Install virtualbox on my laptop
• Set up a virtual machine running XP and Quickbooks 2007
• Test connecting to the vm via RDP
• Install virtualbox on the Ubuntu server
• Transfer the vm to the server
• Start up the vm on the server
• Test remote connectivity
• Test Quickbooks
• Verify acceptable reliability and performance
• Evaluate product in the production environment

Note that for simplicity's sake, I have simply used my IP addresses in this example. You'll want to use your own. Also, don't expose your system to the internet until you have applied all security patches and hardened up your system.

Install virtualbox on my laptop

This was very easy. I just downloaded the 18mb Windows installer for VirtualBox and installed it. I had a few problems with Sun's website where the files are hosted as the download wouldn't go unless I allowed pop-ups.

Set up a virtual machine running XP and Quickbooks 2007

I followed the documentation and quickly created a virtual machine ready for my XP install. I have an ISO image of XP Pro SP2 already on my system, so I mounted the ISO as a CD on the virtual machine and quickly installed one of my MS XP ActionPack licenses (the client will be purchasing their XP license for the production system). It seemed to run faster than a normal hardware install, hmm... I set up automatic updates with Windows updates and download about 92 patch files and applied them.

After the install, the trickiest part was getting the networking right. I settled on a bridged connection between the VM and my windows host. This required creating a bridge connection on my windows host and then linking the bridge to the virtual adapter created by VirtualBox. Then I pointed the first VM fake adapter to bind with the virtual bridge connection. Not a big deal, but it did take a little work to get it just right.

I also changed the default setting on the VM to allow VRDP connections. This will allow you to connect from another machine using RDP (remote desktop protocol). You can even install Windows this way, if you are running a headless server! This is because RDP talks to the virtual machine, not the Windows OS directly.

Test connecting to the vm via RDP

I waited until I had everything running the way I wanted on the desktop and had gotten used to the VM control panel and had networking running (you don't have to have networking running to do this, if you have turned on VRDP in the virtual machine settings as I did above).

I wasn't able to connect to my VM from my host because of a limitation built into the client, I believe (I think it tries to keep you from looping back to your own system). However, I was able to go to another computer on my network and connect right up.

I had a few issues the first time I connected with the cursor not syncing properly (the virtual cursor was a few inches away from my actual cursor), but after resetting things and making sure my RDP connection screen size matched between the VM and the client, it seemed to work just fine.

Install virtualbox on the Ubuntu server

I had some trouble getting VirtualBox to install on the Ubuntu server. An "apt-get" install is supposed to be supported, but I couldn't get it to work because of a missing public key error.

I got around that by downloading the .deb file by hand and installing it using dpkg:
dpkg -i VirtualBox_1.5.6_Ubuntu_dapper.deb

Note: As of May 2, 2008, Virtual Box 1.6 is available with over 2000 improvements. I've since switched to the new version.

There where problems with missing dependancies, but I fixed that by doing an "apt-get -f install". This completed the rest of the installation. A couple of prompts come up, but I take the defaults on those.

I had to take a break at this point to download the linux source files and get them set up so that I could finish the install. This process is described in http://www.mojocode.com/node/131

I followed the manual's instructions for building the missing modules I needed, which was basically to run:
/etc/init.d/vboxdrv setup

Some people report having to run this twice, to get it to work, but I've never had to do that.

At this point, the VirtualBox service was running, I just needed to get my test VM copied over and configured.

Transfer the vm to the server

I used scp to transfer the 2.5gb VDI file and xml configuration files over to the linux box. The directory structure is basically the same, but the files live in the home folder of the user that will be running the vm. For instance:

/root/.VirtualBox
/root/.VirtualBox/Machines
/root/.VirtualBox/VDI

These are the default directories, but they weren't created, since I hadn't built a vm on that box. I manually created the directories with mkdir.

Machines will contain the directories describing the different VMs you have. VDI contains the disk images. I copied my "TestXP" directory to the Machines folder and my TestXP.vdi image to the VDI folder.

The xml files aren't supposed to be edited by hand, and you probably don't need to if you follow the recommended process for detaching things before moving them over. However, I didn't do that (in fact I really was testing the process of moving over a virtual maching to another server such as I might do during a hardware failure or an architecture move).

So, I had to fix the files by hand. VirtualBox documentation recommends against this, but since they are text files and I had backups, I wasn't really worried.

First, I had to get the xp vm registered. It wouldn't register when I first tried it because it didn't like the version (still pointed to windows) and it didn't like the virtual disk being still attached.

I used nano to change this:

<VirtualBox xmlns="http://www.innotek.de/VirtualBox-settings"
 version="1.2-windows">

to this:

<VirtualBox xmlns="http://www.innotek.de/VirtualBox-settings"
 version="1.2-linux">

Then I had to temporarily remove the mounted virtual disk from the file by changing this:

    <HardDiskAttachments>
      <HardDiskAttachment bus="ide0" device="master"
           hardDisk="{6be4dbac-9a80-45aa-a9d5-7b7b1e52617e}"/>
    </HardDiskAttachments>

to this:

    <HardDiskAttachments>
    </HardDiskAttachments>

You have to "detach" the drive because VBoxManage throws an error if you try and register a vm that has a disk attached.

Now register the vm:
VBoxManage registervm "Machines/TestXP/TestXP.xml"

If you don't have any errors, then put the HardDiskAttachment entry back in. If you do have errors, fix them before proceeding.

Now, you need to register the VDI file that you copied the to VDI directory:
VBoxManage registerimage disk "VDI/TestXP.vdi"

Note: when upgrading from 1.5 to 1.6, you have to add a "-convertSettings" option to proceed, but the program is nice about explaining this.

This tells the VirtualBox.xml file about your disk, but doesn't link it to the VM. We did that in the above step when we put the reference to HardDiskAttachment back in.

Note: 1.6 seems to be describing the HardDiskAttachment section differently... Don't use my example above verbatim.

You can add the HardDiskAttachment back using the command line:
VBoxManage modifyvm "TestXP" -hda "VDI/TestXP.vdi"

I also switched the boot order on my TestXP.xml file, since the linux system didn't have a DVD drive. I just switched the order so that the VM boots to the disk first. This probably isn't necessary.

Start up the vm on the server

Now the moment of truth...
VBoxManage startvms TestXP -type vrdp

and BOOM! It reported everything was running. I connected via RDP in time to see the BIOS screen and the Windows XP loading screen!

Everything worked pretty much as hoped. With 1.5, I had some issues with screen artifacts, but I haven't had any problems with 1.6. (For instance, if I click on the Start button, then click it again, Windows normally hides the menu. However, in this case it left the image of the menu on the screen. If I right click the desktop and select Refresh, it clears the artifact. I'm not sure why this is, but I plan on playing with some settings in the VM.)

The next part was much harder than it should be to get working. I wanted the virtual session to be on a different IP address from the host. So, if my host was 192.168.1.77, I wanted my VM to run on 192.168.1.78. I tried following the directions in the manual, but they just didn't add up. The basic idea is that you don't want to use NAT (which basically puts your VMs behind a firewall "inside" the host), you need to change to using host-based networking and if you want the host address to be different from the VM (or VMs), you need to set up bridging.

Here's what I had to do:

Add the bridge and uml utilities packages:
apt-get install bridge-utils uml-utilities

Edit the /etc/network/interfaces file and describe the bridge:
nano /etc/network/interfaces

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet manual
#static
#       address 192.168.1.77
#       netmask 255.255.255.0
#       network 192.168.1.0
#       broadcast 192.168.1.255
#       gateway 192.168.1.1

auto tap1
iface tap1 inet manual
        tunctl_user root
        uml_proxy_arp 192.168.1.77
        uml_proxy_ether eth0

auto br0
iface br0 inet static
        address 192.168.1.77
        netmask 255.255.255.0
        gateway 192.168.1.1
        bridge_ports eth0 tap1
        bridge-maxwait 0

As you can see, I moved the static address from eth0 to the new br0 bridge interface. The new tap1 interface is the tunnel interface that will be assigned to the vm. (It may help to know that when you are bridging, this is an ethernet concept, not a TCP concept.) Basically, we are creating 2 bridged ethernet connections; the host will communicate on the br0 using it's old IP address and the VM will have its IP address assigned inside the VM's guest OS network settings.

Note that the tunnel user has been set to 'root', which is the user that will be starting and running my vm's.

Now add the virtual network to the vbox configuration file:
nano /etc/vbox/interfaces

tap1 root br0

Make sure the tun device has the right rights:
chown root:vboxusers /dev/net/tun

Restart your networking, then make sure you can still get back to your host. Note that your boot time will be slower, now that you are having to wait on the bridge to get established. Don't restart your networking, if you are remoting in through ssh, unless you have access to the machine and can fix anything that is wrong. Anything you botch here (or that I forgot to tell you about) can make your system unaccessible.

/etc/init.d/networking restart

You should be able to ping your server:
ping 192.168.1.77

You won't be able to ping your vm until you have configured networking inside the guest:
ping 192.168.1.78

Start your VM:
VBoxManage startvm "Test XP"

and get your RDP admin connection going by pointing it to 192.168.1.78. Log in and change your network settings to a fixed IP address, as in my case 192.168.1.78.

As soon as you do this, you should be able to ping the address from another workstation and from a ssh session.

Test remote connectivity

Basically, the VRDP functionality works. It isn't fancy and I didn't get remote drives or printing to work. However, by setting up the vm to use a different IP address, I actually have the ability to have two RDP connections.

The first connection is the VRDP connection to the "console". Using this connection, I can log in and make configuration changes, such as to the guest network settings, without losing my connection.

The second connection is the standard XP remote control/terminal server RDP session that is a part of XP Pro. I turned this capability on in the vm guest and can access it using the guest's IP address (in my case 192.168.1.78). The big advantage in having the client employee access the system this way will be that all remote printers and drives are available (shares and local drives), just like you can have in a Terminal Server session. This means the employee can print locally and copy files from the guest vm to the remote client and back the other way. If the remote printer isn't locally attached to the remote computer (ie via USB or LPT), you can still attach to network printers (ones you connect to with the standard TCP port, for instance) by sharing the printer from the attaching client and then installing the network printer on the guest os.

In my case, I had an HP3005 printer attached via TCP on my laptop. The RDP session didn't show any printers available on the guest os because there weren't any locally attached. I simply right clicked on the printer from my laptop and selected "Sharing...". I set it up as a shared printer. Then I started my RDP session to 192.168.1.78 and started adding a printer. When prompted for locally or network connected, I selected networked and pointed to my laptop's shared printer. I got an error that the driver couldn't be loaded. To fix that, I used the shared drives that showed up on the guest (my laptop's C drive, for instance), and navigated to where I had saved the driver package. I copied it to the guest os and ran the installer. It was easy to map the printer at that point.

Test Quickbooks

Quickbooks worked great without a glitch. Performance was very acceptable and since we are only transfering mouse, keyboard, and screen changes, it works very well over slower connections. I wouldn't want to use dial-up, but anything faster works very well. To speed things up, I turned off themes, fancy graphics, and took the option to optimize the interface for performance (standard XP stuff).

Printing of short reports works great. I wouldn't want to have to transfer a lot of graphics or anything, but it seemed to work "good enough".

Verify acceptable reliability and performance

Things I have working, but I'm still testing long term reliability on:

• Status on reboot (auto start VMs) [I have a script that does this, but I'm still testing it]
• Performance with QB after weeks of runtime
• Does it stay up for weeks?
• Is there an issue with the virtual network adapter going to sleep?

Evaluate product in the production environment

I'm still working on these:

• Production environment performance with QB
• Does it stay up for as long as the server?
• Any data corruption issues?
• Is the client pleased with the solution?
• Can we use this in a multi-user environment? (like with using http://www.elusiva.com)
• Does the new "application on your desktop" feature work? (This is where a program running in the VM appears to be running on your desktop.)

Overall impressions

I really liked working with the VirtualBox product. If it holds up in a production environment, I can really see a lot of areas where I'll be using it. Not just as a VMWARE replacement, but even as a solution for running non-native applications on other OSes, a terminal server replacement, and mainly as a way of supporting Quickbooks 2007 and beyond "natively" in a Linux/SAMBA environment. That last one is huge because with QB (and Peachtree) switching to using the .NET database handler, it was forcing my Linux shops to either support a system running Windows Server, run data apps on a non-dedicated XP box, or upgrade to QB Enterprise with its problematic support of Linux as the database server.

I think I have a $140 solution (XP license), to a $5 problem, forced on my clients by a $300 software package (QB), that would have cost $2000 to fix (full Terminal Server solution)!

Also, I'm well on my way to being freed from having to live in XP jail. I can move to a Linux or Mac desktop and still bring my legacy XP applications along without having to emulate XP.

Happiness is a warm vm.