1.1 --- a/BitKeeper/etc/logging_ok	Sun Oct 31 17:37:47 2004 +0000
     1.2 +++ b/BitKeeper/etc/logging_ok	Mon Nov 01 00:57:16 2004 +0000
     1.3 @@ -36,6 +36,7 @@ maw48@labyrinth.cl.cam.ac.uk
     1.4  mjw@wray-m-3.hpl.hp.com
     1.5  mwilli2@equilibrium.research
     1.6  mwilli2@equilibrium.research.intel-research.net
     1.7 +mwilli2@pug.(none)
     1.8  rac61@labyrinth.cl.cam.ac.uk
     1.9  rgr22@boulderdash.cl.cam.ac.uk
    1.10  rn@wyvis.camb.intel-research.net

     2.1 --- a/docs/src/user.tex	Sun Oct 31 17:37:47 2004 +0000
     2.2 +++ b/docs/src/user.tex	Mon Nov 01 00:57:16 2004 +0000
     2.3 @@ -694,6 +694,117 @@ or:
     2.4  # xm console 5
     2.5  \end{verbatim}
     2.6  
     2.7 +\section{Domain save and restore}
     2.8 +
     2.9 +The administrator of a Xen system may suspend a virtual machine's
    2.10 +current state into a disk file in domain 0, allowing it to be resumed
    2.11 +at a later time.
    2.12 +
    2.13 +The ttylinux domain described earlier can be suspended to disk using
    2.14 +the command:
    2.15 +\begin{verbatim}
    2.16 +# xm save ttylinux ttylinux.xen
    2.17 +\end{verbatim}
    2.18 +
    2.19 +This will stop the domain named `ttylinux' and save its current state
    2.20 +into a file called \path{ttylinux.xen}.
    2.21 +
    2.22 +To resume execution of this domain, use the {\tt xm restore} command:
    2.23 +\begin{verbatim}
    2.24 +# xm restore ttylinux.xen
    2.25 +\end{verbatim}
    2.26 +
    2.27 +This will restore the state of the domain and restart it.  The domain
    2.28 +will carry on as before and the console may be reconnected using the
    2.29 +{\tt xm console} command, as above.
    2.30 +
    2.31 +\section{Live migration}
    2.32 +
    2.33 +Live migration is used to transfer a domain between physical hosts
    2.34 +whilst that domain continues to perform its usual activities --- from
    2.35 +the user's perspective, the migration should be imperceptible.
    2.36 +
    2.37 +To perform a live migration, both hosts must be running Xen / Xend and
    2.38 +the destination host must have sufficient resources (e.g. memory
    2.39 +capacity) to accommodate the domain after the move.
    2.40 +
    2.41 +A domain may be migrated using the {\tt xm migrate } command.  To
    2.42 +migrate the example ttylinux domain to another machine, we would use
    2.43 +the command:
    2.44 +
    2.45 +\begin{verbatim}
    2.46 +# xm migrate --live ttylinux destination.ournetwork.com
    2.47 +\end{verbatim}
    2.48 +
    2.49 +There will be a delay whilst the domain is moved to the destination
    2.50 +machine.  During this time, the Xen migration daemon copies as much
    2.51 +information as possible about the domain (configuration, memory
    2.52 +contents, etc.) to the destination host as possible.  The domain is
    2.53 +then stopped for a fraction of a second in order to update the state
    2.54 +on the destination machine with any changes in memory contents, etc.
    2.55 +The domain will then continue on the new machine having been halted
    2.56 +for a fraction of a second (usually between about 60 -- 300ms).
    2.57 +
    2.58 +For now it will be necessary to reconnect to the domain's console on
    2.59 +the new machine using the {\tt xm console} command.  If a migrated
    2.60 +domain has any open network connections then they will be preserved,
    2.61 +so SSH connections do not have this limitation.
    2.62 +
    2.63 +Currently, there is no support for providing access to disk
    2.64 +filesystems when a domain is migrated.  Administrators should choose
    2.65 +an appropriate storage solution (i.e. SAN, NAS, etc.) to ensure that
    2.66 +domain filesystems are also available on their destination node.
    2.67 +
    2.68 +\section{Managing domain memory (ballooning and memory limits)}
    2.69 +
    2.70 +XenLinux domains have the ability to relinquish / reclaim machine
    2.71 +memory at the request of the administrator or the user of the domain.
    2.72 +
    2.73 +\subsection{Setting memory footprints from dom0}
    2.74 +
    2.75 +The machine administator can request that a domain alter its memory
    2.76 +footprint using the {\tt xm balloon} command.  For instance, we can
    2.77 +request that our example ttylinux domain reduce its memory footprint
    2.78 +to 32 megabytes.
    2.79 +
    2.80 +\begin{verbatim}
    2.81 +# xm balloon ttylinux 32
    2.82 +\end{verbatim}
    2.83 +
    2.84 +We can now see the result of this in the output of {\tt xm list}:
    2.85 +
    2.86 +\begin{verbatim}
    2.87 +# xm list
    2.88 +Name              Id  Mem(MB)  CPU  State  Time(s)  Console
    2.89 +Domain-0           0      251    0  r----    172.2        
    2.90 +ttylinux           5       31    0  -b---      4.3    9605
    2.91 +\end{verbatim}
    2.92 +
    2.93 +The domain has responded to the request by returning memory to Xen. We
    2.94 +can restore the domain to its original size using the command line:
    2.95 +
    2.96 +\begin{verbatim}
    2.97 +# xm balloon ttylinux 64
    2.98 +\end{verbatim}
    2.99 +
   2.100 +\subsection{Setting memory footprints from within a domain}
   2.101 +
   2.102 +The virtual file \path{/proc/xen/memory\_target} allows the owner of a
   2.103 +domain to adjust their own memory footprint.  Reading the file
   2.104 +(e.g. \verb!# cat /proc/xen/memory\_target!) prints out the current
   2.105 +memory footprint of the domain.  Writing the file
   2.106 +(e.g. \verb!# echo new\_target > /proc/xen/memory\_target!) requests
   2.107 +that the kernel adjust the domain's memory footprint to a new value.
   2.108 +
   2.109 +\subsection{Setting memory limits}
   2.110 +
   2.111 +Xen associates a memory size limit with each domain.  By default, this
   2.112 +is the amount of memory the domain is originally started with,
   2.113 +preventing the domain from ever growing beyond this size.  To permit a
   2.114 +domain to grow beyond its original allocation or to prevent a domain
   2.115 +you've shrunk from reclaiming the memory it reliquished, use the {\tt
   2.116 +xm maxmem} command.
   2.117 +
   2.118  \chapter{Domain filesystem storage}
   2.119  
   2.120  It is possible to directly export any Linux block device to a virtual,

     3.1 --- a/tools/python/xen/sv/CreateDomain.py	Sun Oct 31 17:37:47 2004 +0000
     3.2 +++ b/tools/python/xen/sv/CreateDomain.py	Mon Nov 01 00:57:16 2004 +0000
     3.3 @@ -32,7 +32,7 @@ class CreatePage1( Sheet ):
     3.4      def __init__( self, urlWriter ):
     3.5          Sheet.__init__( self, urlWriter, "Setup Kernel Image", 1 )
     3.6          self.addControl( ListControl( 'builder', [('linux', 'Linux'), ('netbsd', 'NetBSD')], 'Kernel Type:' ) )
     3.7 -        self.addControl( FileControl( 'kernel', '/boot/vmlinuz-2.4.26-xenU', 'Kernel Image:' ) )
     3.8 +        self.addControl( FileControl( 'kernel', '/boot/vmlinuz-2.6.9-xenU', 'Kernel Image:' ) )
     3.9          self.addControl( InputControl( 'extra', '', 'Kernel Command Line Parameters:' ) )
    3.10  
    3.11  class CreatePage2( Sheet ):