view docs/src/user/introduction.tex @ 7176:0e1838de9db8

Move XendDomainInfo.{create,recreate,parseConfig} to the top level of the
domain. This allows us to refer to them using an import statement, rather than
a from .. import. This is a step towards getting rid of the xroot hack. All
other references to XendDomainInfo methods need to be doubly qualified (once
for the module, once for the class).

Remove XendDomainDict, replacing it with a simple dictionary, folding the
get_by_name method into XendDomain.

Replace XendDomain.refresh_lock with a domains_lock which goes around any
reference to XendDomain.domains or anything that will create or destroy a
domain. This serialises most accesses through XendDomain, ensuring that we will
not return stale state when racing against the watches fired in separate
threads. This should have fixed bugs #270 and #234.

Added a number of domain_get_xyz methods. Those named xyz_nr are to allow
components internal to XendDomain (XendDomainInfo, XendCheckpoint) to call back
into XendDomain without triggering further calls to XendDomain.refresh. The
other methods simply make it clear which fallback behaviour is expected.

Replace XendDomainInfo.domain_exists with XendDomainInfo.domain_by_name; the
internals of this method needed to change to match those changes above, and it
has been a misnomer for some time.

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