Tag Archives: virtualbox

How to install and run VirtualBox on Fedora (and Kororaa)

Kevin on the Kororaa Forums asked a question about VirtualBox and why it needs kernel modules.

Just wondering if someone could give me an idea of what Kernel Modules are and what they do in relation to Virtual Box? Every time I try to install VB it says you need “this” or “that” (mostly kernel modules) and I have no idea where to look, what they are, and what they do, so I am hoping to learn something. Also, if I get VB to work, and “they” update the kernel, do I have to add modules again or? Basically when I install VB, what do I have to install along side it?

Here’s my reply, as it might be useful for anyone running Fedora (note, this is using the latest package from Oracle, rather than the pre-compiled OSE in the Fedora repos).

So your operating system is made up of three (main) components:

  • Physical hardware (computer bits)
  • Kernel (software which talks to your hardware and makes it work, think drivers)
  • Software (talks to your kernel to get to your hardware)

Your kernel is what makes your computer work (this is actually what Linux is, a kernel) and it’s actually the most important part of the operating system. When you’re talking about VirtualBox, it needs to create fake hardware on top of your real hardware, so to do that, it needs a driver. Drivers sit in the kernel layer.

The Linux kernel has thousands of drivers in it, but it does not have VirtualBox drivers in it (yet). This means you need to compile these and load them into your running kernel of you want to use VirtualBox. Once you do that, your kernel will have the fake hardware that the VirtualBox software needs to run. Drivers which you can load and unload into the kernel are called modules.

The VirtualBox host computer needs these drivers, but the VirtualBox guest also needs some drivers to make full use of the fake hardware. When you install Linux or Windows as a VirtualBox guest, the hardware is fake, so that OS needs drivers too! Some of those drivers (like audio and network) are already in the Linux kernel, so if your guest is running Linux, you just need drivers for the video, etc.

In order to compile the drivers for VirtualBox (on both host and guest) on Linux you need some development libraries, compiler program (such as GCC), as well as the headers for the running kernel. You need the headers because you need to compile a driver to load into the kernel and it needs to know detailed information about it.

Fortunately, if you’re using Kororaa, all of the required tools and packages are already installed! 🙂 All you need to do is build the drivers.

If you’re running a vanilla instance of Fedora, then you need to install the build tools like so:
su -c 'yum install gcc kernel-devel'

Now you have the build tools required to compile the drivers.

Automatically building drivers after kernel update
Modules are for a specific kernel and so when you get a kernel update, you need to re-compile the drivers for VirtualBox hosts and guests. Fortunately, there’s a neat little package called DKMS (Dynamic Kernel Module Support Framework) which will do this for you automatically – and of course Kororaa comes with this pre-installed.

If you’re running Fedora, you can easily install it like so:
su -c 'yum install dkms time'

When you install VirtualBox (see below), it will register the drivers with DKMS and on boot it will re-compile them for you, if it needs to. So, you just need to do it once and forget! Any updates to VirtualBox that are pulled in will also be automatically updated.

Building drivers on the host
Because Kororaa has all of the requirements for VirtualBox (including the package repository), all you need to do to get VirtualBox up and running is to install it using the package manager. If you prefer, you can install it manually like so (note the version is currently 4.1):
sudo yum install VirtualBox-4.1

Again, if you’re using vanilla Fedora, then you need to grab the VirtualBox repository file so that you can install VirtualBox from the Oracle repository (the packaged version from Fedora is usually a few versions behind).
su -c 'wget http://download.virtualbox.org/virtualbox/rpm/fedora/virtualbox.repo -O /etc/yum.repos.d/virtualbox.repo'

Now you can install VirtualBox on Fedora:
su -c 'yum install VirtualBox-4.1'

You should see something like this during the install process:
No precompiled module for this kernel found -- trying to build one.
Stopping VirtualBox kernel modules [ OK ]
Uninstalling old VirtualBox DKMS kernel modules [ OK ]
Trying to register the VirtualBox kernel modules using DKMS [ OK ]
Starting VirtualBox kernel modules [ OK ]

As you can see, the modules were successfully compiled and registered with DKMS for future automatic compilation.

Group permissions
Just remember that any user who wants to run and use VirtualBox on the host needs to be in the vboxusers group. You can use the users graphical tool to do this (system-config-users), or add them to the group by running the command (substitute chris with your username):
sudo gpasswd -a chris vboxusers

Then just run VirtualBox and away you go!

Building drivers on the guest
Once you have your host up and your guest operating system installed, the way to install the required drivers is using the built in method. Once you have booted your guest operating system, simply click the Devices menu at the top, and click Install Guest Addons.

Install Guest Addons
This will load a CD in your guest and you can run the autorun.sh script from the disk, which will ask you for the root password and then detect your operating system and compile the drivers for you.

Run Guest Addons
Once again, if your guest is running Kororaa too, then you already have the required build tools and libraries. If not, you will need to install them first – how this is done depends on your distro (for Fedora, see above).

Remember, with DKMS you will automatically get updated drivers this way after a kernel update.

That’s it! Just reboot your guest and away you go.

VirtualBox continues to innovate, 3.1 released

I’m really impressed with Sun’s VirtualBox. Ever since they bought it from Innotek the development has not stood still. Today it’s probably one of the easiest to use and most popular virtualisation technologies, especially on the desktop. Sure, there are closed source bits which is annoying (USB and Remote Desktop support), but that aside, the project has really been innovating.

Now version 3.1 is out and it has some high-end features which might make VMware a little nervous:

VirtualBox 3.1, introduced Nov. 30, offers what Sun officials call “teleportation” capabilities. The software enables businesses to move a running VM between hosts that are running different operating systems, are different classes of computers—including moving from a server to a client—and running different processors, such as chips from Intel and Advanced Micro Devices.

The VMs can be moved uninterrupted when a physical host needs to be brought down.

The grass roots have also been improved:

In addition, VirtualBox 3.1 offers enhanced execution speed—including a 30 percent improvement in memory handling over the previous version of VirtualBox—upgraded network performance that offers better throughput and reduced CPU cycles through a new high-speed, paravirtualized network driver, and a new two-dimensional video acceleration feature for Windows VMs. It also includes better snapshotting features, according to Sun officials.

Here’s the list of new features:

* Teleportation (aka live migration); migrate a live VM session from one host to another (see the manual for more information)
* VM states can now be restored from arbitrary snapshots instead of only the last one, and new snapshots can be taken from other snapshots as well (“branched snapshots”; see the manual for more information)
* 2D video acceleration for Windows guests; use the host video hardware for overlay stretching and color conversion (see the manual for more information)
* More flexible storage attachments: CD/DVD drives can be attached to an arbitrary IDE controller, and there can be more than one such drive (the manual for more information)
* The network attachment type can be changed while a VM is running
* Complete rewrite of experimental USB support for OpenSolaris hosts making use of the latest USB enhancements in Solaris Nevada 124 and higher
* Significant performance improvements for PAE and AMD64 guests (VT-x and AMD-V only; normal (non-nested) paging)
* Experimental support for EFI (Extensible Firmware Interface; see the manual for more information)
* Support for paravirtualized network adapters (virtio-net; see the manual for more information)

Now, if only OpenOffice.org innovated like VirtualBox..

Karmic Virtualbox graphics problem, workaround

I thought I’d give Karmic Kubuntu a spin under Virtualbox 3.0.10, which I installed via the Live CD.

After installation it booted and I could log in and use KDE. The resolution was very low, but everything was there. I thought I’d just do the latest updates and then reboot to configure the rest.

However, after updating the system rebooted and I was greeted with this:
Kubuntu login

I switched to TTY1 (via RCTRL+F1) and logging in presented me with this unusable terminal:
Kubuntu terminal

Switching back to the XServer however now fixed the corruption (and changed the resolution), yay:
Kubuntu login

However, unfortunately now I can’t use the desktop. Aside from the background, it’s completely blank!:
Kubuntu desktop

The graphical environment was working before I updated. To fix this I booted to the recovery console, started a terminal with networking and installed the Virtualbox X driver and configured for use:

apt-get install virtualbox-ose-guest-x11
depmod -e

I then exited the shell and selected start normal but this failed, so I rebooted and was greeted with a working display and log in screen, yay!

Unfortunately, logging in still resulted in the same completely empty desktop. There’s nothing. Nothing! Something has gone drastically wrong.. time to re-install. This time I’ll do the driver, THEN update. As Mike would say, “What could possibly go wrong?”


Lately I’ve been using open source VirtualBox for my virtualisation needs instead of KVM because it is so simple and works well (no nightmare of VMware kernel modules, vmware-any-any or any of that rubbish either!). If you haven’t tried it yet, I highly recommend that you do.

Anyway, version 2.2.0 has just been released with the following major new features:

* OVF (Open Virtualization Format) appliance import and export
* Host-only networking mode
* Hypervisor optimizations with signicant performance gains for high context switching rates
* Raised the memory limit for VMs on 64-bit hosts to 16GB
* VT-x/AMD-V are enabled by default for newly created virtual machines
* USB (OHCI & EHCI) is enabled by default for newly created virtual machines (Qt GUI only)
* Experimental USB support for OpenSolaris hosts
* Shared folders for Solaris and OpenSolaris guests
* OpenGL 3D acceleration for Linux and Solaris guests
* Added C API in addition to C++, Java, Python and Web Services

Experimental OpenGL support for guests was enabled in 2.1.0 and appears to be more complete in this new release. Sun blogger Calum has released a short video of Compiz in action on an OpenSolaris guest. I have yet to test it out myself, but it looks pretty neat.