Changes between Version 3 and Version 4 of VirtualBox architecture

Timestamp:

Nov 16, 2006 3:53:05 PM (17 years ago)

Author:

jose

Comment:

--

VirtualBox architecture

@@ -1 @@
-= The !VirtualBox architecture =
+= The VirtualBox architecture =
 
 [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.
@@ -5 +5 @@
 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 ==
+== 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`. The !VirtualBox GUI is only one of several "frontends" to the !VirtualBox "core", which is encapsulated in several libraries (among them `VBoxVMM.dll`, or `VBoxVMM.so`).
+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 three processes running:
+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;
- 1. `VBoxSVC`, a daemon running in the background that keeps track of all the processes involved (this was automatically started by the first GUI process);
- 1. another `VirtualBox` process that was started with the `-startvm` parameter, which means that its GUI process acts as a shell for a VM.
+ 1. another `VirtualBox` process that was started with the `-startvm` parameter, which means that its GUI process acts as a shell for a VM;
+ 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).
 
-(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.)
+(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 [wiki:"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 [http://www.libsdl.org/index.php 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.
+
+
+
+== 
+
+
+