YouTube placeholder

Full Virtualization

What Is Virtualization?

Until today we’ve been talking about operating systems running on physical machines: a collection of

  1. real hardware resources,

  2. that the operating system has exclusive access to

  3. through hardware interfaces (instruction set architectures, device I/O ports, etc.

Operating systems can also run inside virtual machines (VMs) implemented by virtual machine monitors (VMMs).

  • We refer to an operating system running inside a virtual machine as a guest OS.

Virtual machines differ from physical machines in important ways.

  • They do not provide the guest OS with exclusive access to the underlying physical machine.

  • Equivalently, they do not provide the guest OS with privileged (or fully-privileged) access to the physical machine.

Et voila: the virtual machine monitor (VMM) is

  1. a piece of software running on an operating system (the host OS)

  2. that can allow another operating system (the guest OS) to be run as an application

  3. alongside other applications.

  • When we said that the operating system was really just another program we weren’t kidding!

Meme

This is not

The only matrix

Why Virtualize?

(Clearly there is a big how question here, but let’s start with why!)

  • We’ve been talking about operating systems all semester…​

  • …​and I hope by this point I’ve convinced you that they are pretty great.

But just for the sake of argument…​ what might be some problems with the operating system environments we’ve discussed thus far?

Problems with Operating Systems: Hardware Coupling

Unfortunate coupling between hardware resources and the operating system.

  1. Hard to run multiple operating systems on the same machine. (Geeky.)

  2. Difficult to transfer software setups to another machine, unless it has identical or nearly identical hardware.

  3. Messy to adjust hardware resources to system needs. Requires sticking your hand in the box and mucking around.

  4. Requires static, up-front provision of machine resources.

Problems with Operating Systems: Application Isolation

Lack of true isolation between multiple applications.

  1. Operating systems "leak" a lot of information between processes through the file system and other channels.

  2. Multiple applications may require specific (and conflicting) software packages to run.

  3. Certain applications may have very specific operating systems configuration and tuning requirements.

  4. In some cases, software vendors will not provide support if you are running their precious application alongside anything else.

Why We Virtualize

  • We can package and distribute an entire software development environment which can be used and discarded.

  • We can dynamically divide up one large machine into multiple smaller machines, each running a different operating system and applications.

  • We can easily replicate an entire machine image in order to duplicate or move it.

To Be a VMM

In 1974 (!) Popek and Goldberg provide three essential requirements for a piece of software to be considered a virtual machine monitor (VMM), or to implement a virtual machine:

  1. Fidelity: software on the VMM executes identically to how it would on real hardware (modulo timing effects).

  2. Performance: to achieve good performance most instructions executed by the guest OS should be run directly on the underlying physical hardware.

  3. Safety: the VMM should manage all hardware resources.

Two Approaches to Virtualization

  • Full virtualization. Should be able to run an unmodified guest OS. We will discuss this today.

  • Paravirtualization. Includes small changes to the guest operating system to improve interaction with the virtual machine monitor. We will read this paper for Monday.

Full Virtualization

Our goal: run an unmodified operating system and applications in a VM itself running on a host OS and potentially next to other VMs.

  • VMware is the best-known provider of full virtualization software solutions.

Why is this hard?

  • How do we handle traps by applications running in the guest OS?

  • Guest OS will try to execute privileged instructions!

De-Privileging the Guest OS

What happens if we run the Guest OS with kernel privileges?

  • Privileged instructions work as expected, but guest has access to the entire machine! (Violates safety.)

What happens if we run the Guest OS with user privileges?

  • Need to figure out how to deal with privileged instructions…​

Trapping Privileged Instructions

Ideally, when privileged instructions are run by the guest OS at user privilege level:

  1. The CPU traps the instruction due to a privilege violation.

  2. The trap is handled by the VMM.

  3. Assuming the guest OS is doing something legitimate, the VMM adjusts the VM state and continues the guest OS.

  • We refer to an instruction set having this property as classically virtualizable.

  • We refer to the approach described above as trap and emulate.

Trap and Emulate

What does the VMM do with traps that occur within the virtual machine?

  • If the trap is caused by an application, pass the trap to the guest OS.

  • If the trap is caused by the guest OS, handle the trap by adjusting the state of the virtual machine.

Getting Trappy

VMware and VirtualBox VMMs run as standard system processes but require operating system support.

  • All traps and exceptions originating inside the VM must be handled by the VMM.

  • Most of the time guest applications and the guest OS simply use the physical processor normally.

What happens when an application running inside the virtual machine makes a system call?

  1. syscall: host OS vectors trap to VMM.

  2. VMM inspects trap, identifies it as a system call, and passes control and arguments to the guest OS trap handling code.

  3. rfe: when the guest OS is done, it will also trap back to the VMM by executing a privileged instruction.

  4. VMM will pass arguments back to the process that originated the system call.

Getting (Really) Trappy

What happens when a process inside the virtual machine creates a TLB fault?

  1. Trap to the host OS.

  2. Hand trap to the VMM.

  3. VMM inspects trap, sees that it was generated by the application, passes control to the guest OS.

  4. Guest OS begins handling the TLB fault, tries to load an entry into the TLB.

  5. Trap to the host OS.

  6. Hand trap to the VMM.

  7. VMM inspects trap, sees that it was generated by the guest OS, adjusts the state of the virtual machine appropriately.

Hardware Virtualization

Note that what is being virtualized is the hardware interface.

Let’s compare to virtual memory:

What is the interface?

  • Load and store.

How do we ensure safety?

Translate every unprivileged memory access.

How do we get good performance?

  • Cache translations in the TLB.

What about full hardware virtualization:

What is the interface?

  • All instructions executed on the processor that modify the state of the machine.

How do we ensure safety?

  • Intercept or rewrite unsafe instructions that could "pierce" the VM.

How do we get good performance?

  • Allow safe instructions to run directly on the physical hardware (or "bare metal").

Sadly

The x86 architecture is not (or was not) classically virtualizable.

  • Some instructions did not trap correctly.

  • Others had different side effects when run in kernel or user mode. Ugh.

VMware developed an innovative solution to this problem: binary translation.

  • During guest OS execution scan code pages for non-virtualizable instructions and rewrite them to safe instruction sequences.

  • Cache translations to improve performance.

A Short, Non-Exhaustive List of Cool Details I Have Glossed Over

  • x86 privilege rings.

  • Primary and shadow page tables.

  • Memory traces.

  • x86 extensions to better support virtualization.

  • Lot’s of good resources out there to learn more.

Next Time

  • Paravirtualization.

Created 2/17/2017
Updated 9/18/2020
Commit 4eceaab // History // View
Built 4/17/2016 @ 20:00 EDT