# HG changeset patch
# User kmself@xxxxxxxxxxxxx
# Node ID bc7567741a4c44b1d6b18b1deca3ce1a7e5721fd
# Parent 1deae55b1f5c2ccd656268c3fe6ada1fe0fc2c8c
Incorporating Alan Oehler's changes, some of mine.
diff -r 1deae55b1f5c -r bc7567741a4c docs/src/user/booting_xen.tex
--- a/docs/src/user/booting_xen.tex Sat Dec 3 00:13:55 2005
+++ b/docs/src/user/booting_xen.tex Sat Dec 3 02:59:53 2005
@@ -1,3 +1,170 @@
\chapter{Booting Xen}
-Placeholder.
+Once Xen is installed and configured as described in the preceding chapter, it
+should now be possible to restart the system and use Xen.
+
+Booting the system into Xen will bring you up into the privileged management d
+omain, Domain0. At that point you are ready to create guest domains and "boot"
t
+hem using the xm create command.
+
+\section{Booting Domain0}
+
+After installation and configuration is complete, reboot the system and and ch
+oose the new Xen option when the Grub screen appears.
+
+What follows should look much like a conventional Linux boot. The
+first portion of the output comes from Xen itself, supplying low level
+information about itself and the underlying hardware. The last
+portion of the output comes from XenLinux.
+
+You may see some errors during the XenLinux boot. These are not
+necessarily anything to worry about --- they may result from kernel
+configuration differences between your XenLinux kernel and the one you
+usually use.
+
+%% KMSelf Wed Nov 30 18:09:37 PST 2005: We should specify what these are.
+
+When the boot completes, you should be able to log into your system as
+usual. If you are unable to log in, you should still be able to
+reboot with your normal Linux kernel by selecting it at the GRUB prompt.
+
+The first step in creating a new domain is to prepare a root
+filesystem for it to boot. Typically, this might be stored in a normal
+partition, an LVM or other volume manager partition, a disk file or on
+an NFS server. A simple way to do this is simply to boot from your
+standard OS install CD and install the distribution into another
+partition on your hard drive.
+
+To start the \xend\ control daemon, type
+\begin{quote}
+ \verb!# xend start!
+\end{quote}
+
+If you wish the daemon to start automatically, see the instructions in
+Section~\ref{s:xend}. Once the daemon is running, you can use the
+\path{xm} tool to monitor and maintain the domains running on your
+system. This chapter provides only a brief tutorial. We provide full
+details of the \path{xm} tool in the next chapter.
+
+% \section{From the web interface}
+%
+% Boot the Xen machine and start Xensv (see Chapter~\ref{cha:xensv}
+% for more details) using the command: \\
+% \verb_# xensv start_ \\
+% This will also start Xend (see Chapter~\ref{cha:xend} for more
+% information).
+%
+% The domain management interface will then be available at {\tt
+% http://your\_machine:8080/}. This provides a user friendly wizard
+% for starting domains and functions for managing running domains.
+%
+% \section{From the command line}
+\section{Booting Guest Domains}
+
+\subsection{Creating a Domain Configuration File}
+
+Before you can start an additional domain, you must create a
+configuration file. We provide two example files which you can use as
+a starting point:
+\begin{itemize}
+\item \path{/etc/xen/xmexample1} is a simple template configuration
+ file for describing a single VM\@.
+\item \path{/etc/xen/xmexample2} file is a template description that
+ is intended to be reused for multiple virtual machines. Setting the
+ value of the \path{vmid} variable on the \path{xm} command line
+ fills in parts of this template.
+\end{itemize}
+
+Copy one of these files and edit it as appropriate. Typical values
+you may wish to edit include:
+
+\begin{quote}
+\begin{description}
+\item[kernel] Set this to the path of the kernel you compiled for use
+ with Xen (e.g.\ \path{kernel = ``/boot/vmlinuz-2.6-xenU''})
+\item[memory] Set this to the size of the domain's memory in megabytes
+ (e.g.\ \path{memory = 64})
+\item[disk] Set the first entry in this list to calculate the offset
+ of the domain's root partition, based on the domain ID\@. Set the
+ second to the location of \path{/usr} if you are sharing it between
+ domains (e.g.\ \path{disk = ['phy:your\_hard\_drive\%d,sda1,w' \%
+ (base\_partition\_number + vmid),
+ 'phy:your\_usr\_partition,sda6,r' ]}
+\item[dhcp] Uncomment the dhcp variable, so that the domain will
+ receive its IP address from a DHCP server (e.g.\ \path{dhcp=``dhcp''})
+\end{description}
+\end{quote}
+
+You may also want to edit the {\bf vif} variable in order to choose
+the MAC address of the virtual ethernet interface yourself. For
+example:
+
+\begin{quote}
+\verb_vif = ['mac=00:16:3E:F6:BB:B3']_
+\end{quote}
+If you do not set this variable, \xend\ will automatically generate a
+random MAC address from the range 00:16:3E:xx:xx:xx, assigned by IEEE to
+XenSource as an OUI (organizationally unique identifier). XenSource
+Inc. gives permission for anyone to use addresses randomly allocated
+from this range for use by their Xen domains.
+
+For a list of IEEE OUI assignments, see \newline
+{\tt http://standards.ieee.org/regauth/oui/oui.txt}.
+
+
+\subsection{Booting the Guest Domain}
+
+The \path{xm} tool provides a variety of commands for managing
+domains. Use the \path{create} command to start new domains. Assuming
+you've created a configuration file \path{myvmconf} based around
+\path{/etc/xen/xmexample2}, to start a domain with virtual machine
+ID~1 you should type:
+
+\begin{quote}
+\begin{verbatim}
+# xm create -c myvmconf vmid=1
+\end{verbatim}
+\end{quote}
+
+The \path{-c} switch causes \path{xm} to turn into the domain's
+console after creation. The \path{vmid=1} sets the \path{vmid}
+variable used in the \path{myvmconf} file.
+
+You should see the console boot messages from the new domain appearing
+in the terminal in which you typed the command, culminating in a login
+prompt.
+
+\subsection{Example: ttylinux}
+
+Ttylinux is a very small Linux distribution, designed to require very
+few resources. We will use it as a concrete example of how to start a
+Xen domain. Most users will probably want to install a full-featured
+distribution once they have mastered the basics\footnote{ttylinux is
+ the distribution's home page: {\tt
+ http://www.minimalinux.org/ttylinux/}}.
+
+\begin{enumerate}
+\item Download and extract the ttylinux disk image from the Files
+ section of the project's SourceForge site (see
+ \path{http://sf.net/projects/xen/}).
+\item Create a configuration file like the following:
+ \begin{quote}
+\begin{verbatim}
+kernel = "/boot/vmlinuz-2.6-xenU"
+memory = 64
+name = "ttylinux"
+nics = 1
+ip = "1.2.3.4"
+disk = ['file:/path/to/ttylinux/rootfs,sda1,w']
+root = "/dev/sda1 ro"
+\end{verbatim}
+ \end{quote}
+\item Now start the domain and connect to its console:
+ \begin{quote}
+\begin{verbatim}
+xm create configfile -c
+\end{verbatim}
+ \end{quote}
+\item Login as root, password root.
+\end{enumerate}
+
diff -r 1deae55b1f5c -r bc7567741a4c docs/src/user/cpu_management.tex
--- a/docs/src/user/cpu_management.tex Sat Dec 3 00:13:55 2005
+++ b/docs/src/user/cpu_management.tex Sat Dec 3 02:59:53 2005
@@ -1,3 +1,44 @@
\chapter{CPU Management}
Placeholder.
+%% KMS Something sage about CPU / processor management.
+
+Xen allows a domain's virtual CPU(s) to be associated with one or more
+host CPUs. This can be used to allocate real resources among one or
+more guests, or to make optimal use of processor resources when
+utilizing dual-core, hyperthreading, or other advanced CPU technologies.
+
+Xen enumerates physical CPUs in a `depth first' fashion. For a system
+with both hyperthreading and multiple cores, this would be all the
+hyperthreads on a given core, then all the cores on a given socket,
+and then all sockets. I.e. if you had a two socket, dual core,
+hyperthreaded Xeon the CPU order would be:
+
+
+\begin{center}
+\begin{tabular}{|l|l|l|l|l|l|l|r|}
+\multicolumn{4}{c|}{socket0} & \multicolumn{4}{c|}{socket1} \\ \hline
+\multicolumn{2}{c|}{core0} & \multicolumn{2}{c|}{core1} &
+\multicolumn{2}{c|}{core0} & \multicolumn{2}{c|}{core1} \\ \hline
+ht0 & ht1 & ht0 & ht1 & ht0 & ht1 & ht0 & ht1 \\
+\#0 & \#1 & \#2 & \#3 & \#4 & \#5 & \#6 & \#7 \\
+\end{tabular}
+\end{center}
+
+
+Having multiple vcpus belonging to the same domain mapped to the same
+physical CPU is very likely to lead to poor performance. It's better to
+use `vcpus-set' to hot-unplug one of the vcpus and ensure the others are
+pinned on different CPUs.
+
+If you are running IO intensive tasks, its typically better to dedicate
+either a hyperthread or whole core to running domain 0, and hence pin
+other domains so that they can't use CPU 0. If your workload is mostly
+compute intensive, you may want to pin vcpus such that all physical CPU
+threads are available for guest domains.
+
+
+\section{Setting CPU Pinning}
+
+FIXME: To specify a domain's CPU pinning use the XXX command/syntax in
+XXX.
diff -r 1deae55b1f5c -r bc7567741a4c docs/src/user/domain_filesystem.tex
--- a/docs/src/user/domain_filesystem.tex Sat Dec 3 00:13:55 2005
+++ b/docs/src/user/domain_filesystem.tex Sat Dec 3 02:59:53 2005
@@ -1,9 +1,17 @@
\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
-using standard network protocols (e.g.\ NBD, iSCSI, NFS, etc.). This
-chapter covers some of the possibilities.
+Storage can be made available to virtual machines in a number of
+different ways. This chapter covers some possible configurations.
+
+The most straightforward method is to export a physical block device (a
+hard drive or partition) from dom0 directly to the guest domain as a
+virtual block device (VBD).
+
+Storage may also be exported from a filesystem image or a partitioned
+filesystem image as a \emph{file-backed VBD}.
+
+Finally, standard network storage protocols such as NBD, iSCSI, NFS,
+etc., can be used to provide storage to virtual machines.
\section{Exporting Physical Devices as VBDs}
diff -r 1deae55b1f5c -r bc7567741a4c docs/src/user/glossary.tex
--- a/docs/src/user/glossary.tex Sat Dec 3 00:13:55 2005
+++ b/docs/src/user/glossary.tex Sat Dec 3 02:59:53 2005
@@ -57,14 +57,19 @@
\item[Shadow pagetables] A technique for hiding the layout of machine
memory from a virtual machine's operating system. Used in some {\bf
- VMMs} to provide the illusion of contiguous physical memory, in
+ VMMs} to provide the illusion of contiguous physical memory, in
Xen this is used during {\bf live migration}.
+
+\item[Virtual Block Device] Persistant storage available to a virtual
+ machine, providing the abstraction of an actual block storage device.
+ {\bf VBD}s may be actual block devices, filesystem images, or
+ remote/network storage.
\item[Virtual Machine] The environment in which a hosted operating
system runs, providing the abstraction of a dedicated machine. A
virtual machine may be identical to the underlying hardware (as in
{\bf full virtualisation}, or it may differ, as in {\bf
- paravirtualisation}).
+ paravirtualisation}).
\item[VMM] Virtual Machine Monitor - the software that allows multiple
virtual machines to be multiplexed on a single physical machine.
diff -r 1deae55b1f5c -r bc7567741a4c docs/src/user/installation.tex
--- a/docs/src/user/installation.tex Sat Dec 3 00:13:55 2005
+++ b/docs/src/user/installation.tex Sat Dec 3 02:59:53 2005
@@ -35,10 +35,9 @@
Once you have satisfied these prerequisites, you can now install either
a binary or source distribution of Xen.
-
\section{Installing from Binary Tarball}
-Pre-built tarballs are available for download from the Xen download
+Pre-built tarballs are available for download from the XenSource downloads
page:
\begin{quote} {\tt http://www.xensource.com/downloads/}
\end{quote}
@@ -53,7 +52,22 @@
Once you've installed the binaries you need to configure your system as
described in Section~\ref{s:configure}.
-
+\section{Installing from RPMs}
+Pre-built RPMs are available for download from the XenSource downloads
+page:
+\begin{quote} {\tt http://www.xensource.com/downloads/}
+\end{quote}
+
+Once you've downloaded the RPMs, you typically install them via the RPM
commands:
+\begin{verbatim}
+# rpm -ivh \emph{rpmname}
+\end{verbatim}
+
+See the instructions and the Release Notes for each RPM set referenced at:
+ \begin{quote}
+ {\tt http://www.xensource.com/downloads/}.
+ \end{quote}
+
\section{Installing from Source}
This section describes how to obtain, build and install Xen from source.
@@ -88,9 +102,9 @@
% \item[\path{tools/}] Xen node controller daemon (Xend), command line
% tools, control libraries
% \item[\path{xen/}] The Xen VMM.
+% \item[\path{buildconfigs/}] Build configuration files
% \item[\path{linux-*-xen-sparse/}] Xen support for Linux.
-% \item[\path{linux-*-patches/}] Experimental patches for Linux.
-% \item[\path{netbsd-*-xen-sparse/}] Xen support for NetBSD.
+% \item[\path{patches/}] Experimental patches for Linux.
% \item[\path{docs/}] Various documentation files for users and
% developers.
% \item[\path{extras/}] Bonus extras.
@@ -221,7 +235,7 @@
%% Files in \path{install/boot/} include:
%% \begin{itemize}
-%% \item \path{install/boot/xen-2.0.gz} Link to the Xen 'kernel'
+%% \item \path{install/boot/xen-3.0.gz} Link to the Xen 'kernel'
%% \item \path{install/boot/vmlinuz-2.6-xen0} Link to domain 0
%% XenLinux kernel
%% \item \path{install/boot/vmlinuz-2.6-xenU} Link to unprivileged
@@ -249,10 +263,12 @@
This file is sometimes called \path{menu.lst}, depending on your
distribution. The entry should look something like the following:
+%% KMSelf Thu Dec 1 19:06:13 PST 2005 262144 is useful for RHEL/RH and
+%% related Dom0s.
{\small
\begin{verbatim}
title Xen 3.0 / XenLinux 2.6
- kernel /boot/xen-3.0.gz dom0_mem=131072
+ kernel /boot/xen-3.0.gz dom0_mem=262144
module /boot/vmlinuz-2.6-xen0 root=/dev/sda4 ro console=tty0
\end{verbatim}
}
@@ -265,7 +281,7 @@
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
+passed to it. These 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.
@@ -276,18 +292,81 @@
%% 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
+To use an initrd, add another \path{module} line to the configuration,
+like: {\small
\begin{verbatim}
module /boot/my_initrd.gz
\end{verbatim}
}
+
+%% KMSelf Thu Dec 1 19:05:30 PST 2005 Other configs as an appendix?
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.
\subsection{Serial Console (optional)}
+
+Serial console access allows you to manage, monitor, and interact with
+your system over a serial console. This can allow access from another
+nearby system via a null-modem ("LapLink") cable, remotely via a serial
+concentrator, or for debugging an emulator such as Qemu.
+
+You system's BIOS, bootloader (GRUB), Xen, Linux, and login access must
+each be individually configured for serial console access. It is
+\emph{not} strictly necessary to have each component fully functional,
+but it can be quite useful.
+
+For general information on serial console configuration under Linux,
+refer to the ``Remote Serial Console HOWTO'' at The Linux Documentation
+Project: {\tt http://www.tldp.org}.
+
+\subsubsection{Serial Console BIOS configuration}
+
+Enabling system serial console output neither enables nor disables
+serial capabilities in GRUB, Xen, or Linux, but may make remote
+management of your system more convenient by displaying POST and other
+boot messages over serial port and allowing remote BIOS configuration.
+
+Refer to your hardware vendor's documentation for capabilities and
+procedures to enable BIOS serial redirection.
+
+
+\subsubsection{Serial Console GRUB configuration}
+
+Placeholder
+
+Enabling GRUB serial console output neither enables nor disables Xen or
+Linux serial capabilities, but may made remote management of your system
+more convenient by displaying GRUB prompts, menus, and actions over
+serial port and allowing remote GRUB management.
+
+Adding the following two lines to your GRUB configuration file,
+typically \path{/boot/grub/menu.lst} or \path{/boot/grub/grub.conf}
+depending on your distro, will enable GRUB serial output.
+
+\begin{quote} {\small \begin{verbatim}
+ serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1
+ terminal --timeout=10 serial console
+\end{verbatim}}
+\end{quote}
+
+Note that when both the serial port and the local monitor and keyboard
+are enabled, the text "Press any key to continue." will appear at both.
+Pressing a key on one device will cause GRUB to display to that device.
+The other device will see no output. If no key is pressed before the
+timeout period expires, the system will boot to the default GRUB boot
+entry.
+
+Please refer to the GRUB info documentation for further information.
+
+
+\subsubsection{Serial Console Xen configuration}
+
+Enabling Xen serial console output neither enables nor disables Linux
+kernel output or logging in to Linux over serial port. It does however
+allow you to monitor and log the Xen boot process via serial console and
+can be very useful in debugging.
%% kernel /boot/xen-2.0.gz dom0_mem=131072 com1=115200,8n1
%% module /boot/vmlinuz-2.6-xen0 root=/dev/sda4 ro
@@ -306,14 +385,44 @@
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}
-
-and you should be able to log in. To successfully log in as root over
-the serial line will require adding \path{ttyS0} to
-\path{/etc/securetty} if it is not already there.
+
+\subsubsection{Serial Console Linux configuration}
+
+Enabling Linux serial console output at boot neither enables nor
+disables logging in to Linux over serial port. It does however allow
+you to monitor and log the Linux boot process via serial console and can be
+very useful in debugging.
+
+To enable Linux output at boot time, add the parameter
+\path{console=ttyS0} (or ttyS1, ttyS2, etc.) to your kernel GRUB line.
+Under Xen, this might be:
+\begin{quote} {\small \begin{verbatim}
+ module /vmlinuz-2.6-xen0 ro root=/dev/VolGroup00/LogVol00 console=ttyS0,
115200
+\end{verbatim}}
+\end{quote}
+to enable output over ttyS0 at 115200 baud.
+
+
+
+\subsubsection{Serial Console Login configuration}
+
+Logging in to Linux via serial console, under Xen or otherwise, requires
+specifying a login prompt be started on the serial port. To permit root
+logins over serial console, the serial port must be added to
+\path{/etc/securetty}.
+
+To automatically start a login prompt over serial port,
+Add the line: \begin{quote} {\small {\tt c:2345:respawn:/sbin/mingetty
+ttyS0}} \end{quote} to \path{/etc/inittab}. Run \path{init q} to force
+a reload of your inttab and start getty.
+
+To enable root logins, add \path{ttyS0} to \path{/etc/securetty} if not
+already present.
+
+Your distribution may use an alternate getty, options include getty,
+mgetty, agetty, and others. Consult your distribution's documentation
+for further information.
+
\subsection{TLS Libraries}
@@ -353,4 +462,4 @@
When the boot completes, you should be able to log into your system as
usual. If you are unable to log in, you should still be able to reboot
-with your normal Linux kernel.
+with your normal Linux kernel by selecting it at the GRUB prompt.
diff -r 1deae55b1f5c -r bc7567741a4c docs/src/user/introduction.tex
--- a/docs/src/user/introduction.tex Sat Dec 3 00:13:55 2005
+++ b/docs/src/user/introduction.tex Sat Dec 3 02:59:53 2005
@@ -8,7 +8,7 @@
enterprise-grade functionality, including:
\begin{itemize}
-\item Virtual machines with performance close to native hardware.
+\item Virtual machines with performance typically 94-98\% of native hardware.
\item Live migration of running virtual machines between physical hosts.
\item Excellent hardware support. Supports most Linux device drivers.
\item Sand-boxed, re-startable device drivers.
@@ -26,12 +26,25 @@
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
+With hardware CPU virtualization as provided by Intel VT and AMD
+Pacifica technology, the ability to run an unmodified guest OS kernel is
+available. No porting of the OS is required; however some additional
+driver support is necessary within Xen itself. Unlike traditional full
+virtualization hypervisors, which suffer a tremendous performance
+overhead, the combination of Xen and VT or Xen and Pacifica technology
+complement one another to offer superb performance for para-virtualized
+guest operating systems and full support for unmodified guests, which
+run natively on the processor without need for emulation, under VT.
+Full support for VT and Pacifica chipsets will appear in early 2006.
+
+Xen support is available for increasingly many operating systems:
+currently, Linux and NetBSD are available for Xen 3.0. A FreeBSD port is
undergoing testing and will be incorporated into the release soon. Other
OS ports, including Plan 9, are in progress. We hope that that arch-xen
patches will be incorporated into the mainstream releases of these
operating systems in due course (as has already happened for NetBSD).
+
+%% KMSelf Thu Dec 1 14:59:02 PST 2005 PPC port status?
Possible usage scenarios for Xen include:
diff -r 1deae55b1f5c -r bc7567741a4c docs/src/user/memory_management.tex
--- a/docs/src/user/memory_management.tex Sat Dec 3 00:13:55 2005
+++ b/docs/src/user/memory_management.tex Sat Dec 3 02:59:53 2005
@@ -2,7 +2,7 @@
\section{Managing Domain Memory}
-XenLinux domains have the ability to relinquish / reclaim machine
+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}
_______________________________________________
Xen-changelog mailing list
Xen-changelog@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-changelog
|
Home