StatelessLinux/CreateImageWithXen

= Stateless Linux - Creating An Image Using Xen =

See  Stateless Linux HOWTO

Before you begin, you'll need to be running a xen hypervisor and kernel and have xend running. See  FedoraXenQuickstartFC5  for more details.

Running, you get asked a number of questions:


 * The name to use for the guest domain
 * The amount of RAM you want to allocate to the guest
 * The path to the disk image you want provide to the guest
 * If this image doesn't already exist, the size it should be
 * Whether you want a fully virtualized guest, or a paravirtualized guest
 * If it's going to be a paravirt guest, the location of the Fedora install tree you wish to install from
 * If it's going to be a full virtualized guest, the location of the image or device to use as a bootable cdrom

All these options can be specified on the command line, so e.g. using paravirt:

$> xenguest-install.py -n Terminal -f terminal-pv.img -s 4 -r 512 -p -l http://172.31.0.4/rawhide-latest/x86_64

It should also be possible to install using fully-virt, with e.g.

$> xenguest-install.py -n Terminal -f terminal-fv.img -s 4 -r 512 -v -c ./boot.iso

Notes:


 * The size of the disk image you create is important. You want to choose an image size which will be large enough for your needs into the future, but also not so large as to needlessly waste disk space and bandwidth.
 * On the other hand, the amount of RAM you allocate to the guest is only relevant for the duration of the install.
 * xenguest-install can create random MAC addresses and UUID, but you can re-use these random ones on the command line later if you wish (using  and   options)
 * The  option specifies that the guest should be paravirtualised, the   option specifies that the guest should be fully virtualised.
 * Passing a relative path to  only works with , passing a relative path to   needs
 * If DCHP in the guest fails, it's probably because of bug #197172 . This is fixed in FC6 test2.
 * With, the install tree must contain   and   - sometimes rawhide doesn't have a Xen kernel and these files will be missing.
 * You should use a different name for the LVM Volume Group (i.e. something other than ) otherwise it's likely to clash with another domain's volume group. LVM needs fixing to handle duplicate volume group names better.

Copying The Root Filesystem Image
Now you'll want to extract the ext3 root filesystem image from the disk image.

First, associate the disk image with a loopback device:

$> losetup ./terminal-pv.img /dev/loop0

Now, using the  utility from the   package, create devices which map to each of the partitions on the disk image:

$> kpartx -av /dev/loop0 add map loop0p1 : 0 208782 linear /dev/loop0 63 add map loop0p2 : 0 8177085 linear /dev/loop0 208845

This causes the  and   devices to be created, mapping to the partitions on the disk image.

Assuming you created the root filesystem in an LVM volume, you'll now need to activate the volume group stored on the second partition on the disk image.

$> vgscan Reading all physical volumes. This may take a while... Found volume group "TerminalVG" using metadata type lvm2 Found volume group "VolGroup00" using metadata type lvm2 $> vgchange -ay TerminalVG

You can now copy the root filesystem image to a file:

$> dd if=/dev/TerminalVG/LogVol00 of=./terminal-rootfs.img

Optionally, you can use this little utility to make a sparse copy (i.e. a copy which takes up less space) of the image:

$> e2cp ./terminal-rootfs.img ./terminal-rootfs-sparse.img

Finally, clean up after yourself:

$> vgchange -an TerminalVG $> kpartx -d /dev/loop0 $> losetup -d /dev/loop0