VirtualBox was designed to be modular and flexible. When the VirtualBox graphical user inter- face (GUI) is opened and a VM is started, at least three processes are running:
1. VBoxSVC, the VirtualBox service process which always runs in the background. This pro- cess is started automatically by the first VirtualBox client process (the GUI, VBoxManage, VBoxHeadless, the web service or others) and exits a short time after the last client exits. The service is responsible for bookkeeping, maintaining the state of all VMs, and for provid- ing communication between VirtualBox components. This communication is implemented via COM/XPCOM.
Note: When we refer to “clients” here, we mean the local clients of a particu-
lar VBoxSVC server process, not clients in a network. VirtualBox employs its own client/server design to allow its processes to cooperate, but all these processes run un- der the same user account on the host operating system, and this is totally transparent to the user.
1As an example, before VirtualBox 3.1, it was only possible to enable or disable a single DVD drive in a virtual machine.
If it was enabled, then it would always be visible as the secondary master of the IDE controller. With VirtualBox 3.1, DVD drives can be attached to arbitrary slots of arbitrary controllers, so they could be the secondary slave of an IDE controller or in a SATA slot. If you have a machine settings file from an earlier version and upgrade VirtualBox to 3.1 and then move the DVD drive from its default position, this cannot be expressed in the old settings format; the XML machine file would get written in the new format, and a backup file of the old format would be kept.
2. The GUI process, VirtualBox, a client application based on the cross-platform Qt li- brary. When started without the--startvmoption, this application acts as the VirtualBox manager, displaying the VMs and their settings. It then communicates settings and state changes to VBoxSVC and also reflects changes effected through other means, e.g., VBoxManage.
3. If theVirtualBoxclient application is started with the--startvmargument, it loads the VMM library which includes the actual hypervisor and then runs a virtual machine and provides the input and output for the guest.
Any VirtualBox front-end (client) will communicate with the service process and can both control and reflect the current state. For example, either the VM selector or the VM window or VBoxManage can be used to pause the running VM, and other components will always reflect the changed state.
The VirtualBox GUI application is only one of several available front ends (clients). The com- plete list shipped with VirtualBox is:
1. VirtualBox, the Qt front end implementing the manager and running VMs;
2. VBoxManage, a less user-friendly but more powerful alternative, described in chapter 8,
VBoxManage, page109.
3. VBoxSDL, a simple graphical front end based on the SDL library; see chapter9.1,VBoxSDL, the simplified VM displayer, page148.
4. VBoxHeadless, a VM front end which does not directly provide any video output and keyboard/mouse input, but allows redirection via VirtualBox Remote Desktop Extension; see chapter7.1.2,VBoxHeadless, the remote desktop server, page100.
5. vboxwebsrv, the VirtualBox web service process which allows for controlling a VirtualBox host remotely. This is described in detail in the VirtualBox Software Development Kit (SDK) reference; please see chapter11,VirtualBox programming interfaces, page189for details. 6. The VirtualBox Python shell, a Python alternative to VBoxManage. This is also described
in the SDK reference.
Internally, VirtualBox consists of many more or less separate components. You may encounter these when analyzing VirtualBox internal error messages or log files. These include:
• IPRT, a portable runtime library which abstracts file access, threading, string manipulation, etc. Whenever VirtualBox accesses host operating features, it does so through this library for cross-platform portability.
• VMM (Virtual Machine Monitor), the heart of the hypervisor. • EM (Execution Manager), controls execution of guest code.
• REM (Recompiled Execution Monitor), provides software emulation of CPU instructions. • TRPM (Trap Manager), intercepts and processes guest traps and exceptions.
• HWACCM (Hardware Acceleration Manager), provides support for VT-x and AMD-V. • PDM (Pluggable Device Manager), an abstract interface between the VMM and emulated
devices which separates device implementations from VMM internals and makes it easy to add new emulated devices. Through PDM, third-party developers can add new virtual devices to VirtualBox without having to change VirtualBox itself.
• PATM (Patch Manager), patches guest code to improve and speed up software virtualiza- tion.
• TM (Time Manager), handles timers and all aspects of time inside guests.
• CFGM (Configuration Manager), provides a tree structure which holds configuration set- tings for the VM and all emulated devices.
• SSM (Saved State Manager), saves and loads VM state.
• VUSB (Virtual USB), a USB layer which separates emulated USB controllers from the con- trollers on the host and from USB devices; this also enables remote USB.
• DBGF (Debug Facility), a built-in VM debugger.
• VirtualBox emulates a number of devices to provide the hardware environment that var- ious guests need. Most of these are standard devices found in many PC compatible ma- chines and widely supported by guest operating systems. For network and storage devices in particular, there are several options for the emulated devices to access the underlying hardware. These devices are managed by PDM.
• Guest Additions for various guest operating systems. This is code that is installed from within a virtual machine; see chapter4,Guest Additions, page58.
• The “Main” component is special: it ties all the above bits together and is the only public API that VirtualBox provides. All the client processes listed above use only this API and never access the hypervisor components directly. As a result, third-party applications that use the VirtualBox Main API can rely on the fact that it is always well-tested and that all capabilities of VirtualBox are fully exposed. It is this API that is described in the VirtualBox SDK mentioned above (again, see chapter 11, VirtualBox programming interfaces, page
189).