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 "service", 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. VBoxSVC, the service mentioned above, which is running in the background to keep 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.)

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

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 service 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", or black box, that is static, and it is relatively 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 frontend (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 Remote Desktop Protocol (RDP) server, which is console-only and produces no graphical output on the host, but allows remote computers to connect to it. This is especially useful for enterprises who want to consolidate their client PCs onto just a few servers. The client PCs are then merely displaying RDP data produced by the various RDP server processes on a few big servers, which virtualize the "real" client PCs. (The RDP server is not part of VirtualBox OSE, but is available with the full version; see the Editions page for details.)

Inside a virtual machine

As said above, from the perspective of the host OS, a virtual machine is just another process. The host OS does not need much tweaking to support virtualization.

When a VM is running, from your processor's point of view, your computer can be in one of several states (the following will require a good understanding of the x86 ring architecture):

1. Your CPU can be executing host ring-3 code (e.g. from other host processes), or host ring-0 code, just as it would be if VirtualBox wasn't running.
2. Your CPU can be emulating guest code. Basically, VirtualBox tries to run as much guest code natively as possible. But it can (slowly) emulate guest code as a fallback when it is lost about why guest code is not working, or when the performance penalty of emulation is not too high. Our emulator (in src/emulator/) is based on ​QEMU and typically steps in when
   • guest code disables interrupts and VirtualBox cannot figure out when they will be switched back on (in these situations, VirtualBox actually analyzes the guest code using its own disassembler in src/VBox/Disassembler/);
   • for execution of certain single instructions; this typically happens when a nasty guest instruction such as LIDT has caused a trap and needs to be emulated;
   • for any real-mode code (e.g. BIOS code, a DOS guest, or any operating system startup).
3. Your CPU can be running guest ring-3 code natively. In VirtualBox, this is called "raw ring 3". This is, of course, the most efficient way to run the guest, and hopefully we don't leave this mode too often. The more we do, the slower the VM is compared to a native OS, because all context switches are very expensive.
4. Your CPU can be running guest ring-0 code natively. Here is where things get hairy: The guest only thinks it's running ring-0 code, but VirtualBox has patched the guest OS to instead enter ring 1 (which is normally unused with x86 operating systems).

Also, in the VirtualBox source code, you will find lots of references to "host context" or "guest context". Essentially, these mean:

• Host context (HC) means that the host OS is in control of everything including virtual memory. In the VirtualBox sources, the term "HC" will normally refer to the host's ring-3 context only. We only use host ring-0 (R0) context with our new Intel VMX (Vanderpool) support, which we'll leave out of the picture for now (but see below).

• Guest context (GC) means that VirtualBox has set up CPU & memory exactly the way the guest expects, but has inserted itself at the "bottom" of the picture, so that VirtualBox gains control first for any privileged instructions executed, guest trap or external interrupts, before VirtualBox may then possibly delegate handling such things to the host OS. So, in the guest context, we have
  • ring 3 (hopefully executed in "raw mode" all the time);
  • ring 1 (of which the guest thinks it's ring 0, see above), and
  • ring 0 (which is VirtualBox code). This guest-context ring-0 code is also often called a "hypervisor".

Finally, there is also a ring-0 driver that must be loaded in the host OS for VirtualBox to work. However, this ring-0 driver does less than you may think. It is only needed for a few specific tasks, such as:

• allocating physical memory for the VM;

• saving and restoring CPU registers and descriptor tables when a host interrupt occurs while a guest's ring-3 code is executing (e.g. when the host OS wants to reschedule);

• when switching from host ring-3 to guest context;

• enable or disable Vanderpool etc. support.

Most importantly, the host's ring-0 driver does not mess with your OS's scheduling or process management. The entire guest OS, including its own hundereds of processes, is only scheduled when the host OS gives the VM process a timeslice.

Intel VMX ("Vanderpool") support

With its latest processors, Intel has introduced hardware virtualization support