| | 1 | = The VirtualBox architecture = |
| | 2 | |
| | 3 | [wiki:"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. |
| | 4 | |
| | 5 | There are several ways how to approach how !VirtualBox works. This document shall describe them in order of increasing complexity. |
| | 6 | |
| | 7 | == The !VirtualBox modules: a bird's eye view == |
| | 8 | |
| | 9 | 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`). |
| | 10 | |
| | 11 | Once you start a virtual machine (VM) from the GUI, you have three processes running: |
| | 12 | |
| | 13 | 1. `VirtualBox`, the GUI for the main window; |
| | 14 | 1. `VirtualBoxSVC`, a daemon running in the background that keeps track of all the processes involved (this was automatically started by the first GUI process); |
| | 15 | 1. another `VirtualBox` process that was started with the `-startvm` parameter, which means that its GUI process acts as a shell for a VM. |
| | 16 | |
| | 17 | (On Linux, there's another process called `VBoxXPCOMIPCD` which is necessary for our XPCOM implementation to work. We will ignore this for now; see [wiki:"COM-XPCOM interoperability"] for details.) |
| | 18 | |
