Using VirtualBox 1.5 under Linux
I’ve been using VirtualBox 1.5 to run MS-Windows guest virtual machines under my Linux operating system (Fedora 8 and Ubuntu) for some QA and stuff like that. This post is a summary of my experience with this virtualization solution, mostly so I won’t forget the details, and as such is expected to be updated from time to time.
VirtualBox is a virtualization software – hypervisor – that is available for most operating system under a unique combination of licenses: It is available for open source development under a standard GPL license as source code (pre-packaged binaries are available for some operating systems) and it is also available under a commercial license (but free – as in without charge – for some private use) with extra features. In that sense VirtualBox is more similar to Xen1. This is rather unfortunate because I like to be able to run virtual machines in a “headless mode” and also as VirtualBox offers a remote display option that allows you to access the virtual machine from another computer using a remote desktop type connection – which is rather silly if I have to run the main head on my machine.
Its important to note that the performance is rather impressive: even on weak hardware I get a guest performance that is very close to what the operating system would feel on the real hardware – this is in contrast to VMWare’s free (of charge) offers, the VMWare Server and the VMWare Player, where performance leaves much to be desired. This is true when running a single VM, but when running more then 1 the performance not only seriously degrades (as can be expected) – it actually chokes the host operating system: instead of lowering the CPU and IO resources allocated to the VMs, VirtualBox thrashes the host causing the local desktop to become unresponsive, until sometimes the VirtualBox dies (I think the kernel kills it when it runs out of, well, everything). This also happens when you try to run a heavy virtual machine (lets say – MS-Windows Vista) on a hardware that is not top of the line and at the same time tries to run something heavy on the host – (lets say, two instances of Mozilla Firefox – yes, this is the standard use case on my home computer). Summary – don’t try to run two virtual machine, unless your computer packs some serious horse power and has tons of memory. I found that 2GB is good for running on VM and good rule of thumb is to calculate 1GB for your host operating system and an additional 1GB for each additional VM – assuming you assign 512MB per VM, get more RAM if you assign more.
Another neat feature of VirtualBox – one which I haven’t seen for any other virtualization solution available for Linux, is “seamless mode”. This feature – which is available in products from VMware and Parallels for Mac OS X – allows the VM to have an MS-Windows guest integrate with the host operating system’s desktop: when you press the “seamless mode” key shortcut the VirtualBox window disappears and the MS-Windows task bar appears at the bottom of the screen (over your real desktop bottom panel if you had any) and all the application windows that you have open float on the desktop as if they were local applications (except that they keep the MS-Windows look including window title and borders). This allows you to interact with both local applications, guest applications and the local desktop at the same time – you lose access to the guest’s desktop though. From what I understand, what VirtualBox does is to allocate a single window for the guest workspace, which is full screen and transparent, and it draws the guest operating system’s applications and task bar over it. If you then activate a local application, the VirtualBox “seamless” window goes to the background – even behind the desktop panels. So you actually have two layers on the workspace where the seamless mode is running – one where the guest’s applications are running and one where the host’s applications are running – and you can switch between them by choosing if a local window is active or if a guest’s window is active. Its not as intuitive and easy as it may sound at first, so I use it only on one workspace – on my right most workspace I have a virtual machine running in seamless mode and all other applications are running on other workspaces, and I use the workspace switching key shortcuts to go to the VM and back again. It would have been much nicer, in my opinion if VirtualBox could export the guest’s windows as actual X11 clients on the local desktop, but I guess its much harder to do – specifically to strip MS-Windows applications of their native window decorations (window title bar and borders).
- Xen is an open source hypervisor that is also being sold as a full solution by Xen Source, recently acquired by Citrix), but on the other hand VirtualBox is a fully integrated application that is also available for MS-Windows host (and other operating systems), and is very easy to use for non-technical people – in that regard it is similar to VMWare Player/Server.
Installation:
VirtualBox is very easy to install – the private use binary version is available in several common package formats for most Linux operating systems from VirtualBox website’s download section. After you install the package using your operating system’s install tool, you need to open a terminal as the root user and run the VirtualBox setup process, which automatically compiles the appropriate kernel modules. The process is very similar to VMWare workstation products, but is much easier as it uses the standard SysV service command, needs less info from the user and VirtualBox graphical tools tell you exactly what to do – no guessing required. After setting up the service you need to add all the users that want to run “Virtual Boxes” to a special group that was created – this may be easy but it depends on the specific operating system that is being used and VirtualBox offers no help for this, which is understandable but is still a shame because their applications offer a lot of help for almost anything else.
Running
VirtualBox installs a menu entry into the “System Tools” menu of the desktop and running it opens the main VirtualBox user interface which allows the user to create virtual machines, edit, delete, start and stop them. When a virtual machine is being started, it creates its own window for that machine and the user can then close the main interface – this is unlike VMWare’s console which uses a tabbed interface which may be useful if you are running a lot of virtual machines but is an annoying waste of screen space otherwise. But unlike VMWare and Xen, and similar to QEMU and the Linux KVM, the virtual machine window is the virtual machine itself – close it and the virtual machine shuts down ((When you click the window close button VirtualBox pops up a useful dialog asking if you want to send the guest VM a powerdown signal (like the power button has been pressed), save the current running state and close or just close immediately (yank the power). [↩]
Apparently its rather easy to start a virtual machine under VirtualBox in “headless” mode so you can connect to it with an RDP client from another computer:
Instead of using the management user interface to start the VM, use the command line interface and type: -type vrdp
VBoxManager startvm
I didn’t check thoroughly, but I couldn’t get more then one VM available under VRDP – it grabs the local RDP port (3389) and a new machine simply overrides the old one and take the port for itself. Also you can’t “detach the head” of a VM started from the GUI – you have to close it locally and then start it from the command line. Maybe one can use the command line to suspend the VM (savestate), then enable VRDP on it and resume it – it may start a local head or not, I’m not sure, but you can then connect to it with RDP.