bitkeeper revision 1.1159.1.317 (41858a05X_g4Uut3LMGwGYbviy2MVg)

Merge ssh://srg//auto/groups/xeno/BK/xeno.bk
into pug.(none):/home/irchomes/mwilli2/xeno-docs.bk

BitKeeper/etc/logging_ok

@@ -38,6 +38,7 @@ mjw@wray-m-3.hpl.hp.com
 mwilli2@anvil.research
 mwilli2@equilibrium.research
 mwilli2@equilibrium.research.intel-research.net
+mwilli2@pug.(none)
 rac61@labyrinth.cl.cam.ac.uk
 rgr22@boulderdash.cl.cam.ac.uk
 rn@wyvis.camb.intel-research.net

docs/src/user.tex

@@ -694,6 +694,117 @@ or:
 # xm console 5
 \end{verbatim}
 
+\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 {\tt 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
+{\tt 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.
+
+A domain may be migrated using the {\tt xm migrate } command.  To
+migrate the example ttylinux domain to another machine, we would use
+the command:
+
+\begin{verbatim}
+# xm migrate --live ttylinux destination.ournetwork.com
+\end{verbatim}
+
+There will be a delay whilst the domain is moved to the destination
+machine.  During this time, the Xen migration daemon copies as much
+information as possible about the domain (configuration, memory
+contents, etc.) to the destination host as possible.  The domain is
+then stopped for a fraction of a second in order to update the state
+on the destination machine with any changes in memory contents, etc.
+The domain will then continue on the new machine having been halted
+for a fraction of a second (usually between about 60 -- 300ms).
+
+For now it will be necessary to reconnect to the domain's console on
+the new machine using the {\tt 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.
+
+Currently, there is no support for providing access to disk
+filesystems 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.
+
+\section{Managing domain memory (ballooning and memory limits)}
+
+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 administator can request that a domain alter its memory
+footprint using the {\tt xm balloon} command.  For instance, we can
+request that our example ttylinux domain reduce its memory footprint
+to 32 megabytes.
+
+\begin{verbatim}
+# xm balloon ttylinux 32
+\end{verbatim}
+
+We can now see the result of this in the output of {\tt 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 balloon ttylinux 64
+\end{verbatim}
+
+\subsection{Setting memory footprints from within a domain}
+
+The virtual file \path{/proc/xen/memory\_target} allows the owner of a
+domain to adjust their own memory footprint.  Reading the file
+(e.g. \verb!# cat /proc/xen/memory\_target!) prints out the current
+memory footprint of the domain.  Writing the file
+(e.g. \verb!# echo new\_target > /proc/xen/memory\_target!) 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 reliquished, use the {\tt
+xm maxmem} command.
+
 \chapter{Domain filesystem storage}
 
 It is possible to directly export any Linux block device to a virtual,

tools/python/xen/sv/CreateDomain.py

@@ -32,7 +32,7 @@ class CreatePage1( Sheet ):
     def __init__( self, urlWriter ):
         Sheet.__init__( self, urlWriter, "Setup Kernel Image", 1 )
         self.addControl( ListControl( 'builder', [('linux', 'Linux'), ('netbsd', 'NetBSD')], 'Kernel Type:' ) )
-        self.addControl( FileControl( 'kernel', '/boot/vmlinuz-2.4.26-xenU', 'Kernel Image:' ) )
+        self.addControl( FileControl( 'kernel', '/boot/vmlinuz-2.6.9-xenU', 'Kernel Image:' ) )
         self.addControl( InputControl( 'extra', '', 'Kernel Command Line Parameters:' ) )
 
 class CreatePage2( Sheet ):