~koolhead17/openstackbook/cssbook

<?xml version="1.0" encoding="UTF-8"?><chapter xmlns:db="http://docbook.org/ns/docbook" xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" xml:id="Image_Management-d1e1252" version="5.0" xml:base="Image.xml">
   <title>Image Management</title>
<section xml:id="Introduction-d1e1257">
<title>Introduction</title>
<para> There are several pre-built images for OpenStack available from  various sources. You can download such images and use them to get familiar with OpenStack. You can refer to <link xlink:href="http://docs.openstack.org/diablo/openstack-compute/admin/content/starting-images.html">http://docs.openstack.org/diablo/openstack-compute/admin/content/starting-images.html</link> for details on using such images.</para>
<para>For any production deployment,  you may like to have the ability to bundle custom images, with a custom set of applications or configuration. This chapter will guide you through the process of creating Linux images of Debian and RedHat based distributions from scratch. We have also covered an approach to bundling Windows images.
   </para>
   <para>There are some minor differences in the way you would bundle a Linux image, based on the distribution. Ubuntu makes it very easy by providing cloud-init package, which can be used to take care of the instance configuration at the time of launch. cloud-init handles importing ssh keys for password-less login, setting host name etc. The instance acquires the instance specific configuration from Nova-compute by connecting to a meta data interface running on 169.254.169.254.</para>
   <para>While creating the image of a distro that does not have cloud-init or an equivalent package, you may need to take care of importing the keys etc. by running a set of commands at boot time from rc.local.</para>
   <para>The process used for Ubuntu and Fedora is largely the same with a few minor differences, which are explained below.</para>
   <para>In both cases, the documentation below assumes that you have a working KVM installation to use for creating the images. We are using the machine called 'client1' as explained in the chapter on "Installation and Configuration" for this purpose.</para>
   <para>The approach explained below will give you disk images that represent a disk without any partitions. Nova-compute can resize such disks ( including resizing the file system) based on the instance type chosen at the time of launching the instance. These images cannot have 'bootable' flag and hence it is mandatory to have associated kernel and ramdisk images. These kernel and ramdisk images need to be used by nova-compute at the time of launching the instance.</para>
   <para>However, we have also added a small section towards the end of the chapter about creating bootable images with multiple partitions that can be used by nova to launch an instance without the need for  kernel and ramdisk images. The caveat is that while nova-compute can re-size such disks at the time of launching the instance, the file system size is not altered and hence, for all practical purposes, such disks are not re-sizable.</para></section>
<section xml:id="Creating_a_Linux_Image_-_Ubuntu_Fedora-d1e1287">
<title>Creating a Linux Image - Ubuntu &amp; Fedora</title>
<para>The first step would be to create a raw image on Client1. This will represent the main HDD of the virtual machine, so make sure to give it as much space as you will need.</para>

<programlisting> 
kvm-img create -f raw server.img 5G
</programlisting>

<section xml:id="OS_Installation-d1e1298">
<title>OS Installation</title>

<para>Download the iso file of the Linux distribution you want installed in the image. The instructions below are tested on Ubuntu 11.10 Oneiric Ocelot 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.</para>
<programlisting> 
wget http://releases.ubuntu.com/oneiric/ubuntu-11.10-server-amd64.iso
 </programlisting>

<para>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</para>
<programlisting> 
sudo kvm -m 256 -cdrom ubuntu-11.10-server-amd64.iso -drive file=server.img,if=scsi,index=0 -boot d -net nic -net user -nographic  -vnc :0
</programlisting> 
 
<para>Connect to the VM through VNC (use display number :0) and finish the installation.</para>
<para>For Example,  where 10.10.10.4 is the IP address of client1:</para>

<programlisting> 
vncviewer 10.10.10.4 :0
</programlisting> 
<para>During the installation of Ubuntu, create a single ext4 partition mounted on '/'. Do not create a swap partition.</para>
<para>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.</para>
<para>After finishing the installation, relaunch the VM by executing the following command.</para>

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

<para>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.</para> 
<para>At the minimum, for Ubuntu you may run the following commands</para>

<programlisting> 
sudo apt-get update
</programlisting> 
<programlisting> 
sudo apt-get upgrade
</programlisting> 
<programlisting> 
sudo apt-get install openssh-server cloud-init
</programlisting>  
<para>For Fedora run the following commands as root</para>
<programlisting> 
yum update
</programlisting> 
<programlisting> 
yum install openssh-server
</programlisting> 
<programlisting> 
chkconfig sshd on
</programlisting> 

<section xml:id="Tweaking_etc_fstab-d1e1463">
<title>Tweaking /etc/fstab</title>
<para>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 launching 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. Edit /etc/fstab and change the following line from</para>
<programlisting> 
UUID=e7f5af8d-5d96-45cc-a0fc-d0d1bde8f31c   / ext4 errors=remount-ro   0   1
</programlisting> 
<para>to</para>
<programlisting> 
LABEL=uec-rootfs    /    ext4        defaults    0   0
</programlisting> 
<para>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.</para>

<programlisting> 
sudo rm -rf /etc/udev/rules.d/70-persistent-net.rules
</programlisting>
<para>Shutdown the virtual machine and proceed with the next steps.</para>
</section>
<section xml:id="Extracting_the_EXT4_partition-d1e1377">
<title>Extracting the EXT4 partition</title>
<para>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</para>
<programlisting> 
sudo losetup -f  server.img
</programlisting> 
<programlisting> 
sudo losetup -a
</programlisting>  
<para>You should see an output like this:</para>

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

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

 <para>Now we need to find out the starting sector of the partition. Run:</para>

<programlisting> 
sudo fdisk -cul /dev/loop0
</programlisting> 
<para>You should see an output like this:</para>
<programlisting> 
Disk /dev/loop0: 5368 MB, 5368709120 bytes
</programlisting> 

<programlisting> 
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
</programlisting>


<para>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</para>
<para>Unmount the loop0 device:</para>

<programlisting> 
sudo losetup -d /dev/loop0
</programlisting>

<para>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</para>

<programlisting> 
sudo losetup -f -o 1048576 server.img
</programlisting> 

<programlisting> 
sudo losetup -a
</programlisting> 
<para>You'll see a message like this:</para>
<programlisting> 
/dev/loop0: [0801]:16908388 ($filepath) offset 1048576
</programlisting> 
<para>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.</para>

<para>Copy the entire partition to a new .raw file</para>
<programlisting> 
sudo dd if=/dev/loop0 of=serverfinal.img
</programlisting> 

<para>Now we have our ext4 filesystem image i.e serverfinal.img</para>

<para>Unmount the loop0 device</para>

<programlisting> 
sudo losetup -d /dev/loop0
</programlisting> 
</section>
<section xml:id="Fetching_Metadata_in_Fedora-d1e1488">
<title>Fetching Metadata in Fedora</title>

<para>Since, Fedora does not ship with cloud-init or an equivalent, you will need to take a few steps to have the instance  fetch the meta data like ssh keys etc.</para>
   <para>Edit the /etc/rc.local file and add the following lines before the line "touch /var/lock/subsys/local"</para>

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

<para>Unmount the Loop partition</para>

<programlisting> 
sudo umount /mnt
</programlisting> 
<para>Change the filesystem label of serverfinal.img to 'uec-rootfs'</para>
<programlisting> 
sudo tune2fs -L uec-rootfs serverfinal.img
</programlisting> 

<para>Now, we have all the components of the image ready to be uploaded to OpenStack imaging server.</para>
</section>
<section xml:id="Uploading_to_OpenStack-d1e1534">
<title>Uploading to OpenStack</title>
<para>The last step would be to upload the images to OpenStack Imaging Server glance. The files that need to be uploaded for the above sample setup of Ubuntu are: vmlinuz-2.6.38-7-server, initrd.img-2.6.38-7-server, serverfinal.img</para>
<para>Run the following command</para>

<programlisting> 
uec-publish-image amd64 serverfinal.img bucket1
</programlisting> 

<para>For Fedora, the process will be similar. Make sure that you use the right kernel and initrd files extracted above.</para>
<para>uec-publish-image, like several other commands from euca2ools, returns the prompt back immediately. However, the upload process takes some time and the images will be usable only after the process is complete. You can keep checking the status using the command 'euca-describe-images' as mentioned below.</para>

<para>You can upload bootable disk images without associating kernel and ramdisk images. When you do not want the flexibility of using the same disk image with different kernel/ramdisk images, you can go for bootable disk images. This greatly simplifies the process of bundling and uploading the images. However, the caveats mentioned in the introduction to this chapter apply. Please note that the instructions below use server.img and you can skip all the cumbersome steps related to extracting the single ext4 partition.</para>

<programlisting> 
euca-bundle-image -i server.img
</programlisting> 
<programlisting> 
euca-upload-bundle -b mybucket -m /tmp/server.img.manifest.xml
</programlisting> 
<programlisting> 
euca-register mybucket/server.img.manifest.xml
</programlisting> 
</section>
<section xml:id="Image_Listing-d1e1568">
<title>Image Listing</title>

<para>The status of the images that have been uploaded can be viewed by using euca-describe-images command. The output should like this:</para>

<programlisting> 
localadmin@client1:~$ euca-describe-images
</programlisting> 
<programlisting>
IMAGE	ami-00000003	mybucket9/Fedora14Nova.img.manifest.xml		available	private		x86_64	machine		instance-store
</programlisting>
</section>
<section xml:id="Creating_a_Windows_Image-d1e1594">
<title>Creating a Windows Image</title>
<para>The first step would be to create a raw image on Client1, this will represent the main HDD of the virtual machine, so make sure to give it as much space as you will need.</para>

<programlisting> 
kvm-img create -f raw windowsserver.img 20G
</programlisting> 

<para>OpenStack presents the disk using aVIRTIO interface while launching the instance. Hence the OS needs to have drivers for VIRTIO. By default, the Windows Server 2008 ISO does not have the drivers for VIRTIO. Download the virtual floppy drive containing VIRTIO drivers from the following location</para>
   <para>
      http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/
   </para>
   <para>and attach it during the installation</para>
   <para>Start the installation by running</para>

<programlisting> 
sudo kvm -m 1024 -cdrom win2k8_dvd.iso -drive file=windowsserver.img,if=virtio,boot=on -fda virtio-win-1.1.16.vfd -boot d -nographic -vnc :0
</programlisting> 

<para>When the installation prompts you to choose a hard disk device you won't see any devices available. Click on "Load drivers" at the bottom left and load the drivers from A:\i386\Win2008</para>
   <para>After the Installation is over, boot into it once and install any additional applications you need to install and make any configuration changes you need to make. Also ensure that RDP is enabled as that would be the only way you can connect to a running instance of Windows. Windows firewall needs to be configured to allow incoming ICMP and RDP connections.</para>
   <para>For OpenStack to allow incoming RDP Connections, use euca-authorize command to open up port 3389 as described in the chapter on "Security".</para>
<para>Shut-down the VM and upload the image to OpenStack</para>

<programlisting> 
euca-bundle-image -i windowsserver.img
</programlisting> 

<programlisting> 
euca-upload-bundle -b mybucket -m /tmp/windowsserver.img.manifest.xml
</programlisting> 

<programlisting> 
euca-register mybucket/windowsserver.img.manifest.xml
</programlisting>
</section>
</section>
</section>
</chapter>