1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
|
\chapter{Introduction}
Xen is a \emph{paravirtualising} virtual machine monitor (VMM), or
`hypervisor', for the x86 processor architecture. Xen can securely
execute multiple virtual machines on a single physical system with
close-to-native performance. The virtual machine technology
facilitates enterprise-grade functionality, including:
\begin{itemize}
\item Virtual machines with performance close to native hardware.
\item Live migration of running virtual machines between physical
hosts.
\item Excellent hardware support (supports most Linux device drivers).
\item Sandboxed, re-startable device drivers.
\end{itemize}
Paravirtualisation permits very high performance virtualisation, even
on architectures like x86 that are traditionally very hard to
virtualise.
The drawback of this approach is that it requires operating systems to
be \emph{ported} to run on Xen. Porting an OS to run on Xen is
similar to supporting a new hardware platform, however the process is
simplified because the paravirtual machine architecture is very
similar to the underlying native hardware. Even though operating
system kernels must explicitly support Xen, a key feature is that user
space applications and libraries \emph{do not} require modification.
Xen support is available for increasingly many operating systems:
right now, Linux and NetBSD are available for Xen 2.0.
A FreeBSD port is undergoing testing and will be incorporated into the
release soon. Other OS ports, including Plan 9, are in progress. We
hope that that arch-xen patches will be incorporated into the
mainstream releases of these operating systems in due course (as has
already happened for NetBSD).
Possible usage scenarios for Xen include:
\begin{description}
\item [Kernel development.] Test and debug kernel modifications in a
sandboxed virtual machine --- no need for a separate test machine.
\item [Multiple OS configurations.] Run multiple operating systems
simultaneously, for instance for compatibility or QA purposes.
\item [Server consolidation.] Move multiple servers onto a single
physical host with performance and fault isolation provided at
virtual machine boundaries.
\item [Cluster computing.] Management at VM granularity provides more
flexibility than separately managing each physical host, but better
control and isolation than single-system image solutions,
particularly by using live migration for load balancing.
\item [Hardware support for custom OSes.] Allow development of new
OSes while benefiting from the wide-ranging hardware support of
existing OSes such as Linux.
\end{description}
\section{Structure of a Xen-Based System}
A Xen system has multiple layers, the lowest and most privileged of
which is Xen itself.
Xen in turn may host multiple \emph{guest} operating systems, each of
which is executed within a secure virtual machine (in Xen terminology,
a \emph{domain}). Domains are scheduled by Xen to make effective use
of the available physical CPUs. Each guest OS manages its own
applications, which includes responsibility for scheduling each
application within the time allotted to the VM by Xen.
The first domain, \emph{domain 0}, is created automatically when the
system boots and has special management privileges. Domain 0 builds
other domains and manages their virtual devices. It also performs
administrative tasks such as suspending, resuming and migrating other
virtual machines.
Within domain 0, a process called \emph{xend} runs to manage the
system. \Xend is responsible for managing virtual machines and
providing access to their consoles. Commands are issued to \xend over
an HTTP interface, either from a command-line tool or from a web
browser.
\section{Hardware Support}
Xen currently runs only on the x86 architecture, requiring a `P6' or
newer processor (e.g. Pentium Pro, Celeron, Pentium II, Pentium III,
Pentium IV, Xeon, AMD Athlon, AMD Duron). Multiprocessor machines are
supported, and we also have basic support for HyperThreading (SMT),
although this remains a topic for ongoing research. A port
specifically for x86/64 is in progress, although Xen already runs on
such systems in 32-bit legacy mode. In addition a port to the IA64
architecture is approaching completion. We hope to add other
architectures such as PPC and ARM in due course.
Xen can currently use up to 4GB of memory. It is possible for x86
machines to address up to 64GB of physical memory but there are no
current plans to support these systems: The x86/64 port is the planned
route to supporting larger memory sizes.
Xen offloads most of the hardware support issues to the guest OS
running in Domain~0. Xen itself contains only the code required to
detect and start secondary processors, set up interrupt routing, and
perform PCI bus enumeration. Device drivers run within a privileged
guest OS rather than within Xen itself. This approach provides
compatibility with the majority of device hardware supported by Linux.
The default XenLinux build contains support for relatively modern
server-class network and disk hardware, but you can add support for
other hardware by configuring your XenLinux kernel in the normal way.
\section{History}
Xen was originally developed by the Systems Research Group at the
University of Cambridge Computer Laboratory as part of the XenoServers
project, funded by the UK-EPSRC.
XenoServers aim to provide a `public infrastructure for global
distributed computing', and Xen plays a key part in that, allowing us
to efficiently partition a single machine to enable multiple
independent clients to run their operating systems and applications in
an environment providing protection, resource isolation and
accounting. The project web page contains further information along
with pointers to papers and technical reports:
\path{http://www.cl.cam.ac.uk/xeno}
Xen has since grown into a fully-fledged project in its own right,
enabling us to investigate interesting research issues regarding the
best techniques for virtualising resources such as the CPU, memory,
disk and network. The project has been bolstered by support from
Intel Research Cambridge, and HP Labs, who are now working closely
with us.
Xen was first described in a paper presented at SOSP in
2003\footnote{\tt
http://www.cl.cam.ac.uk/netos/papers/2003-xensosp.pdf}, and the
first public release (1.0) was made that October. Since then, Xen has
significantly matured and is now used in production scenarios on many
sites.
Xen 2.0 features greatly enhanced hardware support, configuration
flexibility, usability and a larger complement of supported operating
systems. This latest release takes Xen a step closer to becoming the
definitive open source solution for virtualisation.
|
