Old Images

Harold Spencer Jr edited this page Jul 4, 2013 · 3 revisions
Clone this wiki locally

NOTE: the content on this page is from the old projects.eucalyptus.com site and might be out of date.

h1. Images

The starter images, which you may find at http://open.eucalyptus.com/wiki/EucalyptusUserImageCreatorGuide, are based on popular distro. To made them more cloud friendly they have few twists:

  • they have a very small root file system (so far 1.3 and 4.5 GB): this allows them to boot very fast, with the downside of having a small root, hence they rely heavily on EBS and ephemeral;
  • they are based on the original distro, but the package list has been trimmed from the original default install;
  • packages have been added from the original default install;
  • an rc.local has been added to allow the instance to interact with the "meta-data":http://open.eucalyptus.com/participate/wiki/accessing-instance-metadata service;
  • a /etc/image-id to keep track of the version of the base image used for the instance.

Most of the files, scripts and stuff needed for the images are kept at https://github.com/eucalyptus/Eucalyptus-Scripts. The git repo is mirrored here on projects if you prefer to review it here.

h1. rc.local

The source:rc.local we use is a very simple one, and it mainly interact with the meta-data service. Right now it grabs the ssh keys (to allow root to login), mount ephemeral0 to the right place, and try to grab the user-data (if there is any) and execute it if it is a script.

The latter allow the images to be easily customized at boot time: check out project:recipes for some scripts to use with this rc.local.

h1. EMI id

We keep an image-id on each image at /etc/image-id to allow for easy identification of the image used for the instance. We keep a list of the current image-ids in the well known repo at source:EMI-IDs. Check the git log as a changelog on the images. The fields are

  • image_name: brief description of the EMI for example "euca-debian-emi"
  • image_version: a string defining the version of the EMI for example "2011.08.15"
  • image_arch: the architecture of the installed binaries, for example "x86_64"
  • image_file: the file name for the image, for example "euca-debian-2011.08.15-x86_64.img"
  • image_stamp: a unique ID for the specific image, for example "082d-d3a4". Currently it is generated using
date +%s|md5sum|sed '1,$ s/\(....\)\(....\).*/\1-\2/'
  • image_date: currently generated using date "+%Y%m%d%H%M%S" for example "20110815122021"
  • recipe_name: this will tell which distro the EMI is based off for example "debian-based"

Here are some image-id files for images we're creating image-ids Look here for descriptions of the images we've created image-info

h1. Root file systems on different devices

Depending on the hypervisor and guestOS configuration, block devices may show up as xvd* or vd* or sd*. In "ticket 97:https://projects.eucalyptus.com/redmine/issues/97" there is the discussion. The solution is to modify udev:

cat /etc/udev/rules.d/euca-udev.rules
KERNEL=="xvd*", PROGRAM="/sbin/euca-udev %k", SYMLINK+="%c"

The program "/sbin/euca-udev" is as follows:

if [ "$#" -ne 1 ] ; then
   echo "$0 " >&2
   exit 1
   if echo "$1"|grep -qE 'xvd[a-z][0-9]?' ; then
      echo "$1" | sed -e 's/xvd/sd/'
      echo "$1"

h1. single kernel

We have a separate project to tackle the single-kernel issue at project:kernel.

h1. zerofree

Before tarring the images up, we run zerofree on them (on a Debian system there is a zerofree package) which will fill all the unused sectors with zeros (it works only for ext2/3 file systems). This allows for the images to be more easily compressed hence making the tar file much smaller.

h1. aelastic PPA

We did add the "aelastic":aelastic.com PPA to the list of repos to pull packages from (when applicable) to allow for ec2-constiste-snapshot to be present on the image. So on debian-based distro we added the following key:

 apt-key adv --keyserver keyserver.ubuntu.com --recv-keys BE09C571

h1. partner image requirements


h1. tips and tricks

A quick way to modify the images is to mount them on the loop device and them bind-mound some of the needed kernel file systems

mount -o loop  /mnt
mount -o bind /proc /mnt/proc
mount -o bind /sys /mnt/sys
mount -o bind /dev /mnt/dev
mount -o bind /dev/pts /dev/pts

You can then chroot and modify the image (for example install or remove packages). Before exiting, you should clean up after yourself, for example

yum clean all
apt-get clean

you may want to remove the history of your commands (after you end the chroot session)

rm /mnt/root/.bash_history

h1. Extend your root FS with the ephemeral disk


h1. IRC meeting summaries and full logs