Hypervisors add a level of indirection to the domain
of computer hardware. They provide the abstraction of a
virtual machine: each one thinks if is "king of the
hill," and has a whole machine to itself. Ideally, the VMs
should be just like the emulated machine, as fast as the
emulated machine, and completely isolated from each other.
VMware had these goals (general to most virtualization):
Any x86 OS, and all of its applications, should be able
to run on without modifications on the VM.
The overhead of the hypervisor had to be low enough the
users could use a VM as their primary machine.
Ideally, things run as fast as on a native OS, but at
least as fast as the previous chip generation.
The hypervisor had to ensure complete isolation of each
VM, i.e., be completely in charge of the real physical
resources. A VM might be infected with malicious code:
this will not impact any other VM.
There was tension between the requirements. E.g., total
compatibility might need to be sacrificed for performance.
But the designers held isolation as paramount.
The primary challenges were:
Dynamic binary translation: the VMM emulates
Problem: too slow for most uses. (5x)
Trap-and-emulate can be used when user
programs are running.
In other cases, resort to binary translation.
Run an algorithm to decide which to do.
This doesn't need to examine code, just
Binary translation must be used if:
The virtual machine is running in kernel mode (ring
The virtual machine can disable interrupts and
issue I/O instructions.
The virtual machine is running in real mode, a
legacy 16-bit mode used by BIOS.
VMware can speed up binary translation to near-native
speeds because it sets the hardware to run the code
instead of translating it in software.
Runs at 80% of native speed, instead of 20%.
A Guest Operating System Centric Strategy
Ideally, we want the hypervisor to emulate the
hardware so successfully that any OS that
runs on that hardware will run on the hypervisor.
With the x86 family, this was not possible: no
hardware support for virtualization, too complex.
So the VMware engineers focused on just a few, like
Linux, Windows 3.1, 95/98 and NT.
(But Minix ran as well, by accident.)
Only OS/2 ever used x86 rings 1 and 2, so VMware
would just shut down the VM if it tried to enter
The Virtual Hardware Platform
Software model that "looks like" the
device to the guest OS.
A back-end that communicates with the host OS.
Example: the "Lance" 10-Mbps ethernet card.
VMware "supported" this card long after the real thing
was off the market, and eventually could run 10x
The actual hardware did not have to be what the guest
OS thought was there! It just talked to the VMware
drivers, and they could be coupled with different
The Role of the Host Operating System
By creating a type 2 hypervisor, VMware could be
installed like a normal program.
It could use the host's drivers to handle the
problem of multiple peripherals.
But VMware needed to do fancy things an ordinary
application could not.
And many of those things an ordinary kernel-level
device driver shouldn't do either.
So, create three components:
VMX: a user-space program the user interacts
with: one per VM.
VMX driver: A small kernel-mode device
driver that can suspend the host OS for the...
VMM: multiplexes the CPU and memory;
contains trap-and-emulate, device drivers, shadow
paging module, binary translator.
Runs in kernel mode, but not "in" the host OS.
VMX runs as an OS process. But the VMM is a peer. The
VMX suspends the host OS and gives the VMM full control
of the machine. This is a world switch.
The VMM and the host OS have entirely
different address spaces.
Although earlier described as very time consuming, here
the book says the world switch only takes 45
The Evolution of the VMware Workstation
The VMM / hhost OS architecture remains the same.
But today, VMware Workstation can rely on:
Trap-and-emulate all the time
Nested hardware page tables instead of the shadow page
ESX Server: VMware's type 1 Hypervisor
Not having a host OS to rely upon means ESX has more work to do
than VMware Workstation. But in a situation where IT
organizations are trying to run 1000s of virtual machines, a
type 1 hypervisor makes sense: it will run significantly
The CPU scheduler ensures that each virtual machine
gets a fair share of the CPU: no starvation.