Xen and the Art of Virtualization
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
Xen and the Art of
Virtualization
*Paul Barham, *Boris Dragovic, *Keir Fraser, *Steven Hand, *Tim Harris,
*Alex Ho, *Rolf Neugebauer, *Ian Pratt, *Andrew Warfield
* * *
December 2003
SOSP '03: Proceedings of the nineteenth ACM symposium on
Operating systems principles
Publisher: ACM Apr. 29, 2009
OUTLINE • INTRODUCTION • APPROACH & OVERVIEW • DETAILED DESIGN • EVALUATION • CONCLUSIONS
INTRODUCTION • Virtual Machine Monitor (VMM) • Successful partitioning of a machine to support the concurrent execution of multiple OSes poses several challenges • VM must be isolated from one another • Support a variety of different OSes • The overhead should be small
INTRODUCTION • Xen allows multiple commodity OSes to share hardware in a safe and resource managed fashion but without sacrificing either performance or functionality • Target is hosting up to 100 virtual machine instances simultaneously on a server • Multiplexes physical resources at the granularity of an entirely operating system
APPROACH & OVERVIEW • In a traditional VMM the virtual hardware exposed is functionally identical to the underlying machine – full virtualization • Xen presents a virtual machine abstraction that is similar but not identical to the underlying hardware – paravirtualization • promises improved performance • not require changes to the application binary interface (API)
APPROACH & OVERVIEW
The Virtual Machine Interface
The paravirtualized x86 interfaceAPPROACH & OVERVIEW
The Cost of Porting an OS to Xen
The simplicity of porting commodity OSes to Xen.
The cost metric is the number of lines of reasonably
commented and formatted code which are modified or added
with the original x86 code base (excluding device drivers)APPROACH & OVERVIEW
Control and Management
The structure of a machine running the Xen hypervisor, hosting
a number of different guest operating systems, including Domain0
running control software in a XenoLinux environmentDETAILED DESIGN • Control Transfer: Hypercalls and Events • Data Transfer: I/O Rings • Subsystem Virtualization • Building a New Domain
DETAILED DESIGN
Control Transfer:
Hypercalls and Events
• Synchronous calls from a domain to Xen
are made using a hypercall to allows
domains to perform a privileged operation
• Notifications are delivered to domains
from Xen using an asynchronous event
mechanismDETAILED DESIGN
Data Transfer: I/O Rings
• Two main factors have shaped the design of
Xen’s I/O-transfer mechanism
• resource management: I/O buffers are
protected during data transfer by pinning
the underlying page frames within Xen
• event notification: allows each domain to
trade-off latency and throughput
requirementsDETAILED DESIGN Data Transfer: I/O Rings The structure of asynchronous I/O rings, which are used for data transfer between Xen and guest OSes
DETAILED DESIGN Subsystem Virtualization • CPU Scheduling • Time and Timers • Virtual Address Translation • Physical Memory • Network • Disk
DETAILED DESIGN ― Subsystem Virtualization
CPU Scheduling
• Xen schedules domains according to the
Borrowed Virtual Time (BVT) algorithm
• since it is both work-conserving and has
a special mechanism for low-latency
wake-up (or dispatch) of a domain when
it receives an event
• Ex: TCP relies on the timely delivery of acks
to correctly estimate network RTTsDETAILED DESIGN ― Subsystem Virtualization
Time and Timer
• Xen provides guest OSes with notions of
• real time: expressed in nanoseconds
passed since machine boot
• virtual time: only advances while it is
executing
• wall-clock time: specified as an offset to
be added to the current real timeDETAILED DESIGN ― Subsystem Virtualization
Virtual Address Translation
• Xen need only be involved in page table
updates to prevent OSes from making
unacceptable changes
• registers guest OS page tables directly
with the MMU, and restrict guest OSes
to read-only access
• Page table updates are passed to Xen via
hypercall and requests are validated before
being appliedDETAILED DESIGN ― Subsystem Virtualization
Physical Memory
• The initial memory allocation, or
reservation, for each domain is specified at
the time of its creation
• Mapping from physical to hardware address
is entirely the responsibility of the guest OS
• Xen supports efficient hardware-to-physical
mapping by providing a shared translation
array that is directly readable by all domainsDETAILED DESIGN ― Subsystem Virtualization
Network
• Xen provides the abstraction of virtual
firewall-router (VFR) where each domain
has one or more network interface (VIFs)
logically attached to VFR
• There are two I/O rings of buffer
descriptors, one for transmit and one for
receive
• Each direction also has a list of associated
rules of the form (, )DETAILED DESIGN ― Subsystem Virtualization
Disk
• Only domain0 has direct unchecked access
to physical (IDE and SCSI) disks
• All other domains access persistent storage
through the abstraction of virtual block
devices (VBDs)
• A translation table is maintained within the
hypervisor for each VBDDETAILED DESIGN Building a New Domain • The task of building the initial guest OS structures for a new domain is mostly delegated to Domain0 • The ease with which the building process can be extended and specialized to cope with new OSes
EVALUATION • Relative Performance • Operating System Benchmarks • Concurrent Virtual Machines • Performance Isolation • Scalability
EVALUATION • A Dell 2650 dual processor 2.4GHz Xeon server with 2GB RAM • A Broadcom Tiger 3 Gigabit Ethernet NIC • A Single Hitachi 146GB 10k RPM SCSI disk • Linux kernel version: 2.4.21 • RedHat 7.2 and ext3 file system
EVALUATION Relative Performance Relative performance of native Linux (L), XenoLinux (X), VMWare workstation 3.2 (V) and User-Mode Linux (U)
EVALUATION
Relative Performance
The SPEC CPU suite contains
a series of long-running
computationally-intensive
application intended to
measure the performance of a
system’s processor, memory
system, and compiler quality.
Relative performance of native Linux (L), XenoLinux (X),
VMWare workstation 3.2 (V) and User-Mode Linux (U)EVALUATION
Relative Performance
• Total elasped time taken
to build a default
configuration of the
Linux 2.4.21 kernel
• Native Linux spends
about 7% of the CPU
time in the OS
Relative performance of native Linux (L), XenoLinux (X),
VMWare workstation 3.2 (V) and User-Mode Linux (U)EVALUATION Relative Performance Performed using Presents results for the PostgreSQL the multi-user 7.1.3 database, Information exercised by the Retrieval (IR) and Open Source On-Line Database Transaction Benchmark (OSDB) Processing (OLTP) suite in its default configuration Relative performance of native Linux (L), XenoLinux (X), VMWare workstation 3.2 (V) and User-Mode Linux (U)
EVALUATION
Relative Performance
• The dbench program is a file
system benchmark derived
from the industry-standard
NetBench
• Examines the throughput
experienced by a single client
performing around 90,000 file
system operations
Relative performance of native Linux (L), XenoLinux (X),
VMWare workstation 3.2 (V) and User-Mode Linux (U)EVALUATION
Relative Performance
• SPEC WEB99 is a complex
application-level benchmark for
evaluating web services and the
systems that host them
• Workload: 30% require dynamic
content generation, 16% are
HTTP POST operations and
0.5% execute a CGI script
Relative performance of native Linux (L), XenoLinux (X),
VMWare workstation 3.2 (V) and User-Mode Linux (U)EVALUATION Operating System Benchmarks • Examined the overhead of virtualization as measured by McVoy’s lmbench program • The OS performance subset of the lmbench suite consist of 37 microbenchmark
EVALUATION
Operating System Benchmarks
lmbench: Processes - times in µsEVALUATION
Operating System Benchmarks
lmbench: Context switching times in µsEVALUATION Operating System Benchmarks lmbench: File & VM system latencies in µs
EVALUATION
Operating System Benchmarks
Network Performance
ttcp: Bandwidth in Mb/sEVALUATION
Concurrent Virtual Machines
SPEC WEB99 for 1, 2, 4, 8 and 16 concurrent Apache servers:
Higher values are betterCONCLUSIONS • Xen provides an excellent platform for deploying a wide variety of network-centric services • The performance of XenoLinux over Xen is practically equivalent to the performance of the baseline Linux system
You can also read
