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 xenguest-install.py, 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 -u and -m options)
• The -p option specifies that the guest should be paravirtualised, the -v option specifies that the guest should be fully virtualised.
• Passing a relative path to -f only works with xen >= 3.0.2-10, passing a relative path to -c needs xen >= 3.0.2-24
• If DCHP in the guest fails, it's probably because of bug #197172 . This is fixed in FC6 test2.
• With -p, the install tree must contain images/xen/vmlinuz and images/xen/initrd.img - 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 VolGroup00) 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 kpartx utility from the device-mapper-multipath 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 /dev/mapper/loop0p1 and /dev/mapper/loop0p2 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