Creating a Linux Image – Ubuntu & Fedora

Download the iso file of the Linux distribution you want installed in the image. The instructions below are tested on Ubuntu 11.04 Natty Narwhal 64-bit server and Fedora 14 64-bit. Most of the instructions refer to Ubuntu. The points of difference between Ubuntu and Fedora are mentioned wherever required.

wget http://releases.ubuntu.com/natty/ubuntu-11.04-server-amd64.iso

Boot a KVM Instance with the OS installer ISO in the virtual CD-ROM. This will start the installation process. The command below also sets up a VNC display at port 0

sudo kvm -m 256 -cdrom ubuntu-11.04-server-amd64.iso -drive   file=server.img,if=scsi,index=0 -boot d -net nic -net user -nographic  -vnc :0

Connect to the VM through VNC (use display number :0) and finish the installation.

For Example, where 10.10.10.4 is the IP address of client1:

 vncviewer 10.10.10.4 :0

During the installation of Ubuntu, create a single ext4 partition mounted on ‘/’. Do not create a swap partition.

In the case of Fedora 14, the installation will not progress unless you create a swap partition. Please go ahead and create a swap partition.

After finishing the installation, relaunch the VM by executing the following command.

sudo kvm -m 256 -drive file=server.img,if=scsi,index=0 -boot c -net nic -net user -nographic -vnc :0

At this point, you can add all the packages you want to have installed, update the installation, add users and make any configuration changes you want in your image.

At the minimum, for Ubuntu you may run the following commands

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install openssh-server cloud-init

For Fedora run the following commands as root

yum update
yum install openssh-server
chkconfig sshd on

Also remove the network persistence rules from /etc/udev/rules.d as their presence will result in the network interface in the instance coming up as an interface other than eth0.

sudo rm -rf /etc/udev/rules.d/70-persistent-net.rules

Shutdown the Virtual machine and proceed with the next steps.

The image that needs to be uploaded to OpenStack needs to be an ext4 filesystem image. Here are the steps to create a ext4 filesystem image from the raw image i.e server.img

sudo losetup  -f  server.img
sudo losetup -a

You should see an output like this:

/dev/loop0: [0801]:16908388 ($filepath)

Observe the name of the loop device ( /dev/loop0 in our setup) when $filepath is the path to the mounted .raw file.

Now we need to find out the starting sector of the partition. Run:

sudo fdisk -cul /dev/loop0

You should see an output like this:

Disk /dev/loop0: 5368 MB, 5368709120 bytes
149 heads, 8 sectors/track, 8796 cylinders, total 10485760 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00072bd4
Device Boot      Start         End      Blocks   Id  System
/dev/loop0p1   *        2048    10483711     5240832   83  Linux

Make a note of the starting sector of the /dev/loop0p1 partition i.e the partition whose ID is 83. This number should be multiplied by 512 to obtain the correct value. In this case: 2048 x 512 = 1048576

Unmount the loop0 device:

sudo losetup -d /dev/loop0

Now mount only the partition(/dev/loop0p1) of server.img which we had previously noted down, by adding the -o parameter with value previously calculated value

sudo losetup -f -o 1048576 server.img
sudo losetup -a

You’ll see a message like this:

/dev/loop0: [0801]:16908388 ($filepath) offset 1048576

Make a note of the mount point of our device(/dev/loop0 in our setup) when $filepath is the path to the mounted .raw file.

Copy the entire partition to a new .raw file

sudo dd if=/dev/loop0 of=serverfinal.img

Now we have our ext4 filesystem image i.e serverfinal.img

Unmount the loop0 device

sudo losetup -d /dev/loop0

You will need to tweak /etc/fstab to make it suitable for a cloud instance. Nova-compute may resize the disk at the time of launch of instances based on the instance type chosen. This can make the UUID of the disk invalid. Hence we have to use File system label as the identifier for the partition instead of the UUID.

Loop mount the serverfinal.img, by running

sudo mount -o loop serverfinal.img /mnt

Edit /mnt/etc/fstab and modify the line for mounting root partition(which may look like the following)

UUID=e7f5af8d-5d96-45cc-a0fc-d0d1bde8f31c  /               ext4    errors=remount-ro  0       1

to

LABEL=uec-rootfs              /          ext4           defaults     0    0
                

An instance must perform several steps on startup by interacting with the metadata service (e.g., retrieve ssh public key, execute user data script). When building a Fedora image, there are several options for implementing this functionality, including:

To fetch the ssh public key and add it to the root account, edit the /etc/rc.local file and add the following lines before the line “touch /var/lock/subsys/local”

depmod -a
modprobe acpiphp

# simple attempt to get the user ssh key using the meta-data service
mkdir -p /root/.ssh
echo >> /root/.ssh/authorized_keys
curl -m 10 -s http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key | grep 'ssh-rsa' >> /root/.ssh/authorized_keys
echo "AUTHORIZED_KEYS:"
echo "************************"
cat /root/.ssh/authorized_keys
echo "************************"

Note

The above script only retrieves the ssh public key from the metadata server. It does not retrieve user data, which is optional data that can be passed by the user when requesting a new instance. User data is often used for running a custom script when an instance comes up. As the OpenStack metadata service is compatible with the Amazon EC2 metadata service, consult the Amazon EC2 documentation on Using Instance Metadata for details on how to retrieve user data.