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 modules: 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. The VirtualBox GUI is only one of several "frontends" to the VirtualBox "core", which is encapsulated in several rather large libraries (among them VBoxVMM.dll, or VBoxVMM.so).

Once you start a virtual machine (VM) from the GUI, you have three processes running:

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

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