TOPIC: CLOUD INFRASTRUCTURE
Things that I like about VirtualBox OSE
6th September 2008Now that VirtualBox 2.0 is out with its 64-bit operating system support among other things, the version included in Ubuntu 8.04, OSE 1.56, is looking that bit older. Nevertheless, there remains a lot to like about the version that I have been using.
For one thing, its Shared Folders functionality doesn't trip up Photoshop Elements like VMware does. VMware so hobbled Photoshop's ability to save back to the Linux file system that it had me looking at the WINE route; I also got to use GIMP for a while. VirtualBox brought me back into the Photoshop fold, and I seem to like the results that I can get with Elements better than those from GIMP.
Another nicety is the way that guest OS desktops can be resized to fit in a maximised VM window. For this to work, you need VirtualBox Guest Additions in place in the virtual machine, but it works very well when all is in place; my experience is with Windows XP. Full screen is on tap too once you use the Host+F combination; the right hand control key is usually the Host key by default. If there is any criticism at all, it might be that seamless application windows are not available in OSE 1.5.6.
Linux kernel changes can upset things, but drivers don't take too long to appear, and you can always take matters into your own hands anyway. It's a far cry from the blithe indifference of VMware and the need to resort to vmware-any-any patching to get things under way again.
All in all, VirtualBox OSE treats me very well. Guest operating systems may seem sluggish at times, but it's never enough to annoy or seriously impede usage. It'll be interesting to see if a newer version of VirtualBox makes it into Ubuntu 8.10.
Getting VirtualBox working on Ubuntu after a kernel upgrade
27th July 2008In previous posts, I have talked about getting VMware Workstation back on its feet again after a kernel upgrade. It also seems that VirtualBox is prone to the same sort of affliction. However, while VMware Workstation fails to start at all, VirtualBox at least starts itself even if it cannot get a virtual machine going and generates errors instead.
My usual course of action is to fire up Synaptic and install the drivers for the relevant kernel. Looking for virtualbox-ose-modules-[kernel version and type] and installing that usually resolves the problem. For example, at the time of writing, the latest file available for my system would be virtualbox-ose-modules-2.6.24-19-generic. If you are a command line fan, the command for this would be:
sudo apt-get install virtualbox-ose-modules-2.6.24-19-generic
The next thing to do would be to issue the command to start the vboxdrv service, and you'd be all set:
sudo /etc/init.d/vboxdrv start
There is one point of weakness (an Achilles heel, if you like) with all of this: the relevant modules need to be available in the first place and I hit a glitch after updating the kernel to 2.6.24-20 when they weren't; I do wonder why Canonical fail to keep both in step with one another and why the new kernel modules don't come through the updates automatically either. However, there is a way around this too. That means installing virtualbox-ose-source via either Synaptic or the command line:
sudo apt-get install virtualbox-ose-source
The subsequent steps involve issuing more commands to perform a reinstallation from the source code:
sudo m-a prepare
sudo m-a auto-install virtualbox-ose
Once these are complete, the next is to start the vbox drv as described earlier and to add yourself to the vboxusers group if you're still having trouble:
sudo adduser [your username] vboxusers
The source code installation option certainly got me up and running again, and I'll be keeping it on hand for use should the situation raise its head once more.
Disk corruption can be virtual too
16th July 2008It's the sort of sight that causes you to fear the worst, an unchanging black screen with a flashing cursor. That was what started to greet me recently when I tried to fire up a Windows XP guest in VMware Workstation. The cause was the corruption of a virtual disk, an ominous thing that affected a supplemental virtual hard drive that I had added to the virtual machine rather than its main one. Though there might have been some data on there, it was nothing that I didn't have elsewhere anyway. Removing the broken disk from the XP VM returned the situation to fuller health, and I simply tried creating a new one again. So far, this seems to be working fine, yet I'll be keeping a watchful eye on things.
So far, I have no idea why the corruption happened, but the broken disk files were created without a VMDK extension, which might indicate that something was amiss with the process that created them. While it would be better if VMware highlighted the state of its virtual disks, it was when I tried opening the trashed disk with VirtualBox that a warning was given and VMware did the same when I tried it with that afterwards (opening VMware virtual disks with VirtualBox is possible, but you need to ensure that no attempt at importation is made, or you could end up with a breakage). While I may have discovered the fault in a roundabout manner, it's better to know what's gone wrong than not to know at all.