StatelessLinux/CreateImageWithXen
From FedoraProject
Stateless Linux - Creating An Image Using Xen
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
-uand-moptions) - The
-poption specifies that the guest should be paravirtualised, the-voption specifies that the guest should be fully virtualised. - Passing a relative path to
-fonly works withxen >= 3.0.2-10, passing a relative path to-cneedsxen >= 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 containimages/xen/vmlinuzandimages/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
