OpenStack – Installing OpenStack Essex (2012.1) on Ubuntu 12.04

by sahab on May.10, 2012, under Ububtu 12.04, Ubuntu

What is OpenStack

OpenStack OpenStack is a global collaboration of developers and cloud computing technologists producing the ubiquitous open source cloud computing platform for public and private clouds. The project aims to deliver solutions for all types of clouds by being simple to implement, massively scalable, and feature rich. The technology consists of a series of interrelated projects delivering various components for a cloud infrastructure solution.

Installing OpenStack Essex (2012.1) on Ubuntu 12.04 (“Precise Pangolin”):

Install NTP by issuing this command on the command line:

apt-get install ntp

Then, open /etc/ntp.conf in your favourite editor and add these lines:

server ntp.ubuntu.com iburst server 127.127.1.0 fudge 127.127.1.0 stratum 10

Restart NTP by issuing the command

service ntp restart

to finish this part of the installation. Next, install the tgt target, which features an iscsi target (we’ll need it for nova-volume):

apt-get install tgt

Then start it with

service tgt start

Given that we’ll be running nova-compute on this machine as well, we’ll also need the openiscsi-client. Install it with:

apt-get install open-iscsi open-iscsi-utils

Next, we need to make sure that our network is working as expected. As pointed out earlier, the machine we’re doing this on has two network interfaces, eth0 and eth1. eth0 is the machine’s link to the outside world, eth1 is the interface we’ll be using for our virtual machines. We’ll also make nova bridge clients via eth0 into the internet. To achieve this kind of setup, first create the according network configuration in /etc/network/interfaces (assuming that you are not using NetworkManager). An example could look like this:

auto lo iface lo inet loopback

auto eth0 iface eth0 inet static address 10.42.0.6 network 10.42.0.0 netmask 255.255.255.0 broadcast 10.42.0.255 gateway 10.42.0.1

auto eth1 iface eth1 inet static address 192.168.22.1 network 192.168.22.0 netmask 255.255.255.0 broadcast 192.168.22.255

As you can see, the “public” network here is 10.42.0.0/24 while the “private” network (within which our VMs will be residing) is 192.168.22.0/24. This machine’s IP address in the public network is 10.42.0.6 and we’ll be using this IP in configuration files later on (except for when connecting to MySQL, which we’ll by connecting to 127.0.0.1). After changing your network interfaces definition accordingly, make sure that the bridge-utils package is installed. Should it be missing on your system, install it with

apt-get install bridge-utils

Then, restart your network with

/etc/init.d/networking restart

We’ll also need RabbitMQ, an AMQP-implementation, as that is what all OpenStack components use to communicate with eath other, and memcached.

apt-get install rabbitmq-server memcached python-memcache

As we’ll also want to run KVM virtual machines on this very same host, we’ll need KVM and libvirt, which OpenStack uses to control virtual machines. Install these packages with:

apt-get install kvm libvirt-bin

Last but not least, make sure you have an LVM volume group called nova-volumes; the nova-volume service will need such a VG later on.

Install MySQL and create the necessary databases and users

Nova and glance will use MySQL to store their runtime data. To make sure they can do that, we’ll install and set up MySQL. Do this:

apt-get install -y mysql-server python-mysqldb

When the package installation is done and you want other machines (read: OpenStack computing nodes) to be able to talk to that MySQL database, too, open up /etc/mysql/my.cnf in your favourite editor and change this line:

bind-address = 127.0.0.1

to look like this:

bind-address = 0.0.0.0

Then, restart MySQL:

service mysql restart

Now create the user accounts in mysql and grant them access on the according databases, which you need to create, too:

mysql -u root <<EOF
CREATE DATABASE nova;
GRANT ALL PRIVILEGES ON nova.* TO 'novadbadmin'@'%' 
  IDENTIFIED BY 'dieD9Mie';
EOF

mysql -u root <<EOF
CREATE DATABASE glance;
GRANT ALL PRIVILEGES ON glance.* TO 'glancedbadmin'@'%' 
  IDENTIFIED BY 'ohC3teiv';
EOF

Install and configure Keystone

We can finally get to OpenStack now and we’ll start by installing the Identity component, codenamed Keystone. Install the according packages:

apt-get install keystone python-keystone python-keystoneclient

Then, open /etc/keystone/keystone.conf in an editor and make sure to set a value for admin_token. We’ll use “hastexo” in this example.

Scroll down to the section starting with [catalog]. This section defines where Keystone finds its endpoint defintions. In earlier versions of Keystone, endpoints had to be manually defined with keystone-manage, but in newer Keystone versions, we can just use a template for that. Ubuntu’s default configuration uses such an endpoint catalog stored in MySQL. However, according to the OpenStack developers, this isn’t the recommended method for Essex. Change the [catalog] section to look like this:

[catalog] driver = keystone.catalog.backends.templated.TemplatedCatalog template_file = /etc/keystone/default_catalog.templates

After you have conduced these changes, restart Keystone by issuing this command:

service keystone restart

The next step is to fill Keystone with actual data. You can use the script attached to this blog entry entitled keystone_data.sh_.txt. It’s courtesy of the Devstack project with some adaptions. Rename the file to keystone_data.sh. Be sure to replace the admin password (ADMIN_PASSWORD variable) and the value for SERVICE_TOKEN with the entry you specified in keystone.conf for admin_token earlier. Then just make the script executable and call it; if everything goes well, it should deliver a return code of 0 and your keystone is ready to go.

Download the file

Install and configure Glance

The next step on our way to OpenStack is its Image Service, codenamed Glance. First, install the packages necessary for it:

apt-get install glance glance-api glance-client glance-common glance-registry python-glance

When that is done, open /etc/glance/glance-api-paste.ini in an editor and scroll down to the end of the document. You’ll see these three lines at its very end:

admin_tenant_name = %SERVICE_TENANT_NAME%
admin_user = %SERVICE_USER%
admin_password = %SERVICE_PASSWORD%

Fill in values here appropriate for your setup. If you used the keystone_data.sh script from this site, then your admin_tenant_name will be admin and your admin_user will be admin, too. admin_password is the password you defined for ADMIN_PASSWORD in keystone_data.sh, so use the same value here, too. In this example, we’ll use hastexo.

After this, open /etc/glance/glance-registry-paste.ini and scroll to that file’s end, too. Adapt it in the same way you adapted /etc/glance/glance-api-paste.ini earlier.

Please open /etc/glance/glance-registry.conf now and scroll down to the line starting with sql_connection. This is where we tell Glance to use MySQL; according to the MySQL configuration we created earlier, the sql_connection-line for this example would look like this:

sql_connection = mysql://glancedbadmin:ohC3teiv@10.42.0.6/glance

It’s important to use the machine’s actual IP in this example and not 127.0.0.1! After this, scroll down until the end of the document and add these two lines:

[paste_deploy]
flavor = keystone

These two lines instruct the Glance Registry to use Keystone for authentication, which is what we want. Now we need to do the same for the Glance API. Open /etc/glance/glance-api.conf and add these two lines at the end of the document:

[paste_deploy]
flavor = keystone

Afterwards, you need to initially synchronize the Glance database by running these commands:

glance-manage version_control 0
glance-manage db_sync

It’s time to restart Glance now:

service glance-api restart && service glance-registry restart

Now what’s the best method to verify that Glance is working as expected? The glance command line utilty can do that for us, but to work properly, it needs to know how we want to authenticate ourselves to Glance (and keystone, subsequently). This is a very good moment to define four environmental variables that we’ll need continously when working with OpenStack: OS_TENANT_NAME, OS_USERNAME, OS_PASSWORD and OS_AUTH_URL. Here’s what they should look like in our example scenario:

export OS_TENANT_NAME=admin
export OS_USERNAME=admin
export OS_PASSWORD=hastexo
export OS_AUTH_URL="http://localhost:5000/v2.0/"

The first three entries are identical with what you inserted into Glance’s API configuration files earlier and the entry for OS_AUTH_URL is mostly generic and should just work. After exporting these variables, you should be able to do

glance index

and get no output at all in return (but the return code will be 0; check with echo $?). If that’s the case, Glance is setup correctly and properly connects with Keystone. Now let’s add our first image!

We’ll be using a Ubuntu UEC image for this. Download one:

wget http://uec-images.ubuntu.com/releases/11.10/release/ubuntu-11.10-server-cloudimg-amd64-disk1.img

Then add this image to Glance:

glance add name="Ubuntu 11.10 cloudimg amd64" is_public=true container_format=ovf disk_format=qcow2 < ubuntu-11.10-server-cloudimg-amd64-disk1.img

After this, if you do

glance index

once more, you should be seeing the freshly added image.

Install and configure Nova

OpenStack Compute, codenamed Nova, is by far the most important and the most substantial openstack component. Whatever you do when it comes to managing VMs will be done by Nova in the background. The good news is: Nova is basically controlled by one configuration file, /etc/nova/nova.conf. Get started by installing all nova-related components:

apt-get install nova-api nova-cert nova-common nova-compute nova-compute-kvm nova-doc nova-network nova-objectstore nova-scheduler nova-vncproxy nova-volume python-nova python-novaclient

Then, open /etc/nova/nova.conf and replace everything in there with these lines:

--dhcpbridge_flagfile=/etc/nova/nova.conf
--dhcpbridge=/usr/bin/nova-dhcpbridge
--logdir=/var/log/nova
--state_path=/var/lib/nova
--lock_path=/var/lock/nova
--allow_admin_api=true
--use_deprecated_auth=false
--auth_strategy=keystone
--scheduler_driver=nova.scheduler.simple.SimpleScheduler
--s3_host=10.42.0.6
--ec2_host=10.42.0.6
--rabbit_host=10.42.0.6
--cc_host=10.42.0.6
--nova_url=http://10.42.0.6:8774/v1.1/
--routing_source_ip=10.42.0.6
--glance_api_servers=10.42.0.6:9292
--image_service=nova.image.glance.GlanceImageService
--iscsi_ip_prefix=192.168.22
--sql_connection=mysql://novadbadmin:dieD9Mie@10.42.0.6/nova
--ec2_url=http://10.42.0.6:8773/services/Cloud
--keystone_ec2_url=http://10.42.0.6:5000/v2.0/ec2tokens
--api_paste_config=/etc/nova/api-paste.ini
--libvirt_type=kvm
--libvirt_use_virtio_for_bridges=true
--start_guests_on_host_boot=true
--resume_guests_state_on_host_boot=true
--vnc_enabled=true
--vncproxy_url=http://10.42.0.6:6080
--vnc_console_proxy_url=http://10.42.0.6:6080
# network specific settings
--network_manager=nova.network.manager.FlatDHCPManager
--public_interface=eth0
--flat_interface=eth1
--flat_network_bridge=br100
--fixed_range=192.168.22.32/27
--floating_range=10.42.0.32/27 
--network_size=32
--flat_network_dhcp_start=192.168.22.33
--flat_injected=False
--force_dhcp_release
--iscsi_helper=tgtadm
--connection_type=libvirt
--root_helper=sudo nova-rootwrap
--verbose

As you can see, many of the entries in this file are self-explanatory; the trickiest bit to get done right is the network configuration part, which you can see at the end of the file. We’re using Nova’s FlatDHCP network mode; 192.168.22.32/27 is the fixed range from which our future VMs will get their IP adresses, starting with 192.168.22.33. Our flat interface is eth1 (nova-network will bridge this into a bridge named br100), our public interface is eth0. An additional floating range is defined at 10.42.0.32/27 (for those VMs that we want to have a ‘public IP’).

Attention: Every occurance of 10.42.0.6 in this file refers to the IP of the machine I used for writing this guide. You need to replace it with the actual machine IP of the box you are running this on. For example, if your machine has the local IP address 192.168.0.1, then use this IP instead of 10.42.0.6.

After saving nova.conf, open /etc/nova/api-paste.ini in an editor and scroll down to the end of the file. Adapt it according to the changes you conducted in Glance’s paste-files in step 3.

Then, restart all nova services to make the configuration file changes take effect:

for a in libvirt-bin nova-network nova-compute nova-api nova-objectstore nova-scheduler nova-volume nova-vncproxy; do service "$a" stop; done

for a in libvirt-bin nova-network nova-compute nova-api nova-objectstore nova-scheduler nova-volume nova-vncproxy; do service "$a" start; done

The next step will create all databases Nova needs in MySQL. While we are at it, we can also create the network we want to use for our VMs in the Nova databases. Do this:

nova-manage db sync

nova-manage network create private --fixed_range_v4=192.168.22.32/27 --num_networks=1 --bridge=br100 --bridge_interface=eth1 --network_size=32

Also, make sure that all files in /etc/nova belong to the nova user and the nova group:

chown -R nova:nova /etc/nova

Then, restart all nova-related services again:

for a in libvirt-bin nova-network nova-compute nova-api nova-objectstore nova-scheduler nova-volume nova-vncproxy; do service "$a" stop; done

for a in libvirt-bin nova-network nova-compute nova-api nova-objectstore nova-scheduler nova-volume nova-vncproxy; do service "$a" start; done

You should now see all these nova-* processes when doing ps auxw. And you should be able to use the numerous nova commands. For example,

nova list

should give you a list of all currently running VMs (none, the list should be empty). And

nova image-list

should show a list of the image you uploaded to Glance in the step before. If that’s the case, Nova is working as expected and you can carry on with starting your first VM.

Your first VM

Once Nova works as desired, starting your first own cloud VM is easy. As we’re using a Ubuntu image for this example which allows for SSH-key based login only, we first need to store a public SSH key for our admin user in the OpenStack database. Upload the file containing your SSH public key onto the server (i’ll assume the file is called id_dsa.pub) and do this:

nova keypair-add --pub_key id_rsa.pub key1

This will add the key to OpenStack Nova and store it with the name “key1″. The only thing left to do after this is firing up your VM. Find out what ID your Ubuntu image has, you can do this with:

nova image-list

When starting a VM, you also need to define the flavor it is supposed to use. Flavors are pre-defined hardware schemes in OpenStack with which you can define what resources your newly created VM has. OpenStack comes with five pre-defined flavors; you can get an overview over the existing flavors with

nova flavor-list

Flavors are referenced by their ID, not by their name. That’s important for the actual command to execute to start your VM. That command’s syntax basically is this:

nova boot --flavor ID --image Image-UUID --key_name key-name vm_name

So let’s assume you want to start a VM with the m1.tiny flavor, which has the ID 1. Let’s further assume that your image’s UUID in Glance is 9bab7ce7-7523-4d37-831f-c18fbc5cb543 and that you want to use the SSH key key1. Last but nut least, you want your new VM to have the name superfrobnicator. Here’s the command you would need to start that particular VM:

nova boot --flavor 1 --image 9bab7ce7-7523-4d37-831f-c18fbc5cb543 --key_name key1 superfrobnicator

After hitting the Enter key, Nova will show you a summary with all important details concerning the new VM. After some seconds, issue the command

nova show superfrobnicator

In the line with the private_network keyword, you’ll see the IP address that Nova has assigned this particular VM. As soon as the VMs status is ACTIVE, you should be able to log into that VM by issuing

ssh -i Private-Key ubuntu@IP

Of course Private-Key needs to be replaced with the path to your SSH private key and IP needs to be replaced with the VMs actual IP. If you’re using SSH agent forwarding, you can leave out the “-i”-parameter altogether.

The OpenStack Dashboard

We can use Nova to start and stop virtual machines now, but up to this point, we can only do it on the command line. That’s not good, because typically, we’ll want users without high-level administrator skills to be able to start new VMs. There’s a solution for this on the OpenStack ecosystem called Dashboard, codename Horizon. Horizon is OpenStack’s main configuration interface. It’s django-based.

Let’s get going with it:

apt-get install libapache2-mod-wsgi openstack-dashboard

Make sure that you install at least the version 2012.1~rc2-0ubuntu1 of the openstack-dashboard package as this version contains some important fixes that are necessary for Horizon to work properly.

Then, open /etc/openstack-dashboard/local_settings.py in an editor. Go to the line starting with CACHE_BACKEND and make sure it looks like this:

CACHE_BACKEND = 'memcached://127.0.0.1:11211/'

Now restart Apache with

service apache2 restart

After this, point your webbrowser to the Nova machine’s IP address and you should see the OpenStack Dashboard login prompt. Login with admin and the password you specified. That’s it – you’re in!

Making the euca2ools work

OpenStack offers a full-blown native API for administrator interaction. However, it also has an API compatible with Amazons AWS service. This means that on Linux you can not only use the native OpenStack clients for interaction but also the euca2ools toolsuite. Using euca2ools with keystone is possible. Large portions on how to do it are written down in this document. Here’s the short summary for those who are in a hurry:

export EC2_URL=$(keystone catalog --service ec2 | awk '/ publicURL / { print $4 }')
export CREDS=$(keystone ec2-credentials-create)
export EC2_ACCESS_KEY=$(echo "$CREDS" | awk '/ access / { print $4 }')
export EC2_SECRET_KEY=$(echo "$CREDS" | awk '/ secret / { print $4 }')

After that, the euca2ools should just work (if the euca2ools package is installed, of course). You can try running

euca-describe-images

euca-describe-instances

to find out whether it’s working or not.

Making nova-volume work

nova-volume is the OpenStack Compute component that will allow you to assign persistent storage devices to your virtual machines. Internally, it’s using iSCSI, which is why you installed the tgt package earlier.

Assuming that you have a local LVM volume group entitled nova-volumes, you can try assigning a 1G large volume to our superfrobnicator VM by using these commands to create a 1G large volume and assign it accordingly:

nova volume-create --display_name "volume1" 1
nova volume-attach superfrobnicator 1 /dev/vdb

Please take particular note of the parameter between superfrobnicator and /dev/vdb in this example. It refers to the actual ID of the volume. To find out a volume’s ID, you can do

nova volume-list

and then use the value from the “ID” field for a specific volume. If everything went well, you’ll see a new disk device in the superfrobnicator VM now, /dev/vdb.

Using floating IPs

Floating IPs are an unbelievably handy tool in OpenStack to supply your virtual machines with “official” IP addresses. In this example, we’ve mainly been dealing with the 192.168.22.0/24 network, which is the “internal” network for our VMs. Our VMs can communicate with each other and they can communicate with the outside world, but they don’t have an official IP address that others could connect to (the “public” net in this test-setup is 10.42.0.0/24 after all). Floating IPs allow you to assign your VMs an additional IP from that “public” network, making them accessible directly. And using floating IPs is anything but hard!

First, you’ll have to define a range of addresses which OpenStack nova will use. Our old friend nova-manage does this:

nova-manage floating create --ip_range=10.42.0.32/27

Then, within Nova itself, you’ll have to create a floating IP (creating here is Nova-speak for “reserving”):

nova floating-ip-create

This command will print out an IP address (in this example it’s 10.42.0.35) that you will need in the next step. To assign this IP to our superfrobnicator VM, use this command:

nova add-floating-ip superfrobnicator 10.42.0.35

Please note: Assigning a floating IP to an existing VM does automatically enable that IP for the VM. You’ll not have to manually assign the IP to the VMs main network interface, as all the networking magic is done by iptables on the actual compute node.

That’s it! Your new VM can now use its floating IP. There is only one problem left: By default, nova uses very secure iptables rules to protect IPs reachable via floating IPs from abuse. De facto, nova will not allow any traffic from the outside to get through to your VM. We’ll have to fiddle with Security Groups to solve this problem. Here’s how you can enable SSH access and ICMP to your floating IPs:

nova secgroup-add-rule default tcp 22 22 0.0.0.0/0
nova secgroup-add-rule default icmp -1 -1 0.0.0.0/0

After this, your VM will be reachable directly from the outside via its floating IP address (by SSH and ICMP).

http://ubuntulinux.co.in/blog/wp-admin/media.php?attachment_id=511&action=edit

:openstack, OpenStack - Installing OpenStack Essex (2012.1) on Ubuntu 12.04

3 Comments for this entry

Nesrine
May 19th, 2012 on 8:36 pm
hello ! first, thank you for this documentation
i have a problem concerning “nova image-list”
before added : chown -R nova:nova /etc/nova all goes well . but after i have an missing authentication .
thank you in advance.
sahab
May 30th, 2012 on 5:15 pm
Please paste the error message
Jack
February 25th, 2013 on 1:26 am
Way cool! Some extremely valid points! I appreciate you penning this write-up plus the rest of the website is really good.