# 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
|
Home