In this post, we will take the next step and that is uploading (to Walrus) and registering a machine image (EMI) with Eucalyptus. Once we have registered the image, we can then run instances of this image using either Amazon EC2 API or Euca2ools.

Eucalyptus Machine Image

A machine image, or more specifically, a Eucalyptus Machine Image (EMI) is a template, stored in Walrus, that can be used to create and run instances. A EMI is a combination of:

• a kernel image,
• a ramdisk image, and
• one or more virtual hard disk image

The kernel image is more specifically referred to as Eucalyptus Kernel Image (EKI) and the ramdisk image is referred to as Eucalyptus Ramdisk Image (ERI).

Each of the images – EKI, ERI, and EMI – have associated xml files containing meta-data about the corresponding images respectively.

The EKIs, ERIs, and EMIs are stored in Walrus and can be referenced by a identifier, Image ID.

Now that we have some background information on EMI’s, let’s get started.

Download Eucalyptus Certified Image

Start by opening a browser and connecting to https://<front-end-ip-address>:8443. In my case, the front-end is 192.168.0.114 (see this post).

Log in with your admin user and password.

Next, click on the Extras tab. And download one of the “Eucalyptus-certified Images”. I picked the CentOS 5.3 i386 image (euca-centos-5.3-i386.tar.gz). I downloaded it on my front-end machine for now.

For the rest of this document, I’ll be referring to the CentOS 5.3 i386 image. Feel free to replace this with the image you downloaded as you proceed through this post.

Once you un-tar the file, you should see a directory structure similar to the following:

where in my case,
centos.5-3.x86.img – is the root disk image
kvm-kernel – directory containing kvm-based kernel and ramdisk (vmlinuz-2.6.28-11-server and initrd.img-2.6.28-11-server)
xen-kernel – directory containing xen-based kernel and ramdisk (vmlinuz-2.6.24-19-xen and initrd.img-2.6.24-19-xen)

Now we can bundle the kernel, ramdisk, and hard disk image, upload it to walrus and register each of them respectively. But before we do this, I’m going to take a small detour.

Detour: Resizing the disk image

Notice in the directory listing of euca-centos-5.3-i386, the size of the centos.5-3.x86.img is only 1 GB. If you bundle, upload and register an EMI out of this image, your instance will have only a 1 GB root partition. Which is fairly small if you plan on installing software on a running instance. For instance, if you try to install Sun Java on it, the installation will fail due to lack of space.

Hence this is a good time to increase the size from 1GB to say, 4GB.

Note: Feel free to skip this step and proceed with the bundling, uploading, and registering of the images.

To re-size the image, let’s start by creating a clean image file, new_centos.5-3.x86.img of size 4GB. We can do this using the dd command.

dd if=/dev/zero of=new_centos.5-3.x86.img bs=1M count-4096

where,
if – source. In this case, we are reading a stream of zeroes from (/dev/zero) device.
of – target. Our new image file (new_centos.5-3.x86.img). The stream of zeroes are copied to this file.
bs – read and write in blocks of 1M
count – copy 4GB of blocks

The above command may take a few minutes to complete. You see output similar to this when done:

Next, associate loop devices with each of the original (centos.5-3.x86.img) and new (new_centos.5-3.x86.img) image files. Make sure that the loop devices that you are going to use are free. You can check the next available loop device using the losetup -f command. In my case, I have /dev/loop1 and /dev/loop2 available.

losetup /dev/loop1 centos.5-3.x86.img
losetup /dev/loop2 new_centos.5-3.x86.img

Confirm the status of the loop devices

losetup /dev/loop1
losetup /dev/loop2

Next, create a ext3 file system on the new image (in our case, associated with loop device /dev/loop2) as follows:

mke2fs -j /dev/loop2

Let’s create a couple of directories that will serve as temporary mount points for our image files. And then mount the images onto those temporary directories

mkdir orig
mkdir new

mount /dev/loop1 orig
mount /dev/loop2 new

Check the list of mounts by running the mount command without any arguments. You should see the above mount points in the listing. Something similar to the following:

Also, you can list the contents of the orig (original image) directory. You should see an entire linux file system.

We can now copy the contents of the original (centos.5-3.x86.img) image to the new image new_centos.5-3.x86.img) as follows:

(cd old; tar zcf - .) | (cd new; tar zxf -)

The above command will take a few minutes to complete. Once it is done you can list the contents of the new (new image) directory to confirm the copy worked ok.

Great we now have a new, bigger image new_centos.5-3.x86.img that we can now bundle, upload and register with Eucalyptus.

Before you proceed, make sure you clean up by un-mounting the images and detaching them from the loop devices

umount /dev/loop1
umount /dev/loop2

losetup -d /dev/loop1
losetup -d /dev/loop2

Bundle, Upload, Register

Now would be a good time to install Euca2ools if you haven’t done so already.

There are 3 steps to making an EMI available:

1. Bundling
2. Uploading
3. Registering

And since an EMI is made up for a kernel image, a ramdisk image and a hard disk image, we need to perform the above 3 steps on each of the kernel, ramdisk and hard disk image.

Eucalyptus Kernel Image

First, we bundle the kernel image using Euca2ools euca-bundle-image command as follows:

euca-bundle-image -i xen-kernel/vmlinuz-2.6.24-19-xen --kernel true --arch i386

where,
xen-kernel/vmlinuz-2.6.24-19-xen – is the path to the kernel image
i386 – is the architecture. In our case, 32-bit architecture
The other argument –kernel true tells the euca-bundle-image that this is a kernel image.

The above command packages the kernel image and generates a manifest.xml file under /tmp directory.

We will pass the full path to the manifest file as an argument to euca-upload-image to upload the image to Walrus:

euca-upload-bundle -b kernel-bucket -m /tmp/vmlinuz-2.6.24-19-xen.manifest.xml

where,
kernel-bucket – is the name of the bucket that the image (kernel image) will be stored under.
/tmp/vmlinuz-2.6.24-19-xen.manifest.xml – is the manifest.xml that was generated by the euca-bundle-image command

As you can see from the output, the kernel image was uploaded to kernel-bucket in Walrus. Note that you could replace kernel-bucket with a name of your choice.

Once we have uploaded the image, we need to register it so that it is available for use. We can do this using the euca-register command:

euca-register kernel-bucket/vmlinuz-2.6.24-19-xen.manifest.xml

where,
kernel-bucket/vmlinuz-2.6.24-19-xen.manifest.xml – is the path to the kernel image in walrus

The output of the euca-register command is an image id. We can use this image id when we bundle up the hard disk image or when we create an instance from a Eucalyptus machine image. The prefix of “eki” implies that the image is a kernel image, more specifically a Eucalyptus Kernel Image (EKI).

Verify that the EKI image is available by running euca2ools euca-describe-images command:

euca-describe-images

Eucalyptus Ramdisk Image

Bundle the ramdisk image as follows:

euca-bundle-image -i xen-kernel/initrd.img-2.6.24-19-xen --ramdisk true --arch i386

where,
xen-kernel/initrd.img-2.6.24-19-xen – is the path to the ramdisk image
i386 – is the architecture. In our case, 32-bit architecture
The other argument –ramdisk true specifies that this is a ramdisk image.

The above command packages the ramdisk image and generates a manifest.xml file in the /tmp directory.

Next, we pass the path to the manifest.xml file as an argument to the euca-upload-bundle command to upload the image to Walrus.

euca-upload-bundle -b ramdisk-bucket -m /tmp/initrd.img-2.6.24-19-xen.manifest.xml

where,
ramdisk-bucket – is the name of the bucket that the ramdisk image will be stored under.
/tmp/initrd.img-2.6.24-19-xen.manifest.xml – is the manifest.xml that was generated in the previous step

Next we register the image as follows:

euca-register ramdisk-bucket/initrd.img-2.6.24-19-xen.manifest.xml

The output of the above euca_register command is an image id. Again, we can use this image id when we bundle up the hard disk image or when we create an instance from a Eucalyptus machine image. The prefix “eri” implies that the image is a ramdisk image, more specifically a Eucalyptus Ramdisk Image (ERI).

Run the describe images command to verify that the ramdisk image is available:

euca-describe-images

Finally we are ready to create the Eucalyptus Machine Image.

Eucalyptus Machine Image

We will use the hard disk image – new_centos.5-3.x86.img – we created in the section “Resizing the disk image“. If you skipped the “resize” section, you could use the base image – centos.5-3.x86.img – provided in the download.

Let’s get started with first bundling the hard disk image as follows:

euca-bundle-image -i new_centos.5-3.x86.img --kernel eki-90461381 --ramdisk eri-E85914C7

where,
new_centos.5-3.x86.img – is the path to the hard disk image

The other two arguments to the above command are the Eucalyptus Kernel Image (EKI) id and the Eucalyptus Ramdisk Image (ERI) id. In this case, eki-90461381 and eri-E85914C7 which we obtained when registering the kernel and ramdisk image respectively.

As expected, the above command packages the disk image and generates a manifest.xml file in the /tmp directory.

Next, we upload the disk image to Walrus passing in the manifest.xml file path obtained from the previous command as follows:

euca-upload-bundle -b image-bucket -m /tmp/new_centos.5-3.x86.img.manifest.xml

where,
image-bucket – is the name of the bucket that the disk image will be stored under.
/tmp/new_centos.5-3.x86.img.manifest.xml – is the manifest.xml that was generated in the previous euca-bundle-image step

Finally, we register the image as follows:

euca-register image-bucket/new_centos.5-3.x86.img.manifest.xml

A quick euca-describe-images reveals the EMI that is available for use:

In the next post, we will look into creating instances of the EMI that we just registered.

• Installed Eucalyptus, an Infrastructure-as-a-Service offering, and
• Configured Eucalyptus to start VMs with IP addresses from a private VLAN

Before we jump into bundling, uploading, and registering images, let’s first download and install Euca2ools.

Euca2ools

Euca2ools are command-line utilities to help:

• Manage Images (bundle, upload, register, delete, etc.)
• Manage Instances (start, reboot, terminate, list, etc.)
• Manage Volumes & Snapshots (attach, detach, list, create, delete, etc.)
• Manage IP addresses (associate, disassociate, list, etc.)
• Manage SSH key pairs (add, delete, list)
• Manage Security groups (add, delete, list, add rules)
• Query availability zones (clusters)

Euca2ools is compatible with Amazon EC2 and S3 web services. In fact, Euca2ools is modeled after Amazon EC2 API and EC2 AMI tools.

Download & Install

Since I have been using CentOS 5 32-bit, I’ll describe the tar ball install process for CentOS 5. Also, in my case I’ll install euca2ools on my front-end machine (192.168.0.114)

Note: You may choose to go the yum (you will need to add the http://www.eucalyptussoftware.com/downloads/repo/euca2ools/$VERSION/yum/centos/ repo first) route instead of the tar ball.

Note: If you are using a Debian-based distro, feel free to install using apt-get (apt-get install euca2ools)

First download the tar.gz package for CentOS 5 32-bit – in this case, euca2ools-1.2-centos-i386.tar.gz

Next un-tar the above package

tar zxvf euca2ools-1.2-centos-i386.tar.gz

Before you install the rpm packages in the euca2ools-1.2-centos-i386 directory, you need to install swig as follows:

yum update
yum install swig

Next, go into euca2ools-1.2-centos-i386 directory and install the rpm packages as follows:

cd euca2ools-1.2-centos-i386
rpm -Uvh python25-2.5.1-bashton1.i386.rpm python25-libs-2.5.1-bashton1.i386.rpm euca2ools-1.2-1.i386.rpm

Confirm that euca2ools is install as follows:

rpm -qa euca2ools

Testing Euca2ools

In the first post I used Amazon EC2 API tools to test the Eucalyptus install. To be precise I had used the ec2-describe-availability-zones command.

Now that we have Euca2ools installed we can use the euca-describe-availability-zones command instead. Remember to source in the eucarc file first.

cd .euca
source eucarc
euca-describe-availability-zones verbose

Nice!

Feel free to play around with some of the other commands. You can get a list of commands by typing “euca” and pressing the TAB button twice. You could also run the command ls /usr/bin | grep euca

To get more information on a particular command, type in the command name following by the argument –help. For instance:

euca-describe-availability-zones --help

As we continue these series, we will see more and more of the Euca2ools commands.

In my previous post on setting up a private cloud, we looked at getting Eucalyptus “Infrastructure-as-a-Service” platform installed and running. If you recall, we stated to keep things simple but still practical enough such that you could use this as a reference guide to “Building and running a private cloud”. Hence in this post we will look at tweaking the default configuration – primarily changing the default out-of-the-box enabled networking to something similar to Amazon EC2.

Networking in Eucalyptus

Eucalyptus comes with 4 networking modes.

• SYSTEM
• STATIC
• MANAGED
• MANAGED-NOVLAN

SYSTEM networking mode

SYSTEM networking mode is the default “no-frills” networking that is offered as part of an out-of-the-box Eucalyptus install.
In this networking mode, Eucalyptus relies on the existence of a DHCP server (non-Eucalyptus controlled) located on the LAN. Virtual machines obtain their IP address from this DHCP server the same way other machines (such as your desktop, laptop, etc.) on the LAN do.
In this mode, you cannot set up create VLANs or isolate network traffic. There is only one IP address that gets assigned to the VMs i.e. the IP address obtained from the DHCP server setup by your administrator.
This mode is useful when you are just getting started with Eucalyptus. If you have only a single machine (server/laptop/desktop) to try out Eucalyptus, then SYSTEM (or STATIC) networking mode is the way to go.

As described in my previous post, I had setup Eucalyptus with 1 Cluster Controller (CC), 2 Node Controllers (NC) and SYSTEM networking mode. But we will tweak this to use MANAGED mode.

MANAGED networking mode

This mode almost resembles the networking setup of Amazon EC2 cloud in that you can define:

• a large private VLAN from which VMs can obtain IP addresses
• a pool of public IP addresses that can be assigned to VMs. Similar to Amazon’s elastic IP addresses
• define security groups where users can define ingress rules that apply to the VM that runs within that security group

In this mode, Eucalyptus maintains a DHCP server, fully manages the local VM instance network and provides all the networking features Eucalyptus currently supports.

Before we jump into configuring Eucalyptus for MANAGED networking there are some requirements that need to be met. Namely:

• Available range of IP addresses unused on the network. These IP addresses will be used to create private VLANs.
• Any switch ports that the Eucalyptus components are connected to allow and forward VLAN tagged packets
• There is either no firewall running on the Cluster Controller or the firewall is compatible with dynamic changes Eucalyptus will make to the front-end netfilter rules

Checklist #1: Available range of IP addresses for private VLAN

Before you start configuring Eucalyptus for MANAGED networking mode, you need to find a range of IP addresses that is unused on the network. We will configure Eucalyptus to use this range to create a private VLAN.

When Eucalyptus boots a virtual machine instance it will assign the instance a private IP address from this range. This is similar to the private IP address assigned to an instance running on Amazon EC2.

In my case, I have 10.10.0.0 – 10.10.255.255 unused as an example.

Checklist #2: Allow/forward VLAN tagged packets

Next we need to verify that the local network will allow/forward VLAN tagged packets between machines running Eucalyptus components.
To test this, we will create, on the front-end and Nodes, virtual ethernet devices assigned with an IP address from the above range of IP addresses. And then attempt to ping them.

Let’s start with the front-end. In my case, 192.168.0.114 if you have been following this series (see post on Setting up a private cloud using Eucalyptus for list of machines involved).

vconfig add eth0 10

where,
eth0 – is the value of the VNET_PRIVINTERFACE in my eucalyptus.conf on my front-end

We can verify we created a VLAN device on eth0 by checking /proc/net/vlan/config

cat /proc/net/vlan/config

We could also run the following command to verify that the VLAN device was created

ip a sh eth0.10

Next let’s pick an IP from the “Available range of IP addresses for private VLAN“, 10.10.0.0 – 10.10.255.255 (in my case). Let’s pick 10.10.1.2

ifconfig eth0.10 10.10.1.2 up

Let’s verify that the virtual ethernet device eth0.10 is up

ip a sh eth0.10

Excellent. Now let’s do the same on the Nodes with the exception that we will pick a different IP address, say 10.10.1.3 and 10.10.1.5 for each of my two Nodes, 192.168.0.19 and 192.168.5.7.

For the sake of brevity, I’ve detailed the steps on one of my Nodes.

vconfig add eth0 10

where,
eth0 – is the value of the VNET_PRIVINTERFACE (and VNET_PUBINTERFACE) in my eucalyptus.conf on my Nodes

Verify that the virtual ethernet device has been created on the Node:

cat /proc/net/vlan/config

Next assign the virtual ethernet device eth0.10 IP address 10.10.1.3 and bring it up

ifconfig eth0.10 10.10.1.3 up
ip a sh eth0.10

Now comes the test. From the above Node, let’s ping the front-end’s virtual ethernet device 10.10.1.2:

ping 10.10.1.2

Next, from the front-end machine, 192.168.0.114, let’s ping the Node’s virtual ethernet device, 10.10.1.3

ping 10.10.1.3

Super cool! This proves that my switch allows/forwards VLAN tagged packets. If for some reason, your results do not resemble mine, then your switch, perhaps, needs to be configured to allow/forward VLAN tagged packets. A little bit of googling on your switch may help.

For cleanup sake, you could go ahead and remove the above test vlan devices. You could do this as follows on the front-end and Node:

ip link set eth0.10 down
vconfig rem eth0.10

cat /proc/net/vlan/config

ip a sh eth0.10

Checklist #3: Firewall configuration on front-end

Finally in the list of things to check, we need to make sure the firewall on the front-end does not interfere with Eucalyptus which will dynamically update the nat and filter rules. In my case my iptables on the front-end reveal the following:

iptables -L

iptables -L -t nat

Ok. Now we are ready to proceed with the MANAGED networking configuration.

Front-end configuration – MANAGED networking mode

Presently to configure Eucalyptus networking, you need to edit eucalyptus.conf. In my installation, this file is located under /etc/eucalyptus.

All of the options that we plan on configuring are located under the “Networking options” section in eucalyptus.conf namely options starting with “VNET_”

We, first, start by configuring VNET_PRIVINTERFACE and VNET_PUBINTERFACE. VNET_PRIVINTERFACE should be set to the ethernet device that is attached to the same physical ethernet as the Nodes. In my case, eth0.

VNET_PRIVINTERFACE="eth0"

Next, if your front-end has a second ethernet device, say eth1, which is used to access the public network, you could configure VNET_PUBINTERFACE to this. In my case, I have only one ethernet device eth0. Therefore I set VNET_PUBINTERFACE to eth0

VNET_PUBINTERFACE="eth0"

Ignore the VNET_BRIDGE since it is only valid for the Nodes.

In MANAGED configuration, Eucalyptus maintains a DHCP server that it uses to dole out IP addresses to virtual machine instances. Therefore it needs the location of dhcp daemon. In my case this is /usr/sbin/dhcpd and in my CentOS OS it is configured to run as root user. Therefore I leave the VNET_DHCPUSER commented out since by default Eucalyptus will setup the DHCPD configuration files/directories to be owned by root user.

VNET_DHCPDAEMON="/usr/sbin/dhcpd"
#VNET_DHCPUSER="root"

If your DHCP daemon is set to run as a non-root user (for example, in Ubuntu it is set to run under dhcpd user), then un-comment VNET_DHCPUSER and update this value accordingly.

Next, comment out VNET_MODE=SYSTEM (out-of-the-box networking mode) since our objective is to use MANAGED networking.

So, let un-comment out the line VNET_MODE=”MANAGED”.

Next, let’s set the values for VNET_SUBNET and VNET_NETMASK. In my case, according to “Checklist #1: Available range of IP addresses for private VLAN“, we define these values as follows:

VNET_SUBNET="10.10.0.0"
VNET_NETMASK="255.255.0.0"

Update your values accordingly. This makes 65536 (256 * 256 = 65536) IP addresses available to Eucalyptus to assign as private IP addresses to virtual machine instances.

Next, I set the number of IP addresses allowed per network (security group per user) to 32 i.e. the option VNET_ADDRSPERNET:

VNET_ADDRSPERNET="32"

The setting above allows for 2048 (65536 / 32 = 2048) networks to be active simultaneously. Depending on your VNET_SUBNET, VNET_NETMASK, and VNET_ADDRSPERNET values, the number of concurrent active networks will be different that mine.

Also, in my case if I end up having, say, 100 users, then each user will have a maximum of 20 networks (2048 / 100 = 20.48) in operation at any given point in time.

Next, we set the VNET_DNS to the same DNS server used by my front-end machine. You can find your DNS server by looking in the /etc/resolv.conf file as follows:

cat /etc/resolv.conf

So I set VNET_DNS with:

VNET_DNS="192.168.0.2"

Next, you will want to assign public IP addresses to your instances – very much like Amazon EC2 instances. This gives users the ability to log into their instances from outside the cluster/front-end. But first you must find a set of public IP addresses that are not in use.

Note: Talk to your LAN administrator at this point to see if he can give you a bunch of IP addresses (a range will be great) that Eucalyptus can use to assign to instances at boot or dynamically at instance run time.

The public IP addresses you pick must be capable of being assigned to the front-end. In my case, I have 192.168.3.1 – 192.168.3.255 addresses available on my LAN network. I confirm that the IP addresses can be assigned to the front-end NIC eth0 as follows:
For example, for IP address 192.168.3.1

ip a add 192.168.3.1/32 dev eth0
ping 192.168.3.1

Perfect. I now configure VNET_PUBLICIPS as follows:

VNET_PUBLICIPS="192.168.3.1-192.168.3.31"

Note: I’ve deliberately, for no particular reason, configured the range to be only allow for 31 public IP addresses.

If you have individual IP addresses instead of range, then separate each IP address with a space.

Next, comes VNET_CLOUDIP and VNET_LOCALIP. Since my Cloud Controller and Cluster Controller are running on the same machine, 192.168.0.114, I leave VNET_CLOUDIP commented out.
Also, since I’m running a single Cluster Controller I leave VNET_LOCALIP commented out as well.

#VNET_LOCALIP="your-public-interface's-ip"
#VNET_CLOUDIP="your-cloud-controller's-ip"

If your installation has multiple Cluster Controllers, and you wish to specify the IP of the Cluster Controller that all other Cluster Controllers can reach, you can set VNET_LOCALIP to that Cluster Controller’s IP address.

That’s all with configuring Eucalyptus to use MANAGED networking mode on the front-end. To summarize my settings on the front-end are as follows:

VNET_PUBINTERFACE="eth0"
VNET_PRIVINTERFACE="eth0"
...
...
VNET_DHCPDAEMON="/usr/sbin/dhcpd"
#VNET_DHCPUSER="root"
...
...
VNET_MODE="MANAGED"
VNET_SUBNET="10.10.0.0"
VNET_NETMASK="255.255.0.0"
VNET_DNS="192.168.0.2"
VNET_ADDRSPERNET="32"
VNET_PUBLICIPS="192.168.3.1-192.168.3.31"
#VNET_LOCALIP="your-public-interface's-ip"
#VNET_CLOUDIP="your-cloud-controller's-ip"
...
...
#VNET_MODE="SYSTEM"

Node configuration – MANAGED networking mode

Next, we need to configure the Nodes for MANAGED networking mode. In my case, my Nodes are 192.168.0.19 and 192.168.5.7.

Again, all the options that we plan on configuring are located under the “Networking options” section in eucalyptus.conf. We are mainly concerned with options VNET_PRIVINTERFACE, VNET_PUBINTERFACE, and VNET_MODE.

Let’s start with VNET_PRIVINTERFACE and VNET_PUBINTERFACE. Both these options should be set to the ethernet device that is attached to the same physical ethernet as the Cluster Controller. In my case, eth0.

VNET_PUBINTERFACE="eth0"
VNET_PRIVINTERFACE="eth0"

We also un-comment the line VNET_MODE=”MANAGED” and comment VNET_MODE=”SYSTEM”

That’s all with configuring Eucalyptus to use MANAGED networking mode on the Nodes. To summarize my settings on the Nodes are as follows:

VNET_PUBINTERFACE="eth0"
VNET_PRIVINTERFACE="eth0"
...
...
VNET_MODE="MANAGED"
#VNET_MODE="SYSTEM"

Now we are ready to restart Eucalyptus on both front-end and Nodes.

Restart Eucalyptus with MANAGED networking mode

On the front-end, first do a “clean” start of the Cluster Controller as follows:

/etc/init.d/eucalyptus-cc cleanstart

Note: A clean start of the Cluster Controller is necessary when you update any Eucalyptus settings for the changes to take effect.

Next, start the Cloud Controller:

/etc/init.d/eucalyptus-cloud start

Verify that Eucalyptus (Cloud Controller, Cluster Controller) is started on the front-end:

ps auxww | grep euca | grep -v euca

Moving on to the Nodes, start the Node Controllers as follows:

/etc/init.d/eucalyptus-nc start

Verify that Eucalyptus (Node Controller) is started on the Nodes:

ps auxww | grep euca | grep -v euca

Testing our Eucalyptus MANAGED networking

Recall in our post on Setting up a private cloud using Eucalyptus, we had installed the Amazon EC2 API Tools. Let’s run a few commands to test Eucalyptus MANAGED networking, especially some of the settings such as the public IP addresses that we set in the Eucalyptus configuration on the front-end:

ec2-describe-availability-zones verbose

You will notice in the above output that it seems like I have some instances running – free < max. Infact I did start an instance (using ec2-run-instances command) so we could see MANAGED networking in action.

ec2-describe-instances

As you can see my instance i-4BAA0834 has a public IP address of 192.168.3.1 and a private IP address of 10.10.1.2.

When Eucalyptus booted up my instance it assigned the instance 192.168.3.1 from the list of public IP addresses (see VNET_PUBLICIPS in section Front-end configuration – MANAGED networking mode). Eucalyptus also assigned the instance a private IP address 10.10.1.2 from the range of unused IP addresses (see VNET_SUBNET in section Front-end configuration – MANAGED networking mode).

Also, if you run ec2-describe-addresses you will see the public IP addresses (VNET_PUBLICIPS) that are in use and available.

ec2-describe-addresses

So now when Eucalyptus boots up instances, the instances will be assigned a private address and a public address, similar to Amazon EC2 instances.

So you are now running a Amazon EC2-like cloud in your datacenter using Eucalyptus!

In up-coming posts in this series of “Building a private Cloud”, we will look how to bundle/register images, run instances, and more importantly how Platform-as-a-Service complements Infrastructure-as-a-Service.

For the sake of keeping things simple but still practical enough, we will have:

• 1 front-end machine. This will house the Cloud Controller (CLC) and Walrus. Since we intend to keep things fairly simple we will limit ourselves to a single cluster and setup the Cluster Controller (CC) and Storage Controller (SC) on this same machine. In my case, this machine has one network interface (NIC) with an IP address of 192.168.0.114.
• 2 machines (Nodes) that will serve as hosts running Xen hypervisor for the virtual machines i.e. each machine will have a Node Controller (NC) installed. In my case, each machine has a single NIC and the IP addresses are 192.168.0.19 and 192.168.5.7 respectively.

Before we install Eucalyptus we need to first prep these machines.

Note: For the rest of this document, run the commands as root user.

This document is organized as below. Feel free to skip any sections if you have already implemented the steps in that section.

Prep work

On the front-end machine, we first install Java and Ant. You can download Sun JDK from here and Ant from here . I’m using JDK version 1.6u20 (jdk-6u20-linux-i586-rpm.bin) and Ant version 1.8.0 (apache-ant-1.8.0-bin.tar.gz).

Once you have downloaded Sun JDK to a directory, install it as follows:

chmod +x jdk-6u20-linux-i586-rpm.bin
./jdk-6u20-linux-i586-rpm.bin

You can confirm that java is on the PATH by running the following command:

java -version

You should output similar to:

Next, install Ant under /opt directory as follows:

cd /opt
mkdir ant
cd ant
tar zxvf ~/apache-ant-1.8.0-bin.tar.gz
ln -s apache-ant-1.8.0 latest

Next, we need to add an environment variable ANT_HOME that points to /opt/ant/latest and append the $ANT_HOME/bin to the PATH environment variable. Add this to the /etc/profile file as follows:

cd /etc
cp profile profile.ORIG
echo "export ANT_HOME=/opt/ant/latest" >> profile
echo "export PATH=\$PATH:\$ANT_HOME/bin" >> profile

Next we need to install a few dependencies (dhcp, bridge-utils, httpd, xen-libs, ntp) and synchronize the system clock on the front-end machine. You can do this as follows:

yum update
yum install dhcp xen-libs httpd bridge-utils ntp
ntpdate pool.ntp.org

I have the following versions installed:

yum list dhcp xen-libs httpd bridge-utils

We also allow the front-end machine to forward IP packets as follows:

cd /etc
cp sysctl.conf sysctl.conf.ORIG
sed -i "s/net.ipv4.ip_forward = 0/net.ipv4.ip_forward = 1/" sysctl.conf

To change this value immediately without rebooting, run the following command:

sysctl -p /etc/sysctl.conf

Next, we need to configure firewall rules to permit the various Eucalyptus communicate with each other. Since we are planning on using security groups in Eucalyptus, let’s start with disabling SELinux on the front-end machine as follows:

cd /etc/selinux
cp config config.ORIG
sed -i "s/SELINUX=permissive/SELINUX=disabled/" config

Let’s reboot the front-end machine at this point.

Next, we need to prep the two Nodes. We start by installing xen hypervisor and also synchronize the system clock on each Node as follows:

yum update
yum install xen ntp
ntpdate pool.ntp.org

I have the following versions of xen installed:

yum list xen

Once we have Xen installed we need to configure it to allow for the hypervisor to be controlled via HTTP from localhost. We can do this by editing /etc/xen/xend-config.sxp file and then restart xen daemon as follows:

cd /etc/xen
cp xend-config.sxp xend-config.sxp.ORIG
sed -i "s/#(xend-http-server no)/(xend-http-server yes)/" xend-config.sxp
sed -i "s/#(xend-address localhost)/(xend-address localhost)/" xend-config.sxp
/etc/init.d/xend restart

Next we need to make sure the correct kernel with xen enabled is started at boot. We do this by editing the GRUB configuration file (grub.conf) under /boot/grub. If grub.conf is not available, then edit menu.lst which should be a file instead of a symlink to grub.conf.
In my case, /boot/grub/grub.conf is:

The default line is the line we want to change. The first title is 0. Since we want title CentOS (2.6.18-164.15.1.el5xen) to be the default kernel we would set default to 0.
We can do this as follows:

cd /boot/grub
cp grub.conf grub.conf.ORIG
sed -i "default=1/default=0/" grub.conf

Next, we disable SELinux on the Node machines as follows:

cd /etc/selinux
cp config config.ORIG
sed -i "s/SELINUX=permissive/SELINUX=disabled/" config

Let’s reboot both Node machines at this point. We are not ready to proceed with the installation of Eucalyptus.

Download Eucalyptus

You could choose to install Eucalyptus via yum if needed which is easier that
You can downloaded Eucalyptus from here. I picked the 32-bit CentOS 5 rpms that come bundled in a gzip compressed tar file.

Note: Different Eucalyptus components need to be installed on the front-end and each of the Node machines. The aforementioned tar.gz file contains all Eucalyptus components though. Therefore download it once on the front-end and then copy this file over to each of the Node machines.

Install Eucalyptus on the front-end

Once you have downloaded Eucalyptus (in my case, eucalyptus-1.6.2-centos-i386.tar.gz) on the front-end, untar it to root’s home folder /root.

tar zxvf eucalyptus-1.6.2-centos-i386.tar.gz
cd eucalyptus-1.6.2-centos-i386

We are ready to install. Let’s start by installing the 3rd-party dependency RPMs included in the eucalyptus-1.6.2-rpm-deps-i386 directory. Install all the rpms in this directory as follows:

cd eucalyptus-1.6.2-rpm-deps-i386
rpm -Uvh aoetools-21-1.el4.i386.rpm euca-axis2c-1.6.0-1.i386.rpm euca-rampartc-1.3.0-1.i386.rpm vblade-14-1mdv2008.1.i586.rpm groovy-1.6.5-1.noarch.rpm vtun-3.0.2-1.el5.rf.i386.rpm lzo2-2.02-3.el5.rf.i386.rpm
cd ..

Note the above “rpm -Uvh…” command might fail with an error about “Failed dependencies…java-sdk > 1.6.0 is needed….“. To get past this error, run the above rpm -Uvh… with –nodeps. The error is because it is trying to look for Openjdk during installation. But we have installed Sun Java instead. Adding –nodeps will get us past this error message. Don’t worry, the Eucalyptus components will start up fine when the time comes to run them.

Next, let’s install the Cloud Controller, Walrus, Cluster Controller, Storage Controller, and a few other dependencies on the front-end machine as follows:

rpm -Uvh eucalyptus-1.6.2-1.i386.rpm eucalyptus-common-java-1.6.2-1.i386.rpm eucalyptus-cloud-1.6.2-1.i386.rpm eucalyptus-walrus-1.6.2-1.i386.rpm eucalyptus-sc-1.6.2-1.i386.rpm eucalyptus-cc-1.6.2-1.i386.rpm eucalyptus-gl-1.6.2-1.i386.rpm

Now let’s move on the installing Eucalyptus components on the Node.

Install Eucalyptus on the Nodes

First, copy (or download) the Eucalyptus tar.gz file on each Node. Untar it to root’s home folder /root.

Note: The steps in this section need to be performed on each Node (in my case on each of the two Nodes).

Let’s begin by installing a few 3rd-party dependency RPMs.

tar zxvf eucalyptus-1.6.2-centos-i386.tar.gz
cd eucalyptus-1.6.2-centos-i386
cd eucalyptus-1.6.2-rpm-deps-i386
rpm -Uvh aoetools-21-1.el4.i386.rpm euca-axis2c-1.6.0-1.i386.rpm euca-rampartc-1.3.0-1.i386.rpm
cd ..

Next, we install the Node Controller (and a couple of dependencies) on each Node as follows:

rpm -Uvh eucalyptus-1.6.2-1.i386.rpm eucalyptus-gl-1.6.2-1.i386.rpm eucalyptus-nc-1.6.2-1.i386.rpm

Next, confirm that the user eucalyptus can connect with the hypervisor through libvirt.

su eucalyptus -c "virsh list"

The output of the above command should look something like:

Note: If you don’t have libvirt installed/running on the Nodes, you could install it: yum install libvirt

That’s it with the installation!

Running Eucalyptus

You are now ready to start Eucalyptus up.

SSH to the front-end machine and start the Cluster Controller and Cloud Controller as follows:

/etc/init.d/eucalyptus-cc start
/etc/init.d/eucalyptus-cloud start

Run ps command to confirm Eucalyptus is running on the front-end:

ps auxww | grep euca

Next, SSH to each Node and start Node Controller as follows:

/etc/init.d/eucalyptus-nc start

Confirm eucalyptus is running on the Nodes:

ps auxww | grep euca

Registering Eucalyptus components

Now that you have started all components, you will need to register them so that they can talk to each other.

SSH to the front-end machine (in my case, 192.168.0.114) and run the following commands:

euca_conf --register-walrus 192.168.0.114
euca_conf --register-cluster rosh-cluster1 192.168.0.114
euca_conf --register-sc rosh-cluster1 192.168.0.114

where,
192.168.0.114 – is the IP address of my front-end machine which has CLC, Walrus, CC and SC installed/running. Replace this with the IP address of your front-end machine in all the above commands.
rosh-cluster1 – is the cluster name that I used. Replace it with your own cluster name.

Next, we need to register the 2 Nodes. On the front-end machine, run the following command:

euca_conf --register-nodes "192.168.0.19 192.168.5.7"

where,
192.168.0.19, 192.168.5.7 – are the 2 Nodes in my case. Replace the above IP addresses with the IP addresses of your Nodes. Add additional Nodes separated with a space.

You can verify that the nodes are registered by verifying that value of the NODES element in the eucalyptus.conf file on the front-end reflects the node IP addresses added via the above euca_conf –register-nodes command. In my case:

grep NODES /etc/eucalyptus/eucalyptus.conf

We are done with registering the Eucalyptus components.

First-time Configuration

We are now ready to perform some quick configuration.

Using a browser, browse to https://<front-end-ip-address>:8443. In my case, https://192.168.0.114:8443. You will get a warning page stating that the “site’s security certificate is not trusted“. Since Eucalyptus is using a self-signed certificate which is not verified by a third-party that the browser trusts, shows you this warning. Accept the certificate and you will be prompted for a user_id/password. Enter admin for both.

Once you have logged in for the first time, you will be asked to change the password, set the admin email address, etc. Enter the relevant details and hit “Submit”.

On the “Configuration” web page you will see Cloud Configuration, Walrus Configuration, Clusters, etc. These should all be pre-populated. You could make changes to the configurations if you wish. I left these unchanged for now.

Next, browse to “Credentials” web page and click the “Download Credentials” zip file. Save the “euca2-admin-x509.zip” to a directory. You will need these credentials when you use client tools such as euca2ools to manage virtual machines, images, etc.
Create a .euca folder and unzip the contents of this file in this folder. Run the following command from under .euca folder:

unzip euca2-admin-x509.zip

Once you have unzipped the contents, you will find a .eucarc file that exports some variables. The EC2_URL in this case will point to your front-end machine. In my case, 192.168.0.114.

cat .eucarc

Before you run any client tools, you will need to source this file.

Testing our Eucalyptus install

To keep things simple and quickly test our Eucalyptus installation, download Amazon EC2 API Tools. Unzip the downloaded ec2-api-tools.zip to under the .euca folder that you created in the “First-time Configuration” section.

unzip ec2-api-tools.zip

Next source the .eucarc file under and run the ec2-describe-availability-zones command provided by the ec2-api-tools. From under .euca folder run the following commands:

cd .euca
source .eucarc
cd ec2-api-tools-1.3-46266/bin
ec2-describe-availability-zones verbose

You should see output similar to the following:

where,
rosh-cluster1 – is the cluster I registered using euca_conf and in my case, it corresponds to the Cluster Controller running on my front-end machine (192.168.0.114)

If you see something like the above, give yourself a pat on the back!

You are now ready to bundle images and create instances from those images on your own private infrastructure cloud!

Related Articles:
Configuring your private cloud

Update fabric/far version
The update fabric/far version goal of the Appistry CloudIQ Maven plugin automates the version update of the fabric/far artifact and integrates this process into the Maven build life-cycle of the CloudIQ artifact.

During development or build/run/test cycle, the process of manually having to update the version of the fabric/far becomes painful real quick. And heaven forbid that your forget to update the version and attempt a deploy – Appistry CloudIQ rejects the artifact with a nasty message stating that the version that you are attempting to deploy is older than the version it has currently.

The cloudiq:update-far-version goal alleviates the above problem by automating the update of the version value.

Usage
To update the version of the fabric/far application, run this goal as:

mvn cloudiq:update-far-version

Assuming you have configured the Appistry CloudIQ Maven plugin as follows in your project pom:

<build>
    <plugins>
        <plugin>
		<groupId>com.appistry.maven.plugins</groupId>
		<artifactId>maven-cloudiq-plugin</artifactId>
		<version>0.0.1-SNAPSHOT</version>
		<configuration>
			<appName>CreditRules_App</appName>
			<appFilename>CreditRules_App</appFilename>
			<remoteSshHost>192.168.5.55</remoteSshHost>
			<remoteSshPort>22</remoteSshPort>
			<remoteSshUsername>fabricuser</remoteSshUsername>
			<remoteSshPassword>fabricuser</remoteSshPassword>
			<!--
				<farVersionUpdateSkip>false</farVersionUpdateSkip>
				<farVersion>99</farVersion>
			-->
		</configuration>
	</plugin>
</plugins>
</build>

the mvn package cloudiq:update-far-version command will update (increment by 1) the version value in the fabric/far application descriptor (in this case, CreditRules_App.xml). Currently the only requirement is that the version defined in the application descriptor is an integer. We will talk a little more about this requirement a little later.

Note: This goal (cloudiq:update-far-version) is part of the cloudiq:package goal which essentially performs the following:

1. copies the resources/scripts files (cloudiq:copy-resources goal) to a work directory,
2. updates the version of the fabric/far application descriptor (cloudiq:update-far-version goal),
3. gathers the dependent (if any) jars (cloudiq:assemble-dependencies goal), and
4. runs fabric_pkg to create the actual fabric/far artifact.

99.99% of the time you will run the cloudiq:package goal which as described above will update the version and package the app as a deployable CloudIQ artifact.

Configuration
The cloudiq:update-far-version goal does not need any configuration since all it does is read the existing version and increment it. But there are some configuration parameters around this goal that come in handy when needed.

farVersionUpdateSkip
Setting this parameter to true will skip the execution of the cloudiq:update-far-version goal. This comes in handy if you want to update the version by hand or using some other process. The default is false i.e. the version gets updated when either cloudiq:package goal or cloudiq:update-far-version goal is run.

farVersion
This parameter allows you to specify a version that will be used and hence overrides the default behavior of the cloudiq:update-far-version goal which is to increment the version by 1.
This parameter takes a string as it value. That’s right, a String rather than an integer. So you could set it to a value like “1.0″ or “5.0.2″.
I generally use this parameter when I tag my build in my source control management (SCM) and then use the tag value as the version. Of course, the version (SCM tag) is higher than the version deployed (which generally is an older SCM tag). This helps in co-relating what the version deployed to the version tagged in SCM.

Best Practices
Recall, a little above I stated that one of the requirements is that the version defined in the application descriptor is an integer. But then in the farVersion property I contradicted it by saying that you could pass in a string.
Well, let’s clear this up.

Development environment/cloud
Generally during development, you are building from HEAD (or TRUNK or MAIN branch) of your SCM and deploying to a development cloud. And during development you frequently build, deploy and test your changes. During this time, you don’t really care what the version is of the fabric/far as long as it is greater than the existing one so you can deploy it without Appistry CloudIQ baulking at your deploy attempts. Therefore during this time the “increment by 1″ strategy comes in handy. Hence it is a good practice to:

• Set the initial version in the fabric/far application descriptor to an integer, say 1
• Do not specify a farVersion property

and let the plugin do the job of updating the version every time you build.

Test or QA or Production environment/cloud
Once you are ready to deploy to a test/QA/production cloud, tag your code in SCM and use the tag as the value of the farVersion property. This way you know what version of code is deployed in your test/qa/production environments and you can reproduce those artifacts at will.

The source and jars are hosted here.

Goals
The Java bindings around CloudIQ APIs can be used to:

• manage public/private clouds (Appistry CloudIQ clouds) from within Java apps
• deploy fabric, far and resource files to clouds
• push / get / delete / move files to and from CloudIQ Storage and administer CloudIQ Storage workers

See the FAQ for more usage and additional info.

Please use and contribute (feedback, feature request, bug fixes, etc.) to the development of these Java wrappers.

Origins…

maven-cloudiq-plugin currently started off as a simple way to integrate the creation of CloudIQ artifacts (fabric and far files) while building a Maven project on the Mac OS. As you may know, you create CloudIQ artifacts using fabric_pkg tool.

But, currently, there is no fabric_pkg for the Mac OS X. Therefore to create a fabric or far file you end up having to do the following:

1. SCP all your files – fabric/far resources, primary artifact (jar, war, etc.), dependent libraries, scripts, etc. – to a remote host that has Appistry CloudIQ installed
2. SSH to the above remote host and run fabric_pkg to create the fabric or far artifact
3. Deploy the fabric / far artifact to the cloud

Too time-consuming in my opinion! And you end up repeating these steps over and over again. DRY principle, anyone?

Heck if you are developing (on Windows or Linux) a Java application, installation package or service that get packaged as a Fabric or Far file and are using Maven as a build tool, to create the actual fabric or far file, you have to manually run fabric_pkg. Still a pain.

Since I use Maven a heck lot, I had to eliminate some of the repeated tasks. And thus the maven-cloudiq-plugin came forth. The primary objective of which was to integrate and make easy the building of CloudIQ artifacts while building a Maven project.

Looking forward…

Enough with the origins. What can we expect moving forward?

Although I won’t go into every single enhancement or new feature here (I haven’t thought about everything; that’s where you could contribute), I will list out some of the pressing issues that would greatly improve the usability of the plugin.

Some enhancements and features:

1. Auto-increment the fabric or far version in the application descriptors by looking up the latest version running in the cloud. Also, allow for manual override by user. Currently, the user has to update the application descriptors manually.
2. Auto-creation of Fabric and Far application descriptors. Currently, the user has to create these application descriptors by hand.
3. Auto-discover the appropriate CloudIQ artifact (.fabric or .far) that needs to be generated. Currently, the default is fabric. This is configurable though via the appExtension parameter.
4. Ability to deploy CloudIQ artifacts (and files) to clouds.
5. Ability to specify the list of dependent jars required at fabric package time. Currently, the entire kitchen sink of Maven dependencies get downloaded even though only a handful of jars gets included in the fabric file
6. Capture remote fabric_pkg output & error stream and log it out to the standard output during the Maven build.

So, above are some features/enhancements that need working on along with unit tests.

Interested enough to contribute?

If you are interested in contributing to the enhancements, features, and bug-fixes and making the maven-cloudiq-plugin robust and easy to use, feel free to clone the repository, send/attach code snippets, add additional enhancement/feature requests, etc.

Google Code and Mercurial
While I did not spend a ton of time evaluating a public project hosting provider, some of key things I was looking for in a project hosting provider was:

• Must provide DVCS (distributed version control system)
• Must provider some type of issue tracking system

Although GitHub and BitBucket seemed to fit the bill, I decided to go with Google code since it offers Mercurial DVCS (and Subversion as well). Mercurial (hg), IMHO, is faster and easier to learn than other DVCS. Again, this is purely my opinion.

Eclipse IDE has a nice plugin for hg. And NetBeans comes with support for hg out of the box.

How to contribute
If you are reading this post, I would encourage you to contribute to the development of maven-cloudiq-plugin. You can do so easily by cloning the project, fixing bugs, developing new features, requesting new features, and so on.

What is the purpose of the Appistry CloudIQ Maven plugin? See here

Note: These instructions should work with other Debian flavors as well.

Download Appistry-CloudIQ
Download the rpm package for Appistry-CloudIQ from the Community site. The free Community edition is great to start building a small enterprise cloud on-premise. For the purpose of this post, I’m Appistry-CloudIQ Platform 4.2 Community edition for RHEL 5.x, x86 32-bit version.

After you have downloaded, you should see something like this:

Create .deb package
Once you have the package downloaded, use alien to convert the rpm to a .deb package using the commands below. The package alien allows you to convert rpm packages to debian packages and then install them via dpkg. See how-to install alienhow-to.

Convert the rpm package to the debian package using the following command:

roshan@ubuntuWorkerB:~$ sudo alien -kc appistry-cloudiq-4.2.1.2-rhel5.rpm

Install the .deb pacakge
Now that you have the .deb package, install it using dpkg.

roshan@ubuntuWorkerB:~$ sudo dpkg -i appistry-cloudiq_4.2.1.2-rhel5_i386.deb

The install fails to create the user “fabricuser”. So let’s create it and add it to group “fabricuser”.

roshan@ubuntuWorkerB:~$ sudo useradd -s /bin/bash -g fabricuser fabricuser

You can confirm that the user was created by running the following command:

roshan@ubuntuWorkerB:~$ cat /etc/passwd | grep fabricuser

Change ownership of /usr/local/appistry/cloudiq to fabricuser
Change ownership of the /usr/local/appistry/cloudiq directory recursively to fabricuser using the following command:

roshan@ubuntuWorkerB:~$ sudo chown -R fabricuser:fabricuser /usr/local/appistry/cloudiq

Update scripts and create /bin/arch script
First, update the start-up scripts – fabric_keeper and fabric_system_service to explicitly use the /bin/bash interpreter. These two scripts are located under /etc/init.d directory.

roshan@ubuntuWorkerB:~$ sudo sed -ie 's/\/bin\/sh/\/bin\/bash/g' /etc/init.d/fabric_system_service
roshan@ubuntuWorkerB:~$ sudo sed -ie 's/\/bin\/sh/\/bin\/bash/g' /etc/init.d/fabric_keeper

The reason for doing this is because of the bashisms that exist in the two scripts.

Next, we need to create an executable script arch under the /bin directory.

roshan@ubuntuWorkerB:~$ echo "uname -m" > arch
roshan@ubuntuWorkerB:~$ sudo mv arch /bin/.; sudo chmod +x /bin/arch

The reason for doing this is because the start-up scripts source in /etc/fabric_env references /bin/arch which does not exist in Ubuntu since version 7.10. This causes the start-up scripts to fail. See https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/148511 for more information.

Set up symlinks for libssl.so.6 and libcrypto.so.6 shared libraries
Since the start up scripts attempt to load the libssl.so.6 and libcrypto.so.6 shared libraries, create symlinks with these names under /usr/lib directory.

roshan@ubuntuWorkerB:/usr/lib$ sudo ln -s libssl.so.0.9.8 libssl.so.6
roshan@ubuntuWorkerB:/usr/lib$ sudo ln -s libcrypto.so.0.9.8 libcrypto.so.6

If you do not create the above symlinks you will get errors like:

and

Set up init script links to start Appistry CloudIQ at boot
Next, we need to set up init scripts links to have Appistry CloudIQ start up at boot. We do this as follows:

roshan@ubuntuWorkerB:~$ sudo update-rc.d fabric_system_service start 99 2 3 4 5 . stop 01 0 1 6 .
roshan@ubuntuWorkerB:~$ sudo update-rc.d fabric_keeper start 99 2 3 4 5 . stop 01 0 1 6 .

Reboot to start Appistry CloudIQ
Reboot Ubuntu. You should see the following messages when Ubuntu is restarting.

Also, start log_monitor. You should see heartbeat messages.

roshan@ubuntuWorkerB:~$ . /etc/fabric_env
roshan@ubuntuWorkerB:~$ log_monitor 239.255.0.1

You now have the world’s best cloud platform – Appistry CloudIQ – running on Ubuntu.

In future posts, we will see how to create/migrate/manage infrastructure and applications to the “cloud” using Appistry CloudIQ

Downloads
Download the following script and place it alongside the appistry-cloudiq-X.x.rpm that you downloaded from the Appistry Community website.

cloudiq-ubuntu-install.sh

Next, run the script as follows:

roshan@ubuntuWorkerB:~$ sudo sh cloudiq-ubuntu-install.sh appistry-cloudiq-4.2.1.2-rhel5.rpm

where, appistry-cloudiq-4.2.1.2-rhel5.rpm is the version that I downloaded.