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

CloudIQ Storage exposes a RESTful interface that clients can use to store and retrieve files. Using cURL you can be on your way to PUTing and GETing files to CloudIQ Storage or any RESTful server that accepts files. This post is a follow-up to the REST-esting with cURL.

The following are basic curl commands to test PUT/GET of files

PUT a file

curl -i -u fabric-admin:fabric-admin -X PUT -T "test" http://192.168.0.165:16088/files/test

where,
i – show response headers
u – server authentication information, in the form of user:password
X – pass a HTTP method name
T – name of file to upload
The above command PUTs test file.

Optionally, you can leave out the file part in the URL, ending the URL with a trailing slash. cURL will append the local file name in this case. Note that you must use a trailing slash (/) on the last directory to tell cURL to use the file name as specified in the -T argument or cURL will use your last directory name as the remote file name to use.

curl -i -u fabric-admin:fabric-admin -X PUT -T "test" http://192.168.0.165:16088/files/

The above command transfers test file to http://192.168.0.165:16088/files/.

PUT multiple files in single command

You can PUT multiple files via a single command by enclosing them within braces as shown below:

curl -i -u fabric-admin:fabric-admin -X PUT -T "{test4,test5}" http://192.168.0.165:16088/files/

The above command transfers files test4 and test5 to http://192.168.0.165:16088/files/.

If you have many files with the almost the same name but differentiated from each other by a number (say, test4, test5, test6, test7), you could use an alternative to the above command to transfer all these files in one cURL command:

curl -i -u fabric-admin:fabric-admin -X PUT -T "test[4-6]" http://192.168.0.165:16088/files/

GET a file

curl -u fabric-admin:fabric-admin -O http://192.168.0.165:16088/files/test4

where,
O – use the remote file name for the local file
The above command GETs the contents of file test4 from remote location http://192.168.0.165:16088/files/test4 and writes the output to local file named like the remote file (in this case, test4).

If you want to store the contents in a local file with a name different from the remote file name, you could use the -o option:

curl -u fabric-admin:fabric-admin -o test10 http://192.168.0.165:16088/files/test4

The above command GETs the contents of file test4 from remote location http://192.168.0.165:16088/files/test4 and writes the output to local file test10.

Get HEADers
There are times when you just need the headers for a file. You could retrieve the headers for a file by running the following command:

curl -I -u fabric-admin:fabric-admin http://192.168.0.165:16088/files/test4

where,
I – fetches the HTTP headers only
The above command will display the HTTP headers returned by http://192.168.0.165:16088/files/test4

If you want to capture the file contents and the HTTP headers at the same time, you can use the -D option:

curl -u fabric-admin:fabric-admin -D "test4-headers" -O http://192.168.0.165:16088/files/test4

The above command GETs the contents of file test4 from remote location http://192.168.0.165:16088/files/test4 and at the same time outputs the HTTP headers to file test4-headers

For more examples using cURL for testing web services, see here.

I generally categorize my projects into multiple Eclipse workspaces and at times like having them open at the same time. In Windows/Linux OSes, this is a no-brainer – just click on the shortcut and this will start up a new process. But in Mac OS X, clicking on the Eclipse launcher in the taskbar just brought the existing Eclipse process into the foreground.

Finally I found out that I could accomplish what I wanted with the open command. Add it to a script as shown below and bingo, starting up multiple Eclipse workspaces is a piece of cake.

#!/bin/bash

ECLIPSE_HOME=~/tools/editors/eclipse35-JEE-x86_64/eclipse
open -n $ECLIPSE_HOME/Eclipse.App

Pete Koomen, the product manager for Google App Engine showed interested in the CloudIQ Engine piece of CloudIQ especially given that Goople App Engine is one of the key players in the Cloud Platform area – Hosted Cloud Platforms or PaaS, to be precise.
Some folks were interested in whether CloudIQ supports scaling out .NET components. While some asked if C, C++ code was supported. Yes and Yes.

I’m glad I used Sun’s VirtualBox to provision VMs installed with only CloudIQ and the sample application for the demo. I call it the cloud-in-a-box. Also it doesn’t hurt when VirtualBox is part of Sun Cloud.
Anyway, one of the slides in the presentation was that

CloudIQ complements Virtualization

And here is how you can do this with VirtualBox:

1. Use VirtualBox (or Sun Cloud when it is released this summer) to provision VMs with an OS and CloudIQ installed
2. Use CloudIQ Manager to provision and manage applications and middleware such as Tomcat, GlassFish, JBoss, etc.
3. And once you are comfortable with this setup, deploy (”touchless” or otherwise) your compute intensive code to CloudIQ Engine to achieve linear scalability and reliability at the component level

I will blog about my experience with VirtualBox and running Appistry CloudIQ platform on Ubuntu VMs soon. And when Sun’s cloud offering is released, I will tweak it to use Sun’s Cloud APIs. But if you cannot wait until then, sign up for the Appistry CloudIQ 4.0 beta program or download the community edition of Appistry CloudIQ from here and start creating your very own cloud-in-a-box now!

Back to the session, I do wish I had time for Q&A. My boss had warned me about that when he gave me feedback about my presentation slides. What I’m thinking is that people must have been hungry since my session was just before lunch-break and the guy waving the “time-remaining” sign pitied the crowd and decided to cut my session short by 5 minutes. Kidding!

Anyway great crowd, good times.

I attended the Birds-of-a-feather talk hosted by Tim Bray, Craig McClanahan and Lew Tucker where they presented the APIs and answered questions. Both Tim and Craig and their team have done an excellent job of coming up with these APIs that adhere so well to the REST principles. Kudos! Tim has blogged about the Sun Cloud APIs here. And so has Craig here.

During the session, one of the questions was

how do you upgrade middleware or applications or framework libraries (say, Hiberate) used by applications that are deployed in the cloud?

Answer: Use Cloud Application Platforms such as Appistry’s CloudIQ.

In my humble opinion, it would be great if the folks at Project Kenai designed the APIs with extensibility in mind to support Cloud Application Platform APIs such as Appistry’s CloudIQ APIs (which are also REST based) to deploy, install, update, uninstall applications and middleware. I say this because infrastructure level APIs are limiting.

With infrastructure level APIs you could create a VM, clone it with application servers/applications installed and go live. But what happens when you want to deploy a new version of say, GlassFish (perhaps with some critical updates) to your existing production cloud? Now suddenly you are back to home-grown scripting or creating additional VMs with the new updates. Now take it to the next level where you have to create and manage these scripts for various OS’s. Ewwwwww!

The solution is to use CloudIQ which abstracts out the virtual machines. Using CloudIQ you could easily deploy the new version of GlassFish to your existing production cloud without resorting to crazy, complex scripts. Save the time from creating additional VMs for every update and spend that time focusing on your business!

Another great example to drive home the importance of CloudIQ in the Cloud Computing arena:
Assume you are using Hibernate 2.x in a couple of your several web applications running on Tomcat in your production cloud. And now you want to upgrade to the 3.x version of Hibernate for only one of your web applications. So how would you do this easily using infrastructure?

1. Clone a production VM
2. Replace Hibernate 2.x with 3.x jars in the target web application
3. Clone that VM
4. Deploy the new VMs to the production cloud and delete the existing VMs

Ewwwwwwww!

Using CloudIQ, you could do this in half the steps and so fast that it will make your VMs head spin.

1. Replace Hibernate 2.x with 3.x jars in the target web application
2. Deploy the web application using CloudIQ Manager.

Sweeeeeeeet!

The point I’m trying to make is that CloudIQ virtualizes virtualization It gives you more fine-grained control or application level control.

Therefore it would be great to have Project Kenai allow for extensibility to support popular Cloud Application Platforms APIs.

What do you think?