10 Technical background • 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 debuger. • 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 chapter 4, Guest Additions, page 53. • 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 163). 10.3 Hardware vs. software virtualization VirtualBox allows software in the virtual machine to run directly on the processor of the host, but an array of complex techniques is employed to intercept operations that would interfere with your host. Whenever the guest attempts to do something that could be harmful to your computer and its data, VirtualBox steps in and takes action. In particular, for lots of hardware that the guest believes to be accessing, VirtualBox simulates a certain “virtual” environment according to how you have configured a virtual machine. For example, when the guest attempts to access a hard disk, VirtualBox redirects these requests to whatever you have configured to be the virtual machine’s virtual hard disk – normally, an image file on your host. Unfortunately, the x86 platform was never designed to be virtualized. Detecting situations in which VirtualBox needs to take control over the guest code that is executing, as described above, is difficult. There are two ways in which to achive this: • Since 2006, Intel and AMD processors have had support for so-called “hardware virtu- alization”. This means that these processors can help VirtualBox to intercept potentially dangerous operations that a guest operating system may be attempting and also makes it easier to present virtual hardware to a virtual machine. These hardware features differ between Intel and AMD processors. Intel named its tech- nology VT-x AMD calls theirs AMD-V. The Intel and AMD support for virtualization is very different in detail, but not very different in principle. Note: On many systems, the hardware virtualization features first need to be enabled in the BIOS before VirtualBox can use them. 157