|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-changelog] Reorg patch 2 to match http://wiki.xensource.com/xenwiki/Xen3DocsToDo
# HG changeset patch # User Robb Romans <FMJ@xxxxxxxxxx> # Node ID dceb2fcdab5bc623e79c13b302759c362caf9b26 # Parent 63f9c8dd13d4282543b9ccf37211c78dc354da6b Reorg patch 2 to match http://wiki.xensource.com/xenwiki/Xen3DocsToDo Second patch to reorganize the manual to match the structure in the Xen3DocsToDo Wiki entry. diff -r 63f9c8dd13d4 -r dceb2fcdab5b docs/src/user.tex --- a/docs/src/user.tex Fri Dec 2 21:29:25 2005 +++ b/docs/src/user.tex Fri Dec 2 21:29:26 2005 @@ -60,8 +60,6 @@ \setstretch{1.1} -\part{Introduction} - %% Chapter Introduction moved to introduction.tex \include{src/user/introduction} @@ -80,38 +78,77 @@ %% Chapter Installing Xen on Gentoo Linux \include{src/user/gentoo} +%% Chapter Installing Xen on SuSE or SuSE SLES +\include{src/user/suse} + %% Chapter Installing Xen on Red Hat Enterprise Linux (RHEL) \include{src/user/rhel} -%% Chapter Installing Xen on SuSE or SuSE SLES -\include{src/user/suse} +% Chapter dom0 Installation +\include{src/user/dom0_installation} + +% Chapter domU Installation +\include{src/user/domU_installation} + +% Building Xen +\include{src/user/building_xen} + +% Booting Xen +\include{src/user/booting_xen} \part{Configuration and Management} + +%% Chapter Domain Management Tools and Daemons +\include{src/user/domain_mgmt} %% Chapter Starting Additional Domains \include{src/user/start_addl_dom} -%% Chapter Domain Management Tools -\include{src/user/domain_mgmt} - -%% Chapter Domain Filesystem Storage -\include{src/user/domain_filesystem} - %% Chapter Domain Configuration \include{src/user/domain_configuration} +% Chapter Console Management +\include{src/user/console_management} + +% Chapter Network Management +\include{src/user/network_management} + +% Chapter Storage and FileSytem Management +\include{src/user/domain_filesystem} + +% Chapter Memory Management +\include{src/user/memory_management} + +% Chapter CPU Management +\include{src/user/cpu_management} + +% Chapter Scheduler Management +\include{src/user/scheduler_management} + +% Chapter Migrating Domains +\include{src/user/migrating_domains} + %% Chapter Securing Xen \include{src/user/securing_xen} -\part{Troubleshooting} +\part{Monitoring and Troubleshooting} %% Chapter Monitoring Xen \include{src/user/monitoring_xen} -%% Chapter Debugging and Tracing +% Chapter xenstat +\include{src/user/xenstat} + +% Chapter Log Files +\include{src/user/logfiles} + +%% Chapter Debugging \include{src/user/debugging} + +% Chapter xentrace +\include{src/user/xentrace} %% Chapter Known Problems \include{src/user/known_problems} diff -r 63f9c8dd13d4 -r dceb2fcdab5b docs/src/user/control_software.tex --- a/docs/src/user/control_software.tex Fri Dec 2 21:29:25 2005 +++ b/docs/src/user/control_software.tex Fri Dec 2 21:29:26 2005 @@ -1,101 +1,10 @@ \chapter{Control Software} - -The Xen control software includes the \xend\ node control daemon -(which must be running), the xm command line tools, and the prototype -xensv web interface. - -\section{\Xend\ (node control daemon)} -\label{s:xend} - -The Xen Daemon (\Xend) performs system management functions related to -virtual machines. It forms a central point of control for a machine -and can be controlled using an HTTP-based protocol. \Xend\ must be -running in order to start and manage virtual machines. - -\Xend\ must be run as root because it needs access to privileged -system management functions. A small set of commands may be issued on -the \xend\ command line: - -\begin{tabular}{ll} - \verb!# xend start! & start \xend, if not already running \\ - \verb!# xend stop! & stop \xend\ if already running \\ - \verb!# xend restart! & restart \xend\ if running, otherwise start it \\ - % \verb!# xend trace_start! & start \xend, with very detailed debug logging \\ - \verb!# xend status! & indicates \xend\ status by its return code -\end{tabular} - -A SysV init script called {\tt xend} is provided to start \xend\ at -boot time. {\tt make install} installs this script in -\path{/etc/init.d}. To enable it, you have to make symbolic links in -the appropriate runlevel directories or use the {\tt chkconfig} tool, -where available. - -Once \xend\ is running, more sophisticated administration can be done -using the xm tool (see Section~\ref{s:xm}) and the experimental Xensv -web interface (see Section~\ref{s:xensv}). - -As \xend\ runs, events will be logged to \path{/var/log/xend.log} and, -if the migration assistant daemon (\path{xfrd}) has been started, -\path{/var/log/xfrd.log}. These may be of use for troubleshooting -problems. - -\section{Xm (command line interface)} -\label{s:xm} - -The xm tool is the primary tool for managing Xen from the console. -The general format of an xm command line is: - -\begin{verbatim} -# xm command [switches] [arguments] [variables] -\end{verbatim} - -The available \emph{switches} and \emph{arguments} are dependent on -the \emph{command} chosen. The \emph{variables} may be set using -declarations of the form {\tt variable=value} and command line -declarations override any of the values in the configuration file -being used, including the standard variables described above and any -custom variables (for instance, the \path{xmdefconfig} file uses a -{\tt vmid} variable). - -The available commands are as follows: - -\begin{description} -\item[mem-set] Request a domain to adjust its memory footprint. -\item[create] Create a new domain. -\item[destroy] Kill a domain immediately. -\item[list] List running domains. -\item[shutdown] Ask a domain to shutdown. -\item[dmesg] Fetch the Xen (not Linux!) boot output. -\item[consoles] Lists the available consoles. -\item[console] Connect to the console for a domain. -\item[help] Get help on xm commands. -\item[save] Suspend a domain to disk. -\item[restore] Restore a domain from disk. -\item[pause] Pause a domain's execution. -\item[unpause] Un-pause a domain. -\item[pincpu] Pin a domain to a CPU. -\item[bvt] Set BVT scheduler parameters for a domain. -\item[bvt\_ctxallow] Set the BVT context switching allowance for the - system. -\item[atropos] Set the atropos parameters for a domain. -\item[rrobin] Set the round robin time slice for the system. -\item[info] Get information about the Xen host. -\item[call] Call a \xend\ HTTP API function directly. -\end{description} - -For a detailed overview of switches, arguments and variables to each -command try -\begin{quote} -\begin{verbatim} -# xm help command -\end{verbatim} -\end{quote} \section{Xensv (web control interface)} \label{s:xensv} Xensv is the experimental web control interface for managing a Xen -machine. It can be used to perform some (but not yet all) of the +machine. It can be used to perform some (but not yet all) of the management tasks that can be done using the xm tool. It can be started using: @@ -107,7 +16,7 @@ \verb_# xensv stop_ \end{quote} -By default, Xensv will serve out the web interface on port 8080. This +By default, Xensv will serve out the web interface on port 8080. This can be changed by editing \path{/usr/lib/python2.3/site-packages/xen/sv/params.py}. diff -r 63f9c8dd13d4 -r dceb2fcdab5b docs/src/user/debian.tex --- a/docs/src/user/debian.tex Fri Dec 2 21:29:25 2005 +++ b/docs/src/user/debian.tex Fri Dec 2 21:29:26 2005 @@ -2,11 +2,11 @@ The Debian project provides a tool called \path{debootstrap} which allows a base Debian system to be installed into a filesystem without -requiring the host system to have any Debian-specific software (such -as \path{apt}). +requiring the host system to have any Debian-specific software (such as +\path{apt}). -Here's some info how to install Debian 3.1 (Sarge) for an unprivileged -Xen domain: +Here's some info on how to install Debian 3.1 (Sarge) for an +unprivileged Xen domain: \begin{enumerate} @@ -14,13 +14,12 @@ this manual. \item Create disk images for rootfs and swap. Alternatively, you might - create dedicated partitions, LVM logical volumes, etc.\ if that - suits your setup. + create dedicated partitions, LVM logical volumes, etc.\ if that suits + your setup. \begin{verbatim} dd if=/dev/zero of=/path/diskimage bs=1024k count=size_in_mbytes dd if=/dev/zero of=/path/swapimage bs=1024k count=size_in_mbytes \end{verbatim} - If you're going to use this filesystem / disk image only as a `template' for other vm disk images, something like 300 MB should be enough. (of course it depends what kind of packages you are planning @@ -38,25 +37,25 @@ \end{verbatim} \item Install \path{debootstrap}. Make sure you have debootstrap - installed on the host. If you are running Debian Sarge (3.1 / - testing) or unstable you can install it by running \path{apt-get - install debootstrap}. Otherwise, it can be downloaded from the - Debian project website. + installed on the host. If you are running Debian Sarge (3.1 / testing) + or unstable you can install it by running \path{apt-get install + debootstrap}. Otherwise, it can be downloaded from the Debian + project website. \item Install Debian base to the disk image: \begin{verbatim} debootstrap --arch i386 sarge /mnt/disk \ http://ftp.<countrycode>.debian.org/debian \end{verbatim} - - You can use any other Debian http/ftp mirror you want. + You may use any Debian mirror that you want. \item When debootstrap completes successfully, modify settings: \begin{verbatim} chroot /mnt/disk /bin/bash \end{verbatim} -Edit the following files using vi or nano and make needed changes: + Edit the following files using vi or nano and make any required + changes: \begin{verbatim} /etc/hostname /etc/hosts @@ -65,36 +64,36 @@ /etc/networks \end{verbatim} -Set up access to the services, edit: + Set up access to the services. Edit: \begin{verbatim} /etc/hosts.deny /etc/hosts.allow /etc/inetd.conf \end{verbatim} -Add Debian mirror to: + Add Debian mirror to: \begin{verbatim} /etc/apt/sources.list \end{verbatim} -Create fstab like this: + Create fstab like this: \begin{verbatim} /dev/sda1 / ext3 errors=remount-ro 0 1 /dev/sda2 none swap sw 0 0 proc /proc proc defaults 0 0 \end{verbatim} -Logout + Logout \item Unmount the disk image \begin{verbatim} umount /mnt/disk \end{verbatim} -\item Create Xen 2.0 configuration file for the new domain. You can - use the example-configurations coming with Xen as a template. +\item Create Xen 3.0 configuration file for the new domain. You may use + the example-configurations provided with Xen as a template. - Make sure you have the following set up: + Make sure you have the correctly configured: \begin{verbatim} disk = [ 'file:/path/diskimage,sda1,w', 'file:/path/swapimage,sda2,w' ] root = "/dev/sda1 ro" @@ -105,21 +104,20 @@ xm create -f domain_config_file \end{verbatim} -Check that the new domain is running: + Check that the new domain is running: \begin{verbatim} xm list \end{verbatim} -\item Attach to the console of the new domain. You should see - something like this when starting the new domain: +\item Attach to the console of the new domain. You should see something + like this when starting the new domain: \begin{verbatim} Started domain testdomain2, console on port 9626 \end{verbatim} - There you can see the ID of the console: 26. You can also list the - consoles with \path{xm consoles} (ID is the last two digits of the - port number.) + You can see the ID of the console: 26. You can also list the consoles + with \path{xm consoles}. ID is the last two digits of the port number. Attach to the console: @@ -127,28 +125,26 @@ xm console 26 \end{verbatim} - or by telnetting to the port 9626 of localhost (the xm console - program works better). + or by telnetting to the port 9626 of localhost. The xm console program + works better. \item Log in and run base-config - As a default there's no password for the root. + By default there is no password set for root. - Check that everything looks OK, and the system started without - errors. Check that the swap is active, and the network settings are - correct. + Check that everything looks OK, and the system started without errors. + Check that the swap is active, and the network settings are correct. - Run \path{/usr/sbin/base-config} to set up the Debian settings. + Run \path{/usr/sbin/base-config} to configure the Debian settings. - Set up the password for root using passwd. + Set the password for root using \path{passwd}. -\item Done. You can exit the console by pressing {\path{Ctrl + ]}} +\item Done. You may exit the console by pressing {\path{Ctrl + ]}} \end{enumerate} - -If you need to create new domains, you can just copy the contents of -the `template'-image to the new disk images, either by mounting the -template and the new image, and using \path{cp -a} or \path{tar} or by -simply copying the image file. Once this is done, modify the -image-specific settings (hostname, network settings, etc). +If you need to create new domains, you can copy the contents of the +`template'-image to the new disk images, either by mounting the template +and the new image, and using \path{cp -a} or \path{tar} or by simply +copying the image file. Once this is done, modify the image-specific +settings (hostname, network settings, etc). diff -r 63f9c8dd13d4 -r dceb2fcdab5b docs/src/user/debugging.tex --- a/docs/src/user/debugging.tex Fri Dec 2 21:29:25 2005 +++ b/docs/src/user/debugging.tex Fri Dec 2 21:29:26 2005 @@ -1,7 +1,4 @@ -\chapter{Debugging and Tracing} - -\section{Debugging} -\label{s:keys} +\chapter{Debugging} Xen has a set of debugging features that can be useful to try and figure out what's going on. Hit ``h'' on the serial line (if you specified a baud @@ -19,7 +16,3 @@ %% null modem cable. Documentation is included. Alternatively, if the %% Xen machine is connected to a serial-port server then we supply a %% dumb TCP terminal client, {\tt xencons}. - -\section{Tracing} - -Placeholder. \ No newline at end of file diff -r 63f9c8dd13d4 -r dceb2fcdab5b docs/src/user/domain_filesystem.tex --- a/docs/src/user/domain_filesystem.tex Fri Dec 2 21:29:25 2005 +++ b/docs/src/user/domain_filesystem.tex Fri Dec 2 21:29:26 2005 @@ -1,4 +1,4 @@ -\chapter{Domain Filesystem Storage} +\chapter{Storage and File System Management} It is possible to directly export any Linux block device in dom0 to another domain, or to export filesystems / devices to virtual machines diff -r 63f9c8dd13d4 -r dceb2fcdab5b docs/src/user/domain_mgmt.tex --- a/docs/src/user/domain_mgmt.tex Fri Dec 2 21:29:25 2005 +++ b/docs/src/user/domain_mgmt.tex Fri Dec 2 21:29:26 2005 @@ -1,20 +1,98 @@ \chapter{Domain Management Tools} -The previous chapter described a simple example of how to configure -and start a domain. This chapter summarises the tools available to -manage running domains. +This chapter summarises the tools available to manage running domains. -\section{Command-line Management} +\section{\Xend\ } +\label{s:xend} + +The Xen Daemon (\Xend) (node control daemon) performs system management +functions related to virtual machines. It forms a central point of +control for a machine and can be controlled using an HTTP-based +protocol. \Xend\ must be running in order to start and manage virtual +machines. + +\Xend\ must be run as root because it needs access to privileged system +management functions. A small set of commands may be issued on the +\xend\ command line: + +\begin{tabular}{ll} + \verb!# xend start! & start \xend, if not already running \\ + \verb!# xend stop! & stop \xend\ if already running \\ + \verb!# xend restart! & restart \xend\ if running, otherwise start it \\ + % \verb!# xend trace_start! & start \xend, with very detailed debug logging \\ + \verb!# xend status! & indicates \xend\ status by its return code +\end{tabular} + +A SysV init script called {\tt xend} is provided to start \xend\ at boot +time. {\tt make install} installs this script in \path{/etc/init.d}. To +enable it, you have to make symbolic links in the appropriate runlevel +directories or use the {\tt chkconfig} tool, where available. + +Once \xend\ is running, more sophisticated administration can be done +using the xm tool (see Section~\ref{s:xm}) and the experimental Xensv +web interface (see Section~\ref{s:xensv}). + +As \xend\ runs, events will be logged to \path{/var/log/xend.log} and, +if the migration assistant daemon (\path{xfrd}) has been started, +\path{/var/log/xfrd.log}. These may be of use for troubleshooting +problems. + +\section{Xm} +\label{s:xm} Command line management tasks are also performed using the \path{xm} -tool. For online help for the commands available, type: +tool. For online help for the commands available, type: + \begin{quote} - \verb_# xm help_ +\begin{verbatim} +# xm help +\end{verbatim} \end{quote} -You can also type \path{xm help $<$command$>$} for more information on -a given command. +You can also type \path{xm help $<$command$>$} for more information on a +given command. + +The xm tool is the primary tool for managing Xen from the console. The +general format of an xm command line is: + +\begin{verbatim} +# xm command [switches] [arguments] [variables] +\end{verbatim} + +The available \emph{switches} and \emph{arguments} are dependent on the +\emph{command} chosen. The \emph{variables} may be set using +declarations of the form {\tt variable=value} and command line +declarations override any of the values in the configuration file being +used, including the standard variables described above and any custom +variables (for instance, the \path{xmdefconfig} file uses a {\tt vmid} +variable). + +The available commands are as follows: + +\begin{description} +\item[mem-set] Request a domain to adjust its memory footprint. +\item[create] Create a new domain. +\item[destroy] Kill a domain immediately. +\item[list] List running domains. +\item[shutdown] Ask a domain to shutdown. +\item[dmesg] Fetch the Xen (not Linux!) boot output. +\item[consoles] Lists the available consoles. +\item[console] Connect to the console for a domain. +\item[help] Get help on xm commands. +\item[save] Suspend a domain to disk. +\item[restore] Restore a domain from disk. +\item[pause] Pause a domain's execution. +\item[unpause] Un-pause a domain. +\item[pincpu] Pin a domain to a CPU. +\item[bvt] Set BVT scheduler parameters for a domain. +\item[bvt\_ctxallow] Set the BVT context switching allowance for the + system. +\item[atropos] Set the atropos parameters for a domain. +\item[rrobin] Set the round robin time slice for the system. +\item[info] Get information about the Xen host. +\item[call] Call a \xend\ HTTP API function directly. +\end{description} \subsection{Basic Management Commands} @@ -82,122 +160,6 @@ # xencons localhost 9605 \end{verbatim} -\section{Domain Save and Restore} +\section{xenstored} -The administrator of a Xen system may suspend a virtual machine's -current state into a disk file in domain~0, allowing it to be resumed -at a later time. - -The ttylinux domain described earlier can be suspended to disk using -the command: -\begin{verbatim} -# xm save ttylinux ttylinux.xen -\end{verbatim} - -This will stop the domain named `ttylinux' and save its current state -into a file called \path{ttylinux.xen}. - -To resume execution of this domain, use the \path{xm restore} command: -\begin{verbatim} -# xm restore ttylinux.xen -\end{verbatim} - -This will restore the state of the domain and restart it. The domain -will carry on as before and the console may be reconnected using the -\path{xm console} command, as above. - -\section{Live Migration} - -Live migration is used to transfer a domain between physical hosts -whilst that domain continues to perform its usual activities --- from -the user's perspective, the migration should be imperceptible. - -To perform a live migration, both hosts must be running Xen / \xend\ -and the destination host must have sufficient resources (e.g.\ memory -capacity) to accommodate the domain after the move. Furthermore we -currently require both source and destination machines to be on the -same L2 subnet. - -Currently, there is no support for providing automatic remote access -to filesystems stored on local disk when a domain is migrated. -Administrators should choose an appropriate storage solution (i.e.\ -SAN, NAS, etc.) to ensure that domain filesystems are also available -on their destination node. GNBD is a good method for exporting a -volume from one machine to another. iSCSI can do a similar job, but is -more complex to set up. - -When a domain migrates, it's MAC and IP address move with it, thus it -is only possible to migrate VMs within the same layer-2 network and IP -subnet. If the destination node is on a different subnet, the -administrator would need to manually configure a suitable etherip or -IP tunnel in the domain~0 of the remote node. - -A domain may be migrated using the \path{xm migrate} command. To live -migrate a domain to another machine, we would use the command: - -\begin{verbatim} -# xm migrate --live mydomain destination.ournetwork.com -\end{verbatim} - -Without the \path{--live} flag, \xend\ simply stops the domain and -copies the memory image over to the new node and restarts it. Since -domains can have large allocations this can be quite time consuming, -even on a Gigabit network. With the \path{--live} flag \xend\ attempts -to keep the domain running while the migration is in progress, -resulting in typical `downtimes' of just 60--300ms. - -For now it will be necessary to reconnect to the domain's console on -the new machine using the \path{xm console} command. If a migrated -domain has any open network connections then they will be preserved, -so SSH connections do not have this limitation. - - -\section{Managing Domain Memory} - -XenLinux domains have the ability to relinquish / reclaim machine -memory at the request of the administrator or the user of the domain. - -\subsection{Setting memory footprints from dom0} - -The machine administrator can request that a domain alter its memory -footprint using the \path{xm mem-set} command. For instance, we can -request that our example ttylinux domain reduce its memory footprint -to 32 megabytes. - -\begin{verbatim} -# xm mem-set ttylinux 32 -\end{verbatim} - -We can now see the result of this in the output of \path{xm list}: - -\begin{verbatim} -# xm list -Name Id Mem(MB) CPU State Time(s) Console -Domain-0 0 251 0 r---- 172.2 -ttylinux 5 31 0 -b--- 4.3 9605 -\end{verbatim} - -The domain has responded to the request by returning memory to Xen. We -can restore the domain to its original size using the command line: - -\begin{verbatim} -# xm mem-set ttylinux 64 -\end{verbatim} - -\subsection{Setting memory footprints from within a domain} - -The virtual file \path{/proc/xen/balloon} allows the owner of a domain -to adjust their own memory footprint. Reading the file (e.g.\ -\path{cat /proc/xen/balloon}) prints out the current memory footprint -of the domain. Writing the file (e.g.\ \path{echo new\_target > - /proc/xen/balloon}) requests that the kernel adjust the domain's -memory footprint to a new value. - -\subsection{Setting memory limits} - -Xen associates a memory size limit with each domain. By default, this -is the amount of memory the domain is originally started with, -preventing the domain from ever growing beyond this size. To permit a -domain to grow beyond its original allocation or to prevent a domain -you've shrunk from reclaiming the memory it relinquished, use the -\path{xm maxmem} command. +Placeholder. diff -r 63f9c8dd13d4 -r dceb2fcdab5b docs/src/user/installation.tex --- a/docs/src/user/installation.tex Fri Dec 2 21:29:25 2005 +++ b/docs/src/user/installation.tex Fri Dec 2 21:29:26 2005 @@ -1,40 +1,39 @@ \chapter{Basic Installation} The Xen distribution includes three main components: Xen itself, ports -of Linux and NetBSD to run on Xen, and the userspace -tools required to manage a Xen-based system. This chapter describes -how to install the Xen~3.0 distribution from source. Alternatively, -there may be pre-built packages available as part of your operating -system distribution. +of Linux and NetBSD to run on Xen, and the userspace tools required to +manage a Xen-based system. This chapter describes how to install the +Xen~3.0 distribution from source. Alternatively, there may be pre-built +packages available as part of your operating system distribution. \section{Prerequisites} \label{sec:prerequisites} -The following is a full list of prerequisites. Items marked `$\dag$' -are required by the \xend\ control tools, and hence required if you -want to run more than one virtual machine; items marked `$*$' are only -required if you wish to build from source. +The following is a full list of prerequisites. Items marked `$\dag$' are +required by the \xend\ control tools, and hence required if you want to +run more than one virtual machine; items marked `$*$' are only required +if you wish to build from source. \begin{itemize} -\item A working Linux distribution using the GRUB bootloader and - running on a P6-class or newer CPU\@. +\item A working Linux distribution using the GRUB bootloader and running + on a P6-class or newer CPU\@. \item [$\dag$] The \path{iproute2} package. \item [$\dag$] The Linux bridge-utils\footnote{Available from {\tt http://bridge.sourceforge.net}} (e.g., \path{/sbin/brctl}) \item [$\dag$] The Linux hotplug system\footnote{Available from {\tt - http://linux-hotplug.sourceforge.net/}} (e.g., \path{/sbin/hotplug} - and related scripts) + http://linux-hotplug.sourceforge.net/}} (e.g., + \path{/sbin/hotplug} and related scripts) \item [$*$] Build tools (gcc v3.2.x or v3.3.x, binutils, GNU make). \item [$*$] Development installation of libcurl (e.g.,\ libcurl-devel). \item [$*$] Development installation of zlib (e.g.,\ zlib-dev). -\item [$*$] Development installation of Python v2.2 or later (e.g.,\ +\item [$*$] Development installation of Python v2.2 or later (e.g.,\ python-dev). \item [$*$] \LaTeX\ and transfig are required to build the documentation. \end{itemize} -Once you have satisfied these prerequisites, you can now install -either a binary or source distribution of Xen. +Once you have satisfied these prerequisites, you can now install either +a binary or source distribution of Xen. \section{Installing from Binary Tarball} @@ -51,14 +50,13 @@ # sh ./install.sh \end{verbatim} -Once you've installed the binaries you need to configure your system -as described in Section~\ref{s:configure}. +Once you've installed the binaries you need to configure your system as +described in Section~\ref{s:configure}. \section{Installing from Source} -This section describes how to obtain, build and install Xen from -source. +This section describes how to obtain, build and install Xen from source. \subsection{Obtaining the Source} @@ -106,11 +104,11 @@ \begin{itemize} \item Build Xen. \item Build the control tools, including \xend. -\item Download (if necessary) and unpack the Linux 2.6 source code, - and patch it for use with Xen. -\item Build a Linux kernel to use in domain~0 and a smaller - unprivileged kernel, which can optionally be used for unprivileged - virtual machines. +\item Download (if necessary) and unpack the Linux 2.6 source code, and + patch it for use with Xen. +\item Build a Linux kernel to use in domain~0 and a smaller unprivileged + kernel, which can optionally be used for unprivileged virtual + machines. \end{itemize} After the build has completed you should have a top-level directory @@ -187,24 +185,24 @@ \end{verbatim} \end{quote} -You can also copy an existing Linux configuration (\path{.config}) -into e.g.\ \path{linux-2.6.11-xen0} and execute: +You can also copy an existing Linux configuration (\path{.config}) into +e.g.\ \path{linux-2.6.11-xen0} and execute: \begin{quote} \begin{verbatim} # make ARCH=xen oldconfig \end{verbatim} \end{quote} -You may be prompted with some Xen-specific options. We advise -accepting the defaults for these options. +You may be prompted with some Xen-specific options. We advise accepting +the defaults for these options. Note that the only difference between the two types of Linux kernels -that are built is the configuration file used for each. The ``U'' +that are built is the configuration file used for each. The ``U'' suffixed (unprivileged) versions don't contain any of the physical -hardware device drivers, leading to a 30\% reduction in size; hence -you may prefer these for your non-privileged domains. The ``0'' -suffixed privileged versions can be used to boot the system, as well -as in driver domains and unprivileged domains. +hardware device drivers, leading to a 30\% reduction in size; hence you +may prefer these for your non-privileged domains. The ``0'' suffixed +privileged versions can be used to boot the system, as well as in driver +domains and unprivileged domains. \subsection{Installing Generated Binaries} @@ -217,8 +215,8 @@ \end{verbatim} \end{quote} -Alternatively, users with special installation requirements may wish -to install them manually by copying the files to their appropriate +Alternatively, users with special installation requirements may wish to +install them manually by copying the files to their appropriate destinations. %% Files in \path{install/boot/} include: @@ -233,23 +231,23 @@ The \path{dist/install/boot} directory will also contain the config files used for building the XenLinux kernels, and also versions of Xen and XenLinux kernels that contain debug symbols such as -(\path{xen-syms-2.0.6} and \path{vmlinux-syms-2.6.11.11-xen0}) which -are essential for interpreting crash dumps. Retain these files as the +(\path{xen-syms-2.0.6} and \path{vmlinux-syms-2.6.11.11-xen0}) which are +essential for interpreting crash dumps. Retain these files as the developers may wish to see them if you post on the mailing list. \section{Configuration} \label{s:configure} -Once you have built and installed the Xen distribution, it is simple -to prepare the machine for booting and running Xen. +Once you have built and installed the Xen distribution, it is simple to +prepare the machine for booting and running Xen. \subsection{GRUB Configuration} An entry should be added to \path{grub.conf} (often found under \path{/boot/} or \path{/boot/grub/}) to allow Xen / XenLinux to boot. This file is sometimes called \path{menu.lst}, depending on your -distribution. The entry should look something like the following: +distribution. The entry should look something like the following: {\small \begin{verbatim} @@ -266,11 +264,11 @@ Section~\ref{s:xboot}. The module line of the configuration describes the location of the -XenLinux kernel that Xen should start and the parameters that should -be passed to it. Tthese are standard Linux parameters, identifying the -root device and specifying it be initially mounted read only and -instructing that console output be sent to the screen. Some -distributions such as SuSE do not require the \path{ro} parameter. +XenLinux kernel that Xen should start and the parameters that should be +passed to it. Tthese are standard Linux parameters, identifying the root +device and specifying it be initially mounted read only and instructing +that console output be sent to the screen. Some distributions such as +SuSE do not require the \path{ro} parameter. %% \framebox{\parbox{5in}{ %% {\bf Distro specific:} \\ @@ -278,30 +276,26 @@ %% kernel command line, since the partition won't be remounted rw %% during boot. }} - -If you want to use an initrd, just add another \path{module} line to -the configuration, like: -{\small +If you want to use an initrd, just add another \path{module} line to the +configuration, like: {\small \begin{verbatim} module /boot/my_initrd.gz \end{verbatim} } When installing a new kernel, it is recommended that you do not delete -existing menu options from \path{menu.lst}, as you may wish to boot -your old Linux kernel in future, particularly if you have problems. +existing menu options from \path{menu.lst}, as you may wish to boot your +old Linux kernel in future, particularly if you have problems. \subsection{Serial Console (optional)} %% kernel /boot/xen-2.0.gz dom0_mem=131072 com1=115200,8n1 %% module /boot/vmlinuz-2.6-xen0 root=/dev/sda4 ro -In order to configure Xen serial console output, it is necessary to -add an boot option to your GRUB config; e.g.\ replace the above kernel -line with: -\begin{quote} -{\small -\begin{verbatim} +In order to configure Xen serial console output, it is necessary to add +an boot option to your GRUB config; e.g.\ replace the above kernel line +with: +\begin{quote} {\small \begin{verbatim} kernel /boot/xen.gz dom0_mem=131072 com1=115200,8n1 \end{verbatim}} \end{quote} @@ -309,11 +303,11 @@ This configures Xen to output on COM1 at 115,200 baud, 8 data bits, 1 stop bit and no parity. Modify these parameters for your environment. -One can also configure XenLinux to share the serial console; to -achieve this append ``\path{console=ttyS0}'' to your module line. - -If you wish to be able to log in over the XenLinux serial console it -is necessary to add a line into \path{/etc/inittab}. Add the line: +One can also configure XenLinux to share the serial console; to achieve +this append ``\path{console=ttyS0}'' to your module line. + +If you wish to be able to log in over the XenLinux serial console it is +necessary to add a line into \path{/etc/inittab}. Add the line: \begin{quote} {\small {\tt c:2345:respawn:/sbin/mingetty ttyS0}} \end{quote} diff -r 63f9c8dd13d4 -r dceb2fcdab5b docs/src/user/introduction.tex --- a/docs/src/user/introduction.tex Fri Dec 2 21:29:25 2005 +++ b/docs/src/user/introduction.tex Fri Dec 2 21:29:26 2005 @@ -1,45 +1,43 @@ \chapter{Introduction} -Xen is a \emph{paravirtualizing} virtual machine monitor (VMM), or -``hypervisor'', for the x86 processor architecture. Xen can securely +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: +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 Live migration of running virtual machines between physical hosts. \item Excellent hardware support. Supports most Linux device drivers. -\item Sandboxed, re-startable device drivers. +\item Sand-boxed, re-startable device drivers. \end{itemize} -Paravirtualisation permits very high performance virtualisation, even +Para-virtualization permits very high performance virtualization, even on architectures like x86 that are traditionally very hard to -virtualise. +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 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. +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. -Xen support is available for increasingly many operating systems: -right now, 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). +Xen support is available for increasingly many operating systems: right +now, 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). 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. + 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 @@ -50,7 +48,7 @@ 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 benefitting from the wide-ranging hardware support of + OSes while benefiting from the wide-ranging hardware support of existing OSes such as Linux. \end{description} @@ -62,10 +60,10 @@ 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. +\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 @@ -73,39 +71,38 @@ 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. +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 +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. +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 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. +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} @@ -119,20 +116,20 @@ 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: +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 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 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 + 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. diff -r 63f9c8dd13d4 -r dceb2fcdab5b docs/src/user/booting_xen.tex --- /dev/null Fri Dec 2 21:29:25 2005 +++ b/docs/src/user/booting_xen.tex Fri Dec 2 21:29:26 2005 @@ -0,0 +1,3 @@ +\chapter{Booting Xen} + +Placeholder. diff -r 63f9c8dd13d4 -r dceb2fcdab5b docs/src/user/building_xen.tex --- /dev/null Fri Dec 2 21:29:25 2005 +++ b/docs/src/user/building_xen.tex Fri Dec 2 21:29:26 2005 @@ -0,0 +1,3 @@ +\chapter{Building Xen} + +Placeholder. diff -r 63f9c8dd13d4 -r dceb2fcdab5b docs/src/user/console_management.tex --- /dev/null Fri Dec 2 21:29:25 2005 +++ b/docs/src/user/console_management.tex Fri Dec 2 21:29:26 2005 @@ -0,0 +1,3 @@ +\chapter{Console Management} + +Placeholder. diff -r 63f9c8dd13d4 -r dceb2fcdab5b docs/src/user/cpu_management.tex --- /dev/null Fri Dec 2 21:29:25 2005 +++ b/docs/src/user/cpu_management.tex Fri Dec 2 21:29:26 2005 @@ -0,0 +1,3 @@ +\chapter{CPU Management} + +Placeholder. diff -r 63f9c8dd13d4 -r dceb2fcdab5b docs/src/user/dom0_installation.tex --- /dev/null Fri Dec 2 21:29:25 2005 +++ b/docs/src/user/dom0_installation.tex Fri Dec 2 21:29:26 2005 @@ -0,0 +1,3 @@ +\chapter{dom0 Installation} + +Placeholder. diff -r 63f9c8dd13d4 -r dceb2fcdab5b docs/src/user/domU_installation.tex --- /dev/null Fri Dec 2 21:29:25 2005 +++ b/docs/src/user/domU_installation.tex Fri Dec 2 21:29:26 2005 @@ -0,0 +1,3 @@ +\chapter{domU Installation} + +Placeholder. diff -r 63f9c8dd13d4 -r dceb2fcdab5b docs/src/user/logfiles.tex --- /dev/null Fri Dec 2 21:29:25 2005 +++ b/docs/src/user/logfiles.tex Fri Dec 2 21:29:26 2005 @@ -0,0 +1,3 @@ +\chapter{Log Files} + +Placeholder. diff -r 63f9c8dd13d4 -r dceb2fcdab5b docs/src/user/memory_management.tex --- /dev/null Fri Dec 2 21:29:25 2005 +++ b/docs/src/user/memory_management.tex Fri Dec 2 21:29:26 2005 @@ -0,0 +1,51 @@ +\chapter{Memory Management} + +\section{Managing Domain Memory} + +XenLinux domains have the ability to relinquish / reclaim machine +memory at the request of the administrator or the user of the domain. + +\subsection{Setting memory footprints from dom0} + +The machine administrator can request that a domain alter its memory +footprint using the \path{xm mem-set} command. For instance, we can +request that our example ttylinux domain reduce its memory footprint +to 32 megabytes. + +\begin{verbatim} +# xm mem-set ttylinux 32 +\end{verbatim} + +We can now see the result of this in the output of \path{xm list}: + +\begin{verbatim} +# xm list +Name Id Mem(MB) CPU State Time(s) Console +Domain-0 0 251 0 r---- 172.2 +ttylinux 5 31 0 -b--- 4.3 9605 +\end{verbatim} + +The domain has responded to the request by returning memory to Xen. We +can restore the domain to its original size using the command line: + +\begin{verbatim} +# xm mem-set ttylinux 64 +\end{verbatim} + +\subsection{Setting memory footprints from within a domain} + +The virtual file \path{/proc/xen/balloon} allows the owner of a domain +to adjust their own memory footprint. Reading the file (e.g.\ +\path{cat /proc/xen/balloon}) prints out the current memory footprint +of the domain. Writing the file (e.g.\ \path{echo new\_target > + /proc/xen/balloon}) requests that the kernel adjust the domain's +memory footprint to a new value. + +\subsection{Setting memory limits} + +Xen associates a memory size limit with each domain. By default, this +is the amount of memory the domain is originally started with, +preventing the domain from ever growing beyond this size. To permit a +domain to grow beyond its original allocation or to prevent a domain +you've shrunk from reclaiming the memory it relinquished, use the +\path{xm maxmem} command. diff -r 63f9c8dd13d4 -r dceb2fcdab5b docs/src/user/migrating_domains.tex --- /dev/null Fri Dec 2 21:29:25 2005 +++ b/docs/src/user/migrating_domains.tex Fri Dec 2 21:29:26 2005 @@ -0,0 +1,70 @@ +\chapter{Migrating Domains} + +\section{Domain Save and Restore} + +The administrator of a Xen system may suspend a virtual machine's +current state into a disk file in domain~0, allowing it to be resumed at +a later time. + +The ttylinux domain described earlier can be suspended to disk using the +command: +\begin{verbatim} +# xm save ttylinux ttylinux.xen +\end{verbatim} + +This will stop the domain named ``ttylinux'' and save its current state +into a file called \path{ttylinux.xen}. + +To resume execution of this domain, use the \path{xm restore} command: +\begin{verbatim} +# xm restore ttylinux.xen +\end{verbatim} + +This will restore the state of the domain and restart it. The domain +will carry on as before and the console may be reconnected using the +\path{xm console} command, as above. + +\section{Live Migration} + +Live migration is used to transfer a domain between physical hosts +whilst that domain continues to perform its usual activities --- from +the user's perspective, the migration should be imperceptible. + +To perform a live migration, both hosts must be running Xen / \xend\ and +the destination host must have sufficient resources (e.g.\ memory +capacity) to accommodate the domain after the move. Furthermore we +currently require both source and destination machines to be on the same +L2 subnet. + +Currently, there is no support for providing automatic remote access to +filesystems stored on local disk when a domain is migrated. +Administrators should choose an appropriate storage solution (i.e.\ SAN, +NAS, etc.) to ensure that domain filesystems are also available on their +destination node. GNBD is a good method for exporting a volume from one +machine to another. iSCSI can do a similar job, but is more complex to +set up. + +When a domain migrates, it's MAC and IP address move with it, thus it is +only possible to migrate VMs within the same layer-2 network and IP +subnet. If the destination node is on a different subnet, the +administrator would need to manually configure a suitable etherip or IP +tunnel in the domain~0 of the remote node. + +A domain may be migrated using the \path{xm migrate} command. To live +migrate a domain to another machine, we would use the command: + +\begin{verbatim} +# xm migrate --live mydomain destination.ournetwork.com +\end{verbatim} + +Without the \path{--live} flag, \xend\ simply stops the domain and +copies the memory image over to the new node and restarts it. Since +domains can have large allocations this can be quite time consuming, +even on a Gigabit network. With the \path{--live} flag \xend\ attempts +to keep the domain running while the migration is in progress, resulting +in typical `downtimes' of just 60--300ms. + +For now it will be necessary to reconnect to the domain's console on the +new machine using the \path{xm console} command. If a migrated domain +has any open network connections then they will be preserved, so SSH +connections do not have this limitation. diff -r 63f9c8dd13d4 -r dceb2fcdab5b docs/src/user/network_management.tex --- /dev/null Fri Dec 2 21:29:25 2005 +++ b/docs/src/user/network_management.tex Fri Dec 2 21:29:26 2005 @@ -0,0 +1,3 @@ +\chapter{Network Management} + +Placeholder. diff -r 63f9c8dd13d4 -r dceb2fcdab5b docs/src/user/scheduler_management.tex --- /dev/null Fri Dec 2 21:29:25 2005 +++ b/docs/src/user/scheduler_management.tex Fri Dec 2 21:29:26 2005 @@ -0,0 +1,3 @@ +\chapter{Scheduler Management} + +Placeholder. diff -r 63f9c8dd13d4 -r dceb2fcdab5b docs/src/user/xenstat.tex --- /dev/null Fri Dec 2 21:29:25 2005 +++ b/docs/src/user/xenstat.tex Fri Dec 2 21:29:26 2005 @@ -0,0 +1,3 @@ +\chapter{xenstat} + +Placeholder. diff -r 63f9c8dd13d4 -r dceb2fcdab5b docs/src/user/xentrace.tex --- /dev/null Fri Dec 2 21:29:25 2005 +++ b/docs/src/user/xentrace.tex Fri Dec 2 21:29:26 2005 @@ -0,0 +1,3 @@ +\chapter{xentrace} + +Placeholder. _______________________________________________ Xen-changelog mailing list Xen-changelog@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-changelog
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |