X-Git-Url: http://git.annexia.org/?a=blobdiff_plain;f=README.developers;h=8dd9561899379bd08dcc74adffc97578c8f05845;hb=1835c920726e5ce4f012ba1fc4cba0d33c9b316a;hp=d46d5d9cb924850180da1729ed72b09f5e70b6f3;hpb=86bfeb367eb0367046acde183eb6b677ee1d0d1f;p=virt-p2v.git diff --git a/README.developers b/README.developers index d46d5d9..8dd9561 100644 --- 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