Introduction

Oracle VDI (Virtual Desktop Infrastructure) provides desktop virtualization to replace personal computers with virtual machines (VMs) on a server. Users can access these VMs though any RDP client, or through the web via Sun Secure Global Desktop (SGD).

Oracle Virtual Desktop Infrastructure is made up of four main components: virtualization platform, session management (Oracle VDI Core), desktop access clients, and storage.

Figure 1 : Architecture of the Oracle Virtual Desktop Infrastructure

The basis for the Oracle Virtual Desktop Infrastructure architecture is the virtualization platform. In addition to creating and storing virtual machines, the virtualization platform offers the core functionality needed for virtual desktop management such as starting, stopping, and snapshotting virtual machines. Oracle Virtual Desktop Infrastructure 3.2 supports Oracle VM VirtualBox (the Oracle VDI Hypervisor), VMware vCenter, Microsoft Hyper-V, and Microsoft Remote Desktop Services as virtualization platforms.

Oracle VM VirtualBox is cross-platform x86 virtualization software that extends the power of your existing computers to run multiple operating systems, on the same hardware, at the same time, and alongside your existing applications.

Oracle VM VirtualBox includes a hypervisor for the host platform, an application programming interface (API) and software development kit (SDK) for managing guest virtual machines, a command-line tool for managing guests locally, a web service for remote management of guests, a wizard-style graphical tool to manage guests, a graphical console for displaying guest applications on the local host, and a built-in Remote Desktop Protocol (RDP) server that provides complete access to a guest from a remote client. At the core is the hypervisor, implemented as a ring 0 (privileged) kernel service. Figure 1.2 shows the relationships between all of these components.

Figure 2 : Architecture of an Oracle VirtualBox

The kernel service consists of a device driver named vboxsrv, which is responsible for tasks such as allocating physical memory for the guest virtual machine, and several loadable hypervisor modules for things like saving and restoring the guest process context when a host interrupt occurs, turning control over to the guest OS to begin execution, and deciding when VT-x or AMD-V events need to be handled.

The hypervisor does not get involved with the details of the guest operating system scheduling. Instead, those tasks are handled completely by the guest during its execution. The entire guest is run as a single process on the host system and will run only when scheduled by the host. If they are present, an administrator can use host resource controls such as scheduling classes and CPU caps or reservations to give very predictable execution of the guest machine.

Additional device drivers will be present to allow the guest machine access to other host resources such as disks, network controllers, and audio and USB devices. In reality, the hypervisor actually does little work. Rather, most of the interesting work in running the guest machine is done in the guest process. Thus the host's resource controls and scheduling methods can be used to control the guest machine behavior.

In addition to the kernel modules, several processes on the host are used to support running guests. All of these processes are started automatically when needed.