changeset 772:5201797ee24a

bitkeeper revision 1.469 (3f7781640Z-nJWz_6IzI5Q6lTJPXJg)

Add text about installing Xen on a standard distribution.
author iap10@labyrinth.cl.cam.ac.uk
date Mon Sep 29 00:48:36 2003 +0000 (2003-09-29)
parents f6f2a326ccaa
children 522d23c14a4f
files BitKeeper/etc/ignore README.CD
line diff
     1.1 --- a/BitKeeper/etc/ignore	Sun Sep 28 23:16:36 2003 +0000
     1.2 +++ b/BitKeeper/etc/ignore	Mon Sep 29 00:48:36 2003 +0000
     1.3 @@ -469,3 +469,5 @@ tools/internal/xi_sched_domain
     1.4  tools/internal/xi_sched_global
     1.5  xen/arch/i386/nmi.o
     1.6  xen/drivers/net/dummy.o
     1.7 +tools/misc/miniterm/miniterm
     1.8 +tools/misc/xen_read_console
     2.1 --- a/README.CD	Sun Sep 28 23:16:36 2003 +0000
     2.2 +++ b/README.CD	Mon Sep 29 00:48:36 2003 +0000
     2.3 @@ -436,6 +436,97 @@ Alternatively, telnet can be used in 'ch
     2.4  connected to a serial-port server.
     2.7 +Installing Xen / XenoLinux on a RedHat distribution
     2.8 +===================================================
     2.9 +
    2.10 +When using Xen / Xenolinux on a standard Linux distribution there are
    2.11 +a couple of things to watch out for:
    2.12 +
    2.13 +The first Linux VM that is started when Xen boots start (Domain 0) is
    2.14 +given direct access to the graphics card, so it may use it as a
    2.15 +console. Other domains don't have ttyN consoles, so attempts to run a
    2.16 +'mingetty' against them will fail, generating periodic warning
    2.17 +messages from 'init' about services respawning too fast. They should
    2.18 +work for domain0 just fine.
    2.19 +
    2.20 +In future, we may make the current 'xencons' accept input as well as
    2.21 +output, so that a getty can be run against it. In the meantime, other
    2.22 +domains don't have a console suitable for logging in on, so you'll
    2.23 +have to run sshd and ssh in to them.
    2.24 +
    2.25 +To prevent the warning messages you'll need to remove them from
    2.26 +/etc/inittab for domains>0.  Due to a bug in the RH9 /etc/rc.sysinit
    2.27 +script #'ing the lines out of /etc/inittab won't work as it ignores
    2.28 +the '#' and tries to access them anyway.
    2.29 +
    2.30 +Also, because domains>0 don't have any privileged access at all,
    2.31 +certain commands in the default boot sequence will fail e.g. attempts
    2.32 +to update the hwclock, change the console font, update the keytable
    2.33 +map, start apmd (power management), or gpm (mouse cursor).  Either
    2.34 +ignore the errors, or remove them from the startup scripts.  Deleting
    2.35 +the following links are a good start: S24pcmcia S09isdn S17keytable
    2.36 +S26apmd S85gpm
    2.37 +
    2.38 +If you want to use a single root file system that works cleanly for
    2.39 +domain0 and domains>0, one trick is to use different 'init' run
    2.40 +levels. For example, on the Xen Demo CD we use run level 3 for domain
    2.41 +0, and run level 4 for domains>0. This enables different startup
    2.42 +scripts to be run in depending on the run level number passed on the
    2.43 +kernel command line. The xenctl.xml config file on the CD passes '4'
    2.44 +on the kernel command line to domains that it starts.
    2.45 +
    2.46 +Xenolinux kernels can be built to use runtime loadable modules just
    2.47 +like normal linux kernels. Modules should be installed under
    2.48 +/lib/modules in the normal way.
    2.49 +
    2.50 +If there's some kernel feature that hasn't been built into our default
    2.51 +kernel, there's a pretty good change that if its a non-hardware
    2.52 +related option you'll just be able to enable it and rebuild.  If its
    2.53 +not on the xconfig menu, hack the arch/xeno/config.in to put the menu
    2.54 +back in.
    2.55 +
    2.56 +If you're going to use the link local 169.254.1.x addresses to
    2.57 +communicate between VMs, there are a couple of other issues to watch
    2.58 +out for. RH9 appears to have a bug where by default it configures the
    2.59 +loopback interface with a 169.254 address, which stops it working
    2.60 +properly on eth0 for communicating with other domains.
    2.61 +
    2.62 +This utterly daft RH9 behaviour can be stopped by appending
    2.63 +"NOZEROCONF=yes" to /etc/sysconfig/networking-scripts/ifcfg-lo
    2.64 +
    2.65 +If you're going to use NFS root files systems mounted either from an
    2.66 +external server or from domain0 there are a couple of other gotchas.
    2.67 +The default /etc/sysconfig/iptables rules block NFS, so part way
    2.68 +through the boot sequence things will suddenly go dead.
    2.69 +
    2.70 +If you're planning on having a separate NFS /usr partition, the RH9
    2.71 +boot scripts don't make life easy, as they attempt to mount NFS file
    2.72 +systems way to late in the boot process. The easiest way I found to do
    2.73 +this was to have a '/linuxrc' script run ahead of /sbin/init that
    2.74 +mounts /usr:
    2.75 + #!/bin/bash
    2.76 + /sbin/ipconfig lo
    2.77 + /sbin/portmap
    2.78 + /bin/mount /usr
    2.79 + exec /sbin/init "$@" <>/dev/console 2>&1
    2.80 +
    2.81 +The one slight complication with the above is that /sbib/portmap is
    2.82 +dynamically linked against /usr/lib/libwrap.so.0 Since this is in
    2.83 +/usr, it won't work. I solved this by copying the file (and link)
    2.84 +below the /usr mount point, and just let the file be 'covered' when
    2.85 +the mount happens.
    2.86 +
    2.87 +In some installations, where a shared read-only /usr is being used, it
    2.88 +may be desirable to move other large directories over into the
    2.89 +read-only /usr. For example, on the XenDemoCD we replace /bin /lib and
    2.90 +/sbin with links into /usr/root/bin /usr/root/lib and /usr/root/sbin
    2.91 +respectively. This creates other problems for running the /linuxrc
    2.92 +script, requiring bash, portmap, mount, ifconfig, and a handful of
    2.93 +other shared libraries to be copied below the mount point. I guess I
    2.94 +should have written a little statically linked C program...
    2.95 +
    2.96 +
    2.97 +
    2.98  Description of how the XenDemoCD boots
    2.99  ======================================