Episode 4 – Entertaining Guests (An OpenStack Series)

Welcome to 2017. A tad belated but a very Happy New Year to all of you and a wonderful year ahead. Here is to hoping a year full of more excitement and more tech goodies. So where were we (I mean you and OpenStack {OS for short.}) Hopefully by this time things are much clearer, when it comes to OS and all its various moods and quirks. Lets do a quick recap.

Reading Level: Basic
Environment: OpenStack (Newton) on Ubuntu 16.04

Recap for Episode 3:

  • After discovering the various qualities of OS you started to build on this relationship block by block.
  • You decided to add some heat to the mix.
  • And the excitement continues!…

This is how far we have come in 3 Episodes:

Baseline OpenStack setup so far

So as of now we have configured the User Authentication (Keystone), The Image Store (Glance), The Compute (Nova), Networking (Neutron), Horizon (The Graphical User Interface,) Cinder (Block Storage Service) and Heat (Orchestration Service.)

So what now. I feel its time that we stop discovering and start experiencing. Simply put lets stop installing and configuring things for an Episode or two and start using the the things that we have setup :D. Happy times!!!…Since you and OS are practically living together (admit it you are,) it is time that you start entertaining some guests. We will take things slow in the beginning and start with one guest. Almost all of us have entertained guests at some point in our life (well almost all :P.) In this setting entertaining guests is not much different. In any cloud setting you will have instances physical/virtual, hosted over some hardware and you will need to provision access to these for your ‘Tenants.’  Additionally there is some preparatory work that needs to be done and some house keeping to keep everything neat and tidy. That is all good but what in the world are ‘Tenants.’ They are very much like paid guests, they pay you money and their instances live in your cloud. In much simpler terms these are the customers that you will create virtual machines for. We will follow the sequence depicted below in order entertain our very first guest (Tenant.)

ose4-0Since guests come from the outside the first step is to connect OS to the outside world. We do this by defining a Public (External Network.)

1. Create a Public Network
The component that deals with the Networking skills of OS is called ….. ‘Neutron.’ Yes you guessed it right. So we will be talking to neutron to connect to the external world. If you have been following the series and I hope you are, by now you know that we can interact with OS in one of two ways, namely the command-line (our favorite black and white) and Horizon (Graphical User Interface.) So what should we choose. I was presented with this same dilemma when I was writing this episode and after much deliberation I said to myself, why not both. So for each of the steps we will cover the procedure using Horizon and then using the command line.

I tried to do something new this time, so I recorded all my Horizon configurations as short 2-3 min videos. Do let me know if this was a good idea or a big NO NO. Feedback is always much appreciated. I need your feedback to continue writing relevant episodes and make further improvements. So do remember to let me know what you think, below in the blog comments.

The Configuration
Public Network Name PublicNet
Provider Network Type flat
Provider Physical Network external
Public Subnet Name PublicSub
Public Subnet Range
Public Network Allocation Pool –

If you are following along, now would be a good time to create a small configuration spreadsheet and start filling it up, like shown above. You can thank me later. So before we proceed Let me explain what we are seeing above:

  • Public Network Name: This is the name of the Public Network tha will represent the external network in your environment. When I say external I mean the network outside your OS environment. In most cases this will be your LAN (preferably having internet access) or the internet if you are adventurous.
  • Provider Network Type: This is the type of network being used on your external network. I am using a flat network for simplicity. You should adjust this as per your external network.
  • Provider Physical Network: If you remember Episode 2, we configured something on the following lines under neutron configuration:
    • bridge_mappings = vlan:br-vlan,external:br-ex
      Here we configured the aliases to represent the bridges that connect us to the vlan network and the external network. For the Public Network, the provider alias will be external.
    • –external: Tells OS that this is a external (public) network.
    • –share: Tells OS that this network is shared across tenants. We will use the same public network for all Tenants.
  • Public Subnet: Each network in openstack requires at least 1 subnet. The subnet contains all the details with regards to well…the subnet :P.
    • Name: Name of the Subnet
    • Subnet Range: Network Range for your network. Put the complete range
    • Allocation Pool: This is the pool of IP addresses that OS will use for your router public interfaces and floating IP addresses (I will come to these later.) Just make sure you choose a range that is not already allocated to other devices on your public network.
    • Gateway: Network gateway for your external network.

Horizon Configuration:
If you prefer pressing buttons, then sit back and enjoy the video below. It covers the creation of a Public Network in OS using Horizon. The only pre-requisite is that you already have a properly configured and running OS and are logged in to the admin project as the admin user.

Command-line Configuration:
If you prefer the faster command-line method then run the following commands:


Source the OS command line as the admin user in the admin project:

$ source keystone_admin

Run the following command to create a Public Network called PublicNet:

$ openstack network create PublicNet --provider-network-type flat --provider-physical-network external  --external --share

Run the following command to create a Subnet under PublicNet called PublicSub:

$ openstack subnet create PublicSub --network PublicNet --subnet-range --dhcp --allocation-pool start=,end= --gateway=

Once you are finished you will have achieved the following:

Public Network

Next step is to steal those glances. Time to setup a test image.

2. Create a Glance Image:

Although I have covered this already in Episode 2, for the sake of the new readers and also to have a complete set of steps for Tenant Creation, we will cover setting up a test image in glance.

The Configuration
Image Name cirros
Image File cirros-0.3.4-x86_64-disk.img
Disk Format qcow2
Container Format bare

So here we are going to:

  • Setup a cirros test image using a local image file.
  • The disk format and container format are dictated by the cloud image file that you are using.

The cirros img file that I am using for this post was obtianed from:
The above link has a large number of other images that you can also use for your testing.

Horizon Configuration:
Time for another short video. Don’t worry its not very long and I just added free music from google as a bonus :P. As before the only pre-requisite is that you already have a properly configured and running OS and are logged in to the admin project as the admin user.

Command-line Configuration:
Due to the nature of this intimate relation that you have developed with OS, you might be more comfortable getting your hands dirty with the evergreen command line. Follow the steps below to create a cirros test image in glance:

Source the OS command line as the admin user in the admin project:

$ source keystone_admin

Run the following command to create a cirros test image in glance

$ openstack image create "cirros" --file cirros-0.3.4-x86_64-disk.img --disk-format qcow2 --container-format bare --public

To list your created image run the following command:

$ openstack image list  
| ID                                   | Name       | Status |  
| b6b9b3f6-8ca3-4fb8-a6a8-284035003050 | cirros     | active | 

This concludes, (No not the post!!!) the preliminary work that is needed before we start configuring our first tenant. The next four steps that we will follow can be repeated for any number of guests that you and OS want to throw a party for.

3. Create a Tenant (Guest):
Since OS is so multi-tenant(ed) :P, we are able to create individual environments for each tenant that we want to host in our OS. All the networks and instances that we launch for this tenant are then contained with in this environment only. Lastly we create individual users for these tenants in order to give them access to the OS environment.

The Configuration
Project Name My First Tenant
User ftntuser
  • Project Name: In OS the most common way of representing a Tenant is a Project. Now this project can be an individual customer, it can be a department in an organization or it can be an environment like Test, Dev or Production. The business context is totally up to you.
  • User: This is the OS user that will get user level access to the OS environment. Why not admin access you may ask. The admin role in OS is not Project Specific and hence if you give this user admin role on one Project, it ends up having admin role across a number of other things that you do not want it to have admin access to. Its a tad strange but I am sure the guys who built it had their reasons.
  • Additionally we will give admin rights to the admin user on this project.

Horizon Configuration:
Video time again. As before the only pre-requisite is that you already have a properly configured and running OS and are logged in to the admin project as the admin user.

Command-line Configuration:
The command line configuration is simple as always. Follow the following sequence and you will have finished step 3 in no time:


Source the OS command line as the admin user in the admin project:

$ source keystone_admin

Create the Project (Tenant)

$ openstack project create --description "My First Tenant" FirstTenant

Create a user for the Project

$ openstack user create --password-prompt ftntuser

Give admin rights to admin user on this project:

$ openstack role add --project FirstTenant --user admin admin 
#(Command has no output)

Give user rights to project user on this project:

$ openstack role add --project FirstTenant --user ftntuser user  
#(Command has no output)

In order to list your newly created user:

$ openstack user list 
| ID                               | Name              |  
| 0a654fb98be846539f57c584d9da160f | heat              |  
| 24005f6d758d4310a42a6699a1862fb6 | glance            |  
| 71976fea20d54a7aba7b0df25c163f49 | nova              |  
| 86b3a5e60d85422ca9595b2eb5b48d00 | neutron           |  
| 8c18b13b02014e3e85ea77f522aa4dc9 | demo              |  
| 97b1b7d8cb0d473c83094c795282b5cb | admin             |  
| aa8d84376e6e4a69a7e08068e36086ce | ftntuser          |  
| baa6d69136f245dc9bd3e1d2fd61078f | heat_domain_admin |  
| cf02c88d1e6441d6aa4f15125156b214 | cinder            |  

In order to make each guest feel right at home, the one key element is privacy. In the next step we create what is called a Private Network. As stated earlier in this post, each of our Projects will host a tenant with their own network, network equipment and instances. These networks are only visible to this Project/Tenant.

4. Configure Tenant Networking
Each Project will require at least one private network in order to host its virtual instances and other services. Note that I say at least, meaning you are more than welcome to have multiple private networks for each tenant. We will cover multiple networks and additional advanced networking at a later Episodes. Right now for the sake of simplicity and understanding lets stick to one private network. In simpler terms this will be the guests own private LAN, with instances, routing and any other services you can imagine.

The Configuration
Private Network Name FTPrivateNet1
Provider Network Type vlan
Provider Physical Network vlan
Provider Segment 1381
Private Subnet Name FTPrivateSub1
Subnet Range
Router Name FTRouter1
  • Private Network Name: This is the name for the private network that will represent the Tenant’s local network in the OS environment
    • Provider Network Type: In my environment I am using vlans so I set it to vlan. You should change it to ‘flat’, ‘vxlan’ or whatever else you are using.
    • Provider Physical Network: This is the alias that we created to map to the br-vlan bridge in Episode 2. Do not confuse this with the vlan setting of the Provider Network Type, which is a reserve word. In the case of the Provider Physical Network vlan is just an alias we created as part of the neutron configuration. We could have called it myvlan, hypervlan, notreallyvlan. Since its just an alias just make sure it matches to the setting in the neutron configuration.
    • Provider Segment: Since I am using vlan networks this is the vlan ID for my tenant network. Make sure that your physical network supports such a vlan configuration, in case you decide to use vlans. Note that we defined a vlan range in Episode 2 in the neutron configuration. Make sure that this vlan ID is part of this range.
  • Private Subnet Name: This is the subnet under the Private Network that will have all the details for the network being created.
    • Subnet Range: This is the subnet definition being used. I am using a /24 network.
    • Gateway: I usually set this to the .1 IP in my subnet range. Set it to the IP that will be taken by the default router for this network.
  • Router Name: This is the virtual neutron router that will connect the private network and the public network. We need this if we want access to/from our instances from/to the outside world, which in our case is the Public Network.

Horizon Configuration:
So like all the previous steps there is a horizon configuration video for this one as well.

Here is something to confuse you a little bit. You will note in the video that I am using the Admin menu to create the Network and not the Project menu.The reason for this is that if you try to create the network using the Project Menu it will not allow you to choose the vlan ID on your own. This is also fine since the ID will be picked randomly from the vlan id pool that we defined in Episode 2. Although my physical network supports this, I like to assign specific vlans to specific subnets.

As before the only pre-requisite is that you already have a properly configured and running OS and are logged in to the FirstTenant (not admin) project as the admin user.

Command-line Configuration:
In order to perform the command line configuration we need to source the command line so that it accesses the FirstTenant Project and not the admin project. In order to do this we create a second keystone source file. Use the following procedure to create the source file and source the admin user on the FirstTenant project.


$ cp ~/keystone_admin ~/keystone_admin_ft 
$ vi ~/keystone_admin_ft 
    export OS_PROJECT_NAME=FirstTenant 
    export PS1='[\u@\h \W(keystone_admin_ft)]$ ' 
$ source ~/keystone_admin_ft

Create the Private Network:

$ openstack network create --provider-network-type vlan --provider-physical-network vlan --provider-segment 1381 FTPrivateNet1

Create the Private Subnet;

$ openstack subnet create FTPrivateSub1 --network FTPrivateNet1 --subnet-range --dhcp --gateway=

Create the tenant Router:

$ openstack router create FTRouter1

Define the Public Network as the external gateway for the router:

$ openstack router set FTRouter1 --external-gateway PublicNet  
# (Gives an Error "openstack router set: error: unrecognized arguments: --external-gateway PublicNet."
# If you get the same error use the command below instead) 
$ neutron router-gateway-set FTRouter1 PublicNet

Finally add an interface from the Private Subnet to the Router:

$ openstack router add subnet FTRouter1 FTPrivateSub1

Once you have completed the above configuration your setup should look like this:

Tenant Networking

Before we start entertaining guests it is a good idea to have some basic rules of engagement. These rules allow us to safely entertain guests while also controlling what all they can / cannot do while they are being entertained by you and OS. Lets look at Access and Security.

5. Configure Tenant Access and Security
For each Project we will need to configure the following bare minimum items:

Tenant Security Group: These are the firewall rules that apply to the tenant instances when they are launched. If you are familiar with any firewalls (networking or iptables etc,) you should find these very simple to understand. There is the Ingress / Egress which translates to incoming / outgoing, The source IP and port settings and the destination IP and port settings. Note that if your security group has no rules then all traffic will be dropped by neutron for/from the instance.

SSH Key pair: This is a more secure way of logging in to the instances. I am not going to go in to details of SSH Key authentication, (google is your best friend for that,) however in case you want your customers to be able to login in to their cloud instances using SSH keys (rather than the less secure password authentication) then you need to create at least 1 project specific ssh key pair

Floating IPs: Now remember that our instances will live on the private network. This private network is not accessible from the outside world. So how will we allow customers to connect to their cloud instances from outside. One solution to this is the use of floating IP(s). A floating IP is an IP that is taken from the allocation pool of the Public Network and mapped to an instance in the project. Hence whenever someone from the outside world tries to access this mapped IP, the traffic is routed to the particular instance. Using this method each customer instance will be assigned a floating IP. This might get a little in-efficient in the long run and there are other ways to bring the customer in to their private network (for example using VPN.) But this is a much advanced topic that we will leave for a later discussion.

The Configuration
Security Group Name FTSecurityGrp1
Keypair name FTKeyPair1
  • In the Security Group we are creating the following rules’
    • Allow all ICMP incoming traffic (Allow all ping)
    • Allow all port 22 incoming traffic (Allow ssh from anywhere)
    • By default all outgoing UDP and TCP traffic is open using two pre-existing rules in each new security group.
  • When the keypair is created the GUI allows you to download the private key, and the command-line displays the private key. Store this in a safe place. You will use this to login to the customer cloud instance at a later stage. As we all know that OS is full of surprises, let me tell you about one more. The scope of the SSH key is not limited to the Project but to the user who created it. Why or why not is a question we need to ask the developers. Don’t you just love all these surprises.
  • Each project needs to be assigned floating ip(s) from the public network allocation pool, before these floating IPs can be assigned to cloud instances.

Horizon Configuration:
I know you are getting addicted to these videos. Don’t get used to this. It might just be a one time thing :P. So the following video covers the bare minimum Access and Security configuration for the cloud tenant. As before the only pre-requisite is that you already have a properly configured and running OS and are logged in to the FirstTenant (not admin) project as the admin user.

Command-line Configuration:
The same steps can be performed using the command line. Frankly I prefer a black and white relationship. Things should be clear and repeatable. So you can follow the steps below for configuring Access and Security:

Source the FirstTenant profile

$ source ~/keystone_admin_ft

Create the Tenant Security Group:

$ openstack security group create FTSecurityGrp1

Assign the ICMP and ssh ingress rules to the security group:

$ openstack security group rule create --ingress --protocol ICMP FTSecurityGrp1 
$ openstack security group rule create --ingress --protocol tcp --dst-port 22 FTSecurityGrp1

Create a ssh keypair (Do NOT forget to make a copy of the private key displayed)

$ openstack keypair create FTKeyPair1

Assign a floating IP to the Project (Not to the instance. That will follow in the next step)

$ openstack floating ip create PublicNet

And it all comes down to this. All these Episodes, you have worked hard through thick and thin with your very moody yet extremely talented OS. And now you are ready to show off this relationship to the world. Time to let the guests in…

6. Launch an Instance
Now that we have set everything up its time to have some guests over. We will as discussed before begin with 1 guest and 1 virtual instance. (Yes basics are important, stop listening to those sales guys, you are not one of them :D) We will launch a cirros test instance in the FirstTenant that we have created. We will then make the provision to access this instance from the Public Network (You gotta let them in) and control the access. It sounds more complicated than it really is. So sit back and enjoy.

The Configuration
Flavor m1.tiny
Image cirros
Nic Net-id FTPrivateNet1
Security Group FTSecurityGrp1
Key Name FTKeyPair1
Instance Name FTFirstInstance
  • Flavor: Flavors are basically template sizes that you can refer to when launching an image. Basic parts of the flavor include disk, memory and number of cpu(s), and a few other items. You can find flavors in horizon under Admin -> System ->Flavors. If you are missing the flavors do not worry. Just create a new one with the following configuration:


    Leave the other fields as default.

  • Instance Name: This will be the name of the instance you will launch and will also serve as the hostname of the virtual machine.
  • The remaining items are all what you have configured in the previous steps. I am not going to repeat what they are. If you are unsure about any of them, now would be a good time to scroll up.

Horizon Configuration:
Ready for the last video of the day? Well not really last, yea no kidding. Sit back and enjoy as I show you how to launch an instance in OS. Yes its no rocket science, but let me have my little moment of triumph. As before the only pre-requisite is that you already have a properly configured and running OS and are logged in to the FirstTenant (not admin) project as the admin user.

Command-line Configuration:
The same can be done rather quickly using the following short sequence of commands:

Source the FirstTenant profile

$ source ~/keystone_admin_ft

T minus 10 seconds to Launch (just run the command below :P):

$ openstack server create --flavor m1.tiny --image cirros --nic net-id=FTPrivateNet1 --security-group FTSecurityGrp1 --key-name FTKeyPair1 FTFirstInstance

In order to confirm that the instance was launched successfully run the following command:

$ openstack server list 
| ID                                   | Name            | Status | Networks                   | Image Name | 
| 02d1fec3-edbc-4c96-8d2b-a423c4cbcc05 | FTFirstInstance | ACTIVE | FTPrivateNet1= | cirros     | 

If you see an output similar to one above where Status = ACTIVE, you have successfully launched your first instance. If not then wait till it turns active.

In order to map a public network (floating IP) to the instance run the following command:

$ openstack floating ip list 
| ID                                   | Floating IP Address | Fixed IP Address | Port | 
| 8bc8bcd7-11b8-4238-a5cf-c2a4d0d9b77d |        | None             | None | 

Your output would be similar (not the same) to the above. Copy the floating IP shown in the output and run the following command using this floating IP.

$ openstack server add floating ip FTFirstInstance

And we are DONE. Seriously!!! I am not going to show you how to login to a cloud instance. I mean cmon!!!

Oh well fine, just for the pure love of OS I created this last video that shows how to ssh and test connectivity for the cloud instance. Just make sure that if you are following along then the floating IP that you use for the ssh commands is the one that you configured for your instance and ensure that you are doing an ssh from a machine on the Public Network (NOT from the controller or inside OS.)

If you have managed to stay awake and follow along, then you are all set to entertain more hosts. Go ahead experiment a bit with private networks, routers and cloud instances. Let me know how it goes. If you get stuck don’t bother me……just kidding, just drop me a word in the comments and I will be more than happy to assist.

This is how far you have come in this Episode

  • After successfully courting OS for a while you decided to go public with the relationship
  • You were able to privately and securely host your first simple guest with OS.
  • You are getting ready to throw a party!!

Your horizon network topology should look something similar to the one below at this point:

Tenant Network Topology in OS


  • We will figure out how to positively use chemistry (heat) to host guests on a consistent basis.
  • Time to throw a party (a few more guests and more networking.)  Aren’t we the party animal!!
  • Have a good time!!!

Once again I thank you for reading and your patience. If you have any questions/comments/issues please feel free to share below in the comments section so everyone from different sources can benefit from the discussion. Even if you don’t, just drop in a comment to say you like the post or don’t like the post or whatever, just so that I know you were here. The next Episode is up on Episode 5 – Understanding Heat. Happy reading and don’t forget to press that follow button on the blog.

For my latest posts please visit WhatCloud.


5 thoughts on “Episode 4 – Entertaining Guests (An OpenStack Series)

Add yours

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

Powered by WordPress.com.

Up ↑

%d bloggers like this: