• Floodlight Home

spacer OpenStack

{0}."> {0}-{1} of {2} pages containing {3}.">
Skip to end of metadata
  • Page restrictions apply
  • Attachments:2
  • Added by Bethany Kanui, last edited by Kuang-Ching Wang on Nov 21, 2012  (view change)
Go to start of metadata

Overview

Floodlight can be run as the network backend for OpenStack using a Quantum plugin.  Quantum exposes a networking-as-a-service model via a REST API that Floodlight has implemented.  There are two main components to this solution: a VirtualNetworkFilter module in Floodlight (that implements the Quantum API) and the Quantum RestProxy plugin that connects Floodlight to Quantum.

The VirtualNetworkFilter module implements MAC-based layer 2 network isolation in OpenFlow networks and exposed via a REST API.  This module is included in Floodlight by default and does not depend on Quantum or OpenStack to be running.  The VirtualNetworkFilter can be activated via a configuration file change described below. More information is available at Virtual Network Filter REST API.

The RestProxy plugin was designed to run as part of OpenStack’s Quantum service.   If you are unfamiliar with Quantum, it is recommended you read the OpenStack network wiki and Administrator’s Guide to understand how the plugin works and detailed usage instructions.  The following provides an example work flow that explains how Floodlight works with OpenStack.  

The example uses devstack scripts (customized to enable Floodlight's Quantum plugin) to simplify the install process (see devstack.org for an intro of the project). A pre-devtack ubuntu 12.04.1 server VM (Essex) and a post-devstack ubuntu 12.04.1 server VM (Essex) (SEE WARNING) are provided for convenience.  Both VMs already installed ant, default-jdk, and git.

Running Floodlight with VirtualNetworkFilter Enabled

Current support OpenStack Essex
Coming soon OpenStack Folsom

You have two options to follow this tutorial: (A) start with the pre-devstack VM (B) start with the post-devstack VM. If you chooses (B) (SEE WARNING), you'd still start with this step but bypass the install-devstack step.

Floodlight controller can be run on the provided VM, or a separate floodlight VM, or your host (say, in eclipse).

First, you need to unzip and register the VM with VirtualBox. Note a script is provided in the VM home directory to reset the ethernet interfaces to eth0 and eth1 (overcoming a VM cloning artifact that results in increasing ethernet interface numbers after cloning.)

On your host
$ unzip floodlight-openstack-server-pre-devstack-essex.zip
$ ./floodlight-openstack-ubuntu-12.04.1-server.vbox.sh
Click starting the VM in VirtualBox (login:nova,password:nova)
$./reset-eth.sh
VM will reboot and login as before - VM is ready now. Confirm ip addresses of eth0 and eth1 (eth1 usually will not have had an address)
$ ifconfig -a
$ sudo dhclient eth1

Note that in this VM sudo never asks for a password, due to a password bypass statement (last line) added to the /etc/sudoers file

$ cd floodlight
$ git pull
$ ant
$ java -jar target/floodlight.jar -cf src/main/resource/quantum.properties

If you DO choose to use a separate floodlight VM downloaded from floodlight.openflowhub.org, make sure you run flloodlight with the following steps

$ touch /opt/floodlight/floodlight/feature/quantum
$ sudo service floodlight restart

To confirm the VirtualNetworkFilter is successfully activated. If not, repeat steps above.

$ curl 127.0.0.1:8080/quantum/v1.0
{"status":"ok"}

Also, you may choose to use your favorite ssh terminal program to ssh into the VM once its eth1 (a host only adapter allowing your host to ssh into it); the VM address is typically 192.168.56.10x (i.e., 101, 102, ...)

Installing OpenStack with the RestProxy Quantum Plugin

Once Floodlight is confirmed running, we are ready to install OpenStack using the install-devstack script. The script 1) configures OVS switch on the VM to listen to floodlight and 2) installs OpenStack and Floodlight's Quantum REST proxy plugin on the VM.

If you started with the pre-devstack VM, you need this step:

$ cd quantum-restproxy
$ git checkout --track origin/for-essex/stable
$ scripts/install-devstack <floodlight IP address> 8080

If you have run floodlight in the same VM, them put 127.0.0.1 for its IP address; otherwise, put the IP address of the VM or host where you run floodlight.

*Note that OpenStack installation is a LONG process that cannot be interrupted. Any interruption or loss of network connectivity results unknown states that cannot be resumed. It is recommended that you take a "snapshot" using VirtualBox before you begin the installation, such that you can easily power down and restore the original snapshot if indeed the process is interrupted.

install-devstack.sh requires uninterrupted IP connectivity to run.

For those started with (B) (SEE WARNING), after running floodlight, do

$ cd ~/devstack
$ ./stack.sh

This step also takes quite a while. If this successfully completes, it will show the following:

Horizon is now available at 10.10.2.15/
Keystone is serving at 10.10.2.15:5000/v2.0/
Examples on using novaclient command line is in exercise.sh
The default users are: admin and demo
The password: nova
This is your host ip: 10.10.2.15
stack.sh completed in 102 seconds.

OPTION B WARNING:

spacer The OpenStack installation script is currently tightly dependent on the openflow controller address specified at installation. If you choose to use the post-devstack VM, make sure you understand this will only work correctly by running floodlight on the same VM (127.0.0.1). Just changing the localrc file with a new IP address won't make it listen to another controller location.
spacer If you do want to run your controller at a different IP address, say your desktop/laptop, start with the pre-devstack VM and specify the IP address you want.

Creating Networks, Tenants, VMs

Now we have a working OpenStack server, we can launch a number of VMs on it and associate them with different virtual networks via the Quantum API.

odd_even_essex.sh creates two networks,each for two VMs.  If the nodes are created successfully, a number of tables will be printed, but make sure you WAIT PATIENTLY for the nodes to complete their boot process.  With four VMs nested inside a VM, the execution tends to be slow.  If you want to check whether the boot has completed, you can do, for example, 'sudo tail /opt/stack/nova/instances/instance-00000001/console.log' from time to time until you see the "CIRROS" welcom logo is printed at the end of the console log.

N

gipoco.com is neither affiliated with the authors of this page nor responsible for its contents. This is a safe-cache copy of the original web site.