In this DevStack example, I will show how to install a DevStack-based demo OpenStack solution on an existing Ubuntu 14.04 server.

DevStack is an open source project with the goal to offer a development, test or demo environment for working with OpenStack. The compute nodes are based on QEMU, a software virtualization, so do not expect any high performance from this installation. However, it helps you to get acquainted with the handling of OpenStack, to get acquainted with OpenStack’s APIs and/or even to contribute to the OpenStack project.

In this post, we will install OpenStack on an existing Ubuntu server 14.04. I have tried to follow the official documentation, but it was easy to get lost there. The official documentation has led me to some challenges related to file permissions, which you can circumvent by following the step by step guide below.

DevStack Example – Step by Step

Step 1: Install Ubuntu 14.04 Server

In my case, I have used Hyper-V and the Ubuntu Server 14.04 ISO for installing a high-performance Ubuntu server on my brand new monster Predator notebook with 64GB RAM. Hyper-V requires Windows 10 Pro license as a minimum if you are not working with Windows Server licenses. However, you can also choose to install Ubuntu 14.04.x on physical hardware, on VMware vSphere, VMware Workstation, the old VMware Server 2.0.2 or on VirtualBox.

Note: there is a nice and simple way to install Ubuntu on VirtualBox using Vagrant, which I have described in step 1 „Install a Docker Host“ in this post. The Docker host Vagrant box is an Ubuntu 14.04 machine and the Docker software does not hurt. The biggest challenge there is to successfully install VirtualBox.

The following Software needs to be installed in addition on Ubuntu:

sudo apt-get install openssh-server git

Step 2: Download DevStack from Git

Now we need to download DevStack using git:

git clone
cp devstack/samples/local.conf devstack/

Step 3 (optional): take snapshot of your Ubuntu virtual machine (if it is a virtual machine)

At this point, I have created a snapshot (checkpoint) of the VM on Hyper-V, so I can go back any time, the installation fails.

Step 4 (necessary?): copy and edit local.conf

In the moment, it is not clear, whether it is used during installation, but I have copied local.conf from devstack/samples to devstack, as the official documentation always talks about changing local.conf file :

cp devstack/samples/local.conf devstack/

And I have changed the content of devstack/local.conf like follows:

# OV: commented out
# OV: commented out
# I have kept following lines:

Step 5: create a non-root user called „stack“ and log in as this user

Devstack does not run as root, so we need a non-root user. You might want to re-use an existing non-root user instead, but I recommend to create it like follows:

myname@ubuntu:~$ sudo devstack/tools/
Creating a group called stack
Creating a user called stack
Giving stack user passwordless sudo privileges

The user stack has no password, so we only can log in via su as root. In my case, myname is a sudo user, so I have loged in via the command:

myname@ubuntu:~$ sudo su stack

Step 6: copy the git repository to the „stack“ user’s home directory

This step is missing in the official documentation and had caused the installation script to fail due to wrong permissions. As user „stack“, navigate to the directory containing devstack and copy the directory to home directory:

cp -R devstack ~/

The devstack repository is not large, but if you do not want to copy it, you also could change the file permissions by using a chown -R stack:stack devstack.

Step 7: run the installation script

Now the devstack folder and its contents are owned by user stack and the installation script should run with no problems:

cd ~/devstack; ./

-> here I was asked for the password again, even though it is defined in local.conf already. I have not investigated yet, whether the Step 4 above is necessary at all. Just re-type the password you have defined in Step 4.

After ~50 minutes, we see following last message of the installation:

2016-06-21 09:44:20.771 | completed in 2946 seconds.

In this case, the command was running on a Hyper-V Ubuntu 14.04.3 server with only one core of the i7-6700QM CPU and only 6 Mbps Internet download bandwidth.

Step 8: log in to Horizon as admin

Unfortunately, there is no information given on what to do next. Therefore, I have had a look into and I have found that Horizon should be available on URL http://hostname/dashboard/auth/login/?next=/dashboard/ where hostname is in my case:

2016-06-21 (1)

Yes, perfect! Horizon is up and running.

Per trial and error, I have logged in as user „admin“ with the password I have provided above and I have reached the Identity -> Projects screen:

2016-06-21 (2)

Bingo! Time to play around!


Step 9: explore Compute Nodes

On Admin->Hypervisors, we can see that DevStack has added a single QEMU-based Hypervisor with 512MB RAM on the base ubuntu machine:

2016-06-21 (4)

Step 10: create a virtual machine / Instance

On Projects->Compute->Instances, click on „Launch Instance“:

2016-06-21 (5)

2016-06-21 (6)

and then on „Next“. Then we can choose the image, from which the instance will be built:

2016-06-21 (7)

Click on the Plus-sign next to the cirros image and click „Next“.

In the next screen, I have chosen the smallest flavor with 64MB RAM and no disk. Since the QEMU only provides 512MB, some of the other flavors should cause problems later on (can be tested later).

2016-06-21 (9)

Let us skip the other steps for now and immediately create the instance by clicking „Launch Instance“ at the bottom of the screen (you might need to scroll down). You immediately should see a green box flashing with a success message: First, there will be a task „Spawning“, which will change to „None“ in a minute or so. At the same time, the instance Power state will be „Running“.

2016-06-21 (10)

The instance is assigned a private IP address However, is there a possibility to access the system?

Yes, from the Ubuntu system, you can ping the newly created instance:

stack@ubuntu:~$ ping
PING ( 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=64 time=3.38 ms
64 bytes from icmp_seq=2 ttl=64 time=0.333 ms

However, without SSH key, we will not be able to SSH into the system; similar to AWS instances.

In 25 minutes, the German team is playing soccer in the European Contest, so I will stop now with a final dashboard screen:

2016-06-21 (11)

We have created and started a virtual machine (instance) on OpenStack.

Appendix A: Workaround for Openstack Login Error „An error occurred authenticating Please try again later“

After some days of OpenStack running with no interaction from my side, I could not log in to horizon anymore.

2016-07-03 (1)

I have found this YouTube video with information on how to fix this issue. However, I could not find any shell script named, as required. I have re-installed devstack instead. For that, I have issued following commands:

sudo su - stack
cd ~/devstack
sudo rm -rf /etc/keystone

I had to remove the keystone folder with the rm -rf command in order to avoid an Operation not permitted failure during the execution of The downside of this solution is that it takes ~20 minutes of re-installation time again. At the end, I got following information:

This is your host IP address:
This is your host IPv6 address: ::1
Horizon is now available at
Keystone is serving at
The default users are: admin and demo
The password: secret
2016-07-03 14:37:50.238 | WARNING:
2016-07-03 14:37:50.238 | Using lib/neutron-legacy is deprecated, and it will be removed in the future
2016-07-03 14:37:50.239 | completed in 1082 seconds.

And I could log in again:

2016-07-03 (2)


    1. @Jeffrey: that is a good question. Does this description on neutron networking for devstack help? Judging from this document, you need to attach a bridge (Open vSwitch, Linux bridge or MacVTap) to the Firewall/NAT Router’s network. Then you attach the developer’s notebook’s interface to the bridge which may change its MAC-address, invalidating the arp-entries until the next refresh, if the notebook is not sending a gratuitous arp reply.

      The virtual machine instances will still get private IP addresses from the fixed pool (e.g. FIXED_RANGE=“″). This address is not known by the Internet Firewall/NAT router. However, you can assign a floating IP address (e.g. from Q_FLOATING_ALLOCATION_POOL=start=,end= to the instance. The translation between private IP and floating IP is a neutron service, see here for details. All in all, if the virtual machine connects to the Internet, there is a double NAT involved: once from 10.0.0.x to performed by Neutron, and another translation from to the outside public IP address performed by the Firewall/NAT router.

      For incoming connections, you will need to configure port mapping (i.e. static translation of public IP and port to and port) in the router and a similar mapping in the Neutron controller (from the and port to a 10.0.0.x IP address and port).

      Okay, this is all theory up to now. Have you tested something like this already?

  1. Hi
    Thank for the article: I have not finished the recipe yet, but I noticed that running the script to add a user does not work unless adding HOST_IP=“your computer ip“ In stackrc.

    1. Hi Nejm, if you have followed the same steps as I did, then the HOST_IP should not be needed. However, I have found following hint in samples/local.conf (see step 2):

      ### local.conf
      # „HOST_IP„ and „HOST_IPV6„ should be set manually for best results if
      # the NIC configuration of the host is unusual, i.e. „eth1„ has the default
      # route but „eth0„ is the public interface. They are auto-detected in
      # „„ but often is indeterminate on later runs due to the IP moving
      # from an Ethernet interface to a bridge on the host. Setting it here also
      # makes it available for „openrc„ to include when setting „OS_AUTH_URL„.
      # Neither is set by default.

      Best Regards,

  2. Hi,
    I followed the same steps as you did, but i am not getting the default hypervisor in the Admin>hypervisors and not able to find cirros image .Please help me out resolving this issue.

    1. Hi Vijay,
      sorry, your valuable comment/question was hidden under a pile of SPAM comments. I am sorry, to have not seen it in time. Have you succeeded in resolving your issue, finally? If so, how?
      Best regards

    1. I see that your question was posted quite long ago. Sorry for the late reaction.

      Good question. Have you tried to re-run If re-running stack-sh does not do the trick, there does not seem to be a simple way to just start the server without running again. You may need to extract your own startup script from, I fear.

      Maybe a reverse engineering of the function „run_phase“ could be a start?

      $ grep run_phase * 2>/dev/null clean
      functions-common:function run_phase { override_defaults source stack pre-install stack install stack post-config stack extra stack test-config override_defaults unstack

      Maybe you already have found a solution to the problem? It would be great if you’d tell us (even, if you have not found a solution).


Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.