A Step-by-Step Cloud Setup Guide

The OpenStack Dashboard

Your cloud is basically ready for service; you can start virtual machines at the console, but to round off the setup, you still need OpenStack Dashboard (Figure 6), which lets end users create virtual machines as a Service Servicing Portal. After installing the required packages on Alice, take a look at the /etc/openstack-dashboard/local_settings.py file. A couple of entries are needed at the end of this file for the dash to work correctly:

Figure 6: After installing the dashboard, you can use it to start virtual machines in the GUI.

OPENSTACK_HOST = '192.168.122.111'
QUANTUM_ENABLED = True
SWIFT_ENABLED = True

Next, restart the Apache2 web server by typing restart apache2 so that the dashboard reloads its configuration. Directly after doing so, the web interface is available on http://192.168.122.111/horizon (Figure 7). You can log in as admin with a password of secret.

Figure 7: The dashboard displays information on the active virtual machines, such as the IP address assignments and the hardware configuration.

The Thing About Metadata Servers

Virtual machines that are created from special images – that is, from images officially prepared for cloud environments – all have one thing in common: During the boot process, they send HTTP requests to discover information about themselves from the cloud metadata server. This approach was first used in Amazon's EC2 environment; it ensures that the virtual machine knows its own hostname and has a couple of parameters configured when the system starts (e.g., the settings for the SSH server, to start).

The Ubuntu UEC images are a good example for the use of this feature: A machine created from an Ubuntu image for UEC environments runs cloud-init when it starts up. The approach is always the same: An HTTP request for the URL http://169.254.169.254:80 queries the details from the cloud controller. For this to work, you need a matching iptables rule to forward the correct IP address on the computing nodes to the correct cloud controller using DNAT.

The correct controller in this example is nova-api-metadata, which listens on port 8775 on Alice. The good news is that the L2 agent automatically configures the DNAT rule on the compute nodes. The bad news is that you need to configure a route for the return channel from the cloud controller  – that is, Alice – to the virtual machines. The route uses the private VM network as its network (e.g., 10.5.5.0/24) and the IP address that acts as the gateway IP for virtual machines on the network host as the gateway. This value will vary depending on your configuration.

To discover the address, type quantum router-list to discover the ID of the router used by the external network. Once you have this ID, typing:

quantum port-list -- --device_id ID --device_owner network:router_gateway

will give you the gateway – in this example, it is 192.168.144.100. To set the correct route on Alice, you would then need to type:

ip route add 10.5.5.0/24 via 192.168.144.100

After this, access to the metadata server will work. The setup basically routes the packages around the cloud to the cloud controller – you can assume that this fairly convoluted process will be replaced by a new procedure in a future version of OpenStack.

Future

The OpenStack installation I looked at in this article gives you a basic setup that builds a cloud from three nodes. The third part of this series will look at topics such as high availability for individual services and how to assign "official" IP addresses to the virtual machines. It will also explain how to extend the basic setup to provide more computing nodes. Additionally, the next article will look at some of the options that Quantum offers as a network service, which were beyond the scope of this part of the series.