Use of dialog to capture user input.

[virt-p2v.git] / README.developers

diff --git a/README.developers b/README.developers
index d46d5d9..8dd9561 100644 (file)
--- a/README.developers
+++ b/README.developers
@@ -1,9 +1,83 @@
-The files in this directory are:
+$Id$
 
-livecd-test.ks.in
+Background reading
+----------------------------------------------------------------------
+
+About Live CDs / livecd-creator tool:
+
+  http://fedoraproject.org/wiki/FedoraLiveCD/LiveCDHowTo
+
+The files in this directory
+----------------------------------------------------------------------
+
+livecd.ks.in
+
+  Kickstart file which describes how to build the live CD.  This is
+  essentially the configuration file for livecd-creator.  Most
+  importantly it lists the RPMs which are needed on the live CD.
 
 livecd-post.sh.in
 
+  This is the %post-configuration section of the Kickstart script.  It
+  is a shell script which runs after the RPMs have been installed but
+  before the live CD is turned into an ISO.  The shell script creates
+  any extra files we need on the live CD.
+
 p2v.init
 
+  This is installed on the live CD as /etc/init.d/p2v, and it causes the
+  live CD to boot into the P2V configuration tool (see next).
+
 virt-p2v.sh
+
+  This is the virt-p2v.sh P2V configuration tool itself.  It is
+  installed on the live CD as /usr/bin/virt-p2v.sh and runs after the
+  live CD has booted.  All the P2V stuff happens from this script. It
+  uses the 'dialog' program to ask questions.
+
+General implementation plan
+----------------------------------------------------------------------
+
+User boots the live CD.  The job of the live CD is to:
+
+(a) Find local disks.
+
+(b) Copy the disk image(s) over to the Xen host.
+
+(c) Change certain files (eg. /etc/fstab may contain references to
+disk devices, which need to be changed when running under Xen).
+
+(d) BUT, the live CD must be totally non-destructive.  It cannot
+modify the local disks in any way.
+
+(e) The above steps are not automatic.  We need to ask the user some
+questions along the way.
+
+For (a) there are various methods to detect local devices.  We sniff
+for devices in /sys/block.
+
+For (b) we can simply use 'dd' and 'ssh'.  The general plan is to do
+this:
+
+  dd if=/dev/disk | gzip | ssh xenhost 'cat > /var/lib/xen/images/disk.img'
+
+If the user doesn't have sshd installed on the Xen host, then they can
+also opt for a pure TCP transport:
+
+  dd if=/dev/disk | gzip | nc xenhost port
+
+  and on the remote host they do:
+  nc -l -p port > /var/lib/xen/images/disk.img
+
+For (c) we can use device-mapper snapshots to mount a ramdisk above
+the disks themselves.  This allows us to make non-destructive changes
+to files, and still see the "modified" block device (d).  A hairy
+shell script looks for candidate files to modify.
+
+Non-generic virt-p2v
+----------------------------------------------------------------------
+
+The above describes the generic virt-p2v, which asks users questions
+after boot.  It is also possible to build your own live CD, based on
+virt-p2v which has various settings compiled in, so it runs
+automatically.
\ No newline at end of file