diff options
Diffstat (limited to 'docs/src/user/introduction.tex')
| -rw-r--r-- | docs/src/user/introduction.tex | 152 |
1 files changed, 0 insertions, 152 deletions
diff --git a/docs/src/user/introduction.tex b/docs/src/user/introduction.tex deleted file mode 100644 index 5e7acf780d..0000000000 --- a/docs/src/user/introduction.tex +++ /dev/null @@ -1,152 +0,0 @@ -\chapter{Introduction} - - -Xen is a \emph{para-virtualizing} 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 typically 94-98\% of native hardware. -\item Live migration of running virtual machines between physical hosts. -\item Excellent hardware support. Supports most Linux device drivers. -\item Sand-boxed, re-startable device drivers. -\end{itemize} - -Para-virtualization permits very high performance virtualization, even -on architectures like x86 that are traditionally very hard to -virtualize. - -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 para-virtual 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. - -With hardware CPU virtualization as provided by Intel VT and AMD -Pacifica technology, the ability to run an unmodified guest OS kernel is -available. No porting of the OS is required; however some additional -driver support is necessary within Xen itself. Unlike traditional full -virtualization hypervisors, which suffer a tremendous performance -overhead, the combination of Xen and VT or Xen and Pacifica technology -complement one another to offer superb performance for para-virtualized -guest operating systems and full support for unmodified guests, which -run natively on the processor without need for emulation, under VT. -Full support for VT and Pacifica chipsets will appear in early 2006. - -Xen support is available for increasingly many operating systems: -currently, Linux and NetBSD are available for Xen 3.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). - -%% KMSelf Thu Dec 1 14:59:02 PST 2005 PPC port status? - -Possible usage scenarios for Xen include: - -\begin{description} -\item [Kernel development.] Test and debug kernel modifications in a - sand-boxed 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 the - 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 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. -This management includes the responsibility of 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 there is basic support for HyperThreading (SMT), although -this remains a topic for ongoing research. A port specifically for -x86/64 is in progress. 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 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''. Xen plays a key part in that, allowing one to -efficiently partition a single machine to enable multiple independent -clients to run their operating systems and applications in an -environment. This environment provides 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 grown into a fully-fledged project in its own right, enabling us -to investigate interesting research issues regarding the best techniques -for virtualizing 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 3.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 virtualization. |