Full virtualization means that all sensitive functionality of an underlying platform is emulated by the hypervisor—for example device interaction and memory mapping. This makes it possible to deploy any unmodified software as a guest, the guest believing that it is actually executing on physical hardware.

This is implemented on a platform that lacks explicit hardware support for virtualization, by letting the hypervisor trap sensitive (privileged) instructions executed by the guest and emulate them in a sandboxed environment.

Full virtualization can also be hardware-assisted, for example the Intel VT or AMD-V technologies have CPU-specific support for running several operating systems at once. Hardware-supported virtualization dramatically reduces the emulation overhead in a hypervisor. Lately, other pieces of hardware than the CPU have also been equipped with virtualization support. One example would be network cards with built-in hardware support for virtualization.

Large performance benefits to virtualization have been achieved with hardware support. This seems to indicate that full virtualization is rapidly becoming the main virtualization paradigm in the market.

Paravirtualization is used to refer to a virtualized environment where the guest needs to know about the underlying hypervisor. Typically, in a paravirtualized environment, privileged actions need to be explicitly requested by the guest through calls to a public hypervisor API. This means that the guest has to communicate with a lower abstraction layer and consequently needs to know that it is virtualized.

Paravirtualization removes some of the flexibility of virtualization, as the guest (for example an operating system) needs to be modified before virtual deployment. An advantage might be that unnecessary layers of abstraction can be scaled away, enabling additional performance improvements at the price of less flexibility. Also, the end user rarely has to worry about the implementation of the underlying hypervisor. For example, on Xen, which originally was a paravirtualization-only hypervisor, the main use case is to run pre-packaged operating systems that have already been modified for paravirtualization. The user typically deploys his application on top of these.

With the emergence of high-performance hardware support for full virtualization, it is the authors' opinion that paravirtualization is becoming less important.

There are several other keywords in the virtualization area that have many different meanings, for example partial virtualization. Partial virtualization and paravirtualization are sometimes used interchangeably, but partial virtualization may also mean virtualizing only specific parts of the underlying hardware. For example, the term has been used to describe binary translation tools such as Rosetta on the Macintosh, enabling software compiled for PowerPC to run on Intel hardware. Partial virtualization may or may not require hardware support. Concepts like virtual memory in an operating system can also fall under the category partial virtualization.

Operating system level virtualization is another term that pops up from time to time. This typically describes some kind of isolation mechanism built into an OS for dividing the OS into separate instances, protected from one another, making them look like they are running on different physical machines. Solaris Containers is probably the most well-known example.

Recall that the hypervisor is the software layer that makes virtualization possible (optionally with the aid of explicit hardware support). The hypervisor provides an idealized view of a physical machine. All "dangerous operations" that would break the abstraction, such as device interaction and memory mapping, are trapped and emulated by the hypervisor.

Just as there are different types of virtualization, there are different types of hypervisors. Again, terminology is rather complicated. For the purposes of this book, we will discriminate only between hosted hypervisors and native hypervisors.

The main advantage of virtualization is, as we have mentioned, more efficient resource utilization. Several guests can compete for all resources of one physical machine. When one guest is idle, another guest may run. Virtualization may substantially decrease the idle time in the server room.

Another advantage is that virtualization further enables the "cloud computing" metaphor. As virtualized guests may be suspended, migrated to other physical machines, and resumed, an entire machine park can be abstracted as a cloud of computational power, on which deployments of applications may be made. This is usually facilitated through different management frameworks.

The main problem with virtualization is, of course, the extra overhead introduced by another abstraction layer, the hypervisor, in the stack between application and hardware. While hardware resource usage indeed gets more optimal in a virtualized environment, there are costs associated both with running several guests at once on a piece of physical hardware as well as with the extra overhead incurred by the hypervisor abstraction layer.

Now consider the case of a Java application in a virtual environment. For a standard, non-virtualized local Java application, the JVM provides one layer of abstraction against the hardware. The operating system on which the JVM runs provides another. The hypervisor layer that is responsible for emulating the virtual hardware below the OS adds yet another zone of abstraction between the application and its actual execution as native code.

We can try to make each layer of abstraction as thin and efficient as possible, but we can't make them go away altogether. For example, using hardware support to implement the hypervisor will decrease the virtualization overhead. However, we are still dealing with emulating physical hardware for the virtualized application. This naturally incurs overhead anyway.