July 15, 2010, was a big "game changer" for AMI images at Amazon, when they announced their [http://developer.amazonwebservices.com/connect/entry.jspa?externalID=3967&categoryID=174 Enabling User Provided Kernels in Amazon EC2]. This allows people to build anything they want on EC2 run their own custom kernels; [http://wiki.xensource.com/xenwiki/PvGrub pv-grub] is just a small chainloader (to put it simply).

+

July 15, 2010, was a big "game changer" for AMI images at Amazon, when they announced [http://developer.amazonwebservices.com/connect/entry.jspa?externalID=3967&categoryID=174 Enabling User Provided Kernels in Amazon EC2]. This allows people to build anything they want on EC2, running their own custom kernels; [http://wiki.xensource.com/xenwiki/PvGrub pv-grub] is just a small chainloader (to put it simply).

In the case of EC2, it will either look at '''(hd0)/boot/grub/menu.lst''' or '''(hd0,0)/grub/menu.lst''', depending on whether you used the hd0 or hd00 aki. Using the "hd0" image means that pv-grub is expecting /dev/xvda1 to be a partitionless target; the other option, hd00, is "root (hd0,0)" in a standard grub file - meaning, it's pointing to the first partition on the first drive (instead of hd0, the whole drive).

In the case of EC2, it will either look at '''(hd0)/boot/grub/menu.lst''' or '''(hd0,0)/grub/menu.lst''', depending on whether you used the hd0 or hd00 aki. Using the "hd0" image means that pv-grub is expecting /dev/xvda1 to be a partitionless target; the other option, hd00, is "root (hd0,0)" in a standard grub file - meaning, it's pointing to the first partition on the first drive (instead of hd0, the whole drive).

Revision as of 01:21, 13 August 2010

This initially will just have the basic steps for creating EBS-backed, custom images. In this document will be refences to running commands from the ec2-api-tools suite; you may quickly find that these tools often do not do things the way you'd like, and find yourself writing your own tools for talking to the REST/Query API or using tools like euca2ools (which is part of the Fedora Cloud_SIG feature list for Fedora 14).

Contents

pvgrub

July 15, 2010, was a big "game changer" for AMI images at Amazon, when they announced Enabling User Provided Kernels in Amazon EC2. This allows people to build anything they want on EC2, running their own custom kernels; pv-grub is just a small chainloader (to put it simply).

In the case of EC2, it will either look at (hd0)/boot/grub/menu.lst or (hd0,0)/grub/menu.lst, depending on whether you used the hd0 or hd00 aki. Using the "hd0" image means that pv-grub is expecting /dev/xvda1 to be a partitionless target; the other option, hd00, is "root (hd0,0)" in a standard grub file - meaning, it's pointing to the first partition on the first drive (instead of hd0, the whole drive).

Custom EBS-backed images

Follows is the basic rundown of the steps:

create build instance

This doesn't need to be it's own instance. It can be an instance you already

have. It can be anything, so long as it supports the filesystems you will want on your target AMI.

create build target volume

This is the volume the new OS will be installed upon, and of which a snapshot

will be created. Make it, attach it to the build host - note the below script
has "/dev/sdf" as the target, so it might be easiest to just attach there.

build custom OS

The basic concept here is that we're building a snapshot image within a chroot environment. This is made easy by the yum utilities' "--installroot" option. An overly simple example of a script that will do the entire OS snapshot build for you is the createfedora13bootebs.sh script.

If you want to create your own process for creating an OS snapshot, the only difficulty is in the contents of the /boot/grub directory; everything else is extremely simple and more or less just falls in to place without effort.

Within the /boot/grub directory, there needs be only grub.conf and menu.lst; you may experience problems if either one is a symlink instead of a file, so creating one and then making the other a hardlink to the same is the best idea. This can be done with the ln command; simply omit the "-s" that is normally appended, as that flag is for making a soft link (while you want a hard link). Note this means that all the various stage files are not necessary; my personal AMIs run just fine with only 1 file in /boot/grub

Within this one file, note that you want the kernel line to have "root=/dev/xvda1" - despite the fact that you will be telling Amazon to mount the disk at /dev/sda1, and it will claim that's where it is mounted, in reality it will be mounted at /dev/xvda1. This can be changed, but the goal here is a functional AMI; tailoring it further will be up to you.

Finally, since the device is at /dev/xvda1, remember to set the entry in fstab appropriately.

Detach volume

This is simple enough; just run

ec2-detach-volume --region region_name volume_id

create snapshot

Many guides on the inter-tubes will tell you to stop mysql, run rsync, wash your dishes, order some pizza, etc. None of that is necessary here though, because we're not doing the dangerous activity of making a snapshot of a running OS and calling it blessed; we're making a snapshot of an OS that was built inside a chroot environment, which was then unmounted. The filesystems are in a pure, clean, unmounted, happy state. This step can be as fast as just a couple seconds, or it could get stuck in a queue for a couple minutes before completing.

AMI images

The basic components of an AMI are an AKI and a snapshot; we have the snapshot from above, now we need an AKI.

Finding a pvgrub AKI

Regardless how you come up with the snapshot you're using, creating the AMI itself is more or less the same (with only a change to --block-device-mapping necessary for the various storage options). You'll need to know what pv-grub AKI to use. A simple check will tell you what the kernels in your preferred region are:

ec2-describe-images -H --region us-west-1 -x all|grep "pv-grub-hd0"

Creating the AMI

So now you have your snapshot, your AKI...what else do you need? Nothing!

Red Hat, Red Hat Enterprise Linux, the Shadowman logo, and JBoss are trademarks or registered trademarks of
Red Hat, Inc. or its subsidiaries in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries.
The Fedora Project is maintained and driven by the community and sponsored by Red Hat. This is a community
maintained site. Red Hat is not responsible for content.