To create several
virtual servers on one physical machine, a new software layer is necessary: the
hypervisor, also called Virtual Machine Monitor (VMM). The most
important role is to arbitrate the access to the underlying hardware, so that guest
OSes can share the machine. You could say that a VMM manages virtual machines (Guest
OS + applications) like an OS manages processes and threads.

To understand
how the VMM actually works, we first have to understand how a modern operating systems
works. Most modern operating system work with two modes:

A
kernel mode that is allowed to run almost any CPU instructions,
including "privileged" instructions that deal with interrupts, memory
management, and so on. This is of course the mode that the operating system runs
in.

A user mode that allows only instructions that are
necessary to calculate and process data. Applications run in this mode and can only
make use of the hardware by asking the kernel to do some work (a system call).

The whole
user/kernel mode arrangement is based on the fact that RAM is divided into
pages. (It is also possible to work with segment registers and tables, but that
is a discussion for another article.) Before a privileged instruction is executed,
the CPU first checks if the page from where the instruction originates actually
has the right 2-bit code. The most privileged instructions require a 00 "privilege
code". This 2-bit code allows four levels of code, with "11" being
the lowest level.

To illustrate
this, this 2-bit code is graphically represented in many publications by four "onion
rings" (as you can see in this article). Ring 0 is the most privileged
layer, ring 1 is a bit less privileged, and ring 3 is where the user applications
reside with no privileges to manage the hardware resources at all.

Ring
deprivileging with software virtualization: the guest OSes are no longer
running in ring 0, but with less rights in ring 1.

A technique that all (software
based) virtualization solutions use is thus ring deprivileging: the operating system
that runs originally on ring 0 is moved to another less privileged ring like ring
1. This allows the VMM to control the guest OS access to resources. It avoids for
example one guest OS kicking another out of memory, or a guest OS controlling the
hardware directly.