The VirtualBox architecture

Virtualization is, by nature, extraordinarily complex, especially so on x86 hardware. Understanding the VirtualBox source code therefore requires, at least for some components, a great deal of understanding about the details of the x86 architecture as well as great knowledge about the implementations of the host and guest platforms involved.

There are several ways how to approach how VirtualBox works. This document shall describe them in order of increasing complexity.

The VirtualBox processes: a bird's eye view

When you start the VirtualBox graphical user interface (GUI), at least one extra process gets started along the way -- the VirtualBox server, normally dubbed VBoxSVC.

Once you start a virtual machine (VM) from the GUI, you have two windows (the main window and the VM), but three processes running. Looking at your system from Task Manager (on Windows) or some system monitor (on Linux), you will see these:

1. VirtualBox, the GUI for the main window;
2. another VirtualBox process that was started with the -startvm parameter, which means that its GUI process acts as a shell for a VM;
3. VirtualBoxSVC, a daemon running in the background that keeps track of all the processes involved (this was automatically started by the first GUI process).

(On Linux, there's another daemon process called VBoxXPCOMIPCD which is necessary for our XPCOM implementation to work. We will ignore this for now; see COM-XPCOM interoperability for details.)

The VM that runs "inside" the second window looks like just another Qt process to the host operating system. VirtualBox is very well behaved in that respect: it pretty much takes over control over a large part of your computer, executing a complete operating system with its own set of guest processes, drivers, and devices inside this VM process, but the host operating system does not notice much of this. Whatever the VM does, it's just another process in your host operating system.

We therefore have two sorts of encapsulation in place with the various VirtualBox files and processes:

1. Client/server architecture. All aspects of VirtualBox and the VMs that are running can be controlled with a simple, yet powerful, COM/XPCOM API. For example, there is a command-line utility called VBoxManage that allows you to control VMs just like the GUI does (in fact, many of the more sophisticated operations are not yet supported by the GUI). You can, for example, start a VM from the GUI (by clicking on the "Start" button) and stop it again from VBoxManage.

This is why the server process (VBoxSVC) is needed: it acts as a librarian of what VMs are running and what states their in.

2. Frontend/backend architecture. The guts of VirtualBox -- everything that makes x86 virtualization complicated and messy -- are hidden in a shared library, VBoxVMM.dll, or VBoxVMM.so on Linux. This can be considered a "backend" that is static, and it is easy to write another frontend without having to mess with the gory details of x86 virtualization. So, as an example, if you don't like the fact that the GUI is a Qt application, you can easily write a different frontent (say, using GTK).

In fact, VirtualBox already comes with several frontends:

• The Qt GUI (VirtualBox) that you may already be familiar with.

• VBoxManage, a command-line utility that allows you to control all of VirtualBox's powerful features.

• A "plain" GUI based on ​SDL, with fewer fancy features than the Qt GUI. This is useful for business use as well as testing during development. To control the VMs, you will then use VBoxManage.

• An RDP server, which does not produce visible output on the host, but allows remote computers to connect to it.

(The RDP server is not part of VirtualBox Open Source Edition, but is available with the full version; see the [Editions] page for details.