To ensure that we're running the Ubuntu Cloud Archive, we must first configure our Ubuntu 14.04 installation to use this service. For more information, visit http://bit.ly/OpenStackCookbookCloudArchive.

We will configure Keystone to use MariaDB as the database backend, so this needs to be installed prior to installing Keystone.

Ensure that you have a suitable server available for installation of the OpenStack Identity service components. If you are using the accompanying Vagrant environment, as described in the Preface, this will be the controller node.

Make sure that you are logged in to the controller node and ensure that it has Internet access to allow us to install the required packages in our environment for running Keystone. If you created this node with Vagrant, you can execute the following command:

vagrant ssh controller

The instructions here assume that the controller node has two IP addresses. It will have a front-facing IP address, 192.168.100.200, and a backside IP address, 172.16.0.200, (which is also the address of the MariaDB server). The reason it has two addresses is that internal data will communicate over the backside IP address (for example, database traffic), and any Keystone traffic will traverse the front.

Carry out the following instructions to install the OpenStack Identity service:

Congratulations! We have now installed the OpenStack Identity service and it is ready for use in our OpenStack environment.

A convenient way to install the OpenStack Identity service in our OpenStack environment is by using the Ubuntu packages. Once installed, we configure our MariaDB database server with a keystone database and set up the keystone.conf configuration file with the corresponding values. After starting the Keystone service, running the keystone-manage db_sync command populates the keystone database with the appropriate tables ready for us to add in the required users, roles, and tenants required in our OpenStack environment.

Ensure that you are logged in to the controller node and that it has Internet access to allow us to install the required packages in our environment for running Keystone. If you created this node with Vagrant, you can execute the following command:

vagrant ssh controller

Carry out the following instructions to configure the Keystone service:

The OpenStack services normally intercommunicate via standard HTTP requests. This provides a large degree of flexibility, but it comes at the cost of all communication happening in plain text. By adding SSL certificates and changing Keystone's configuration, all communication with Keystone will now be encrypted via HTTPS.

We will be using the keystone client to operate Keystone. If the python-keystoneclient tool isn't available, follow the steps described at http://bit.ly/OpenStackCookbookClientInstall.

Ensure that we have our environment set correctly to access our OpenStack environment for administrative purposes:

export OS_TENANT_NAME=cookbook
export OS_USERNAME=admin
export OS_PASSWORD=openstack
export OS_AUTH_URL=https://192.168.100.200:5000/v2.0/
export OS_NO_CACHE=1
export OS_KEY=/vagrant/cakey.pem
export OS_CACERT=/vagrant/ca.pem

vagrant ssh controller

To create a tenant in our OpenStack environment, perform the following steps:

Creation of the tenants is achieved by using the keystone client, specifying the tenant-create option with the following syntax:

keystone tenant-create \
    --name tenant_name \
    --description "A description" \
    --enabled true

The tenant_name is an arbitrary string and must not contain spaces. On creation of the tenant, this returns an ID associated with it that we use when adding users to this tenant. To see a list of tenants and the associated IDs in our environment, we can issue the following command:

keystone tenant-list

We will be using the keystone client to operate Keystone. If the python-keystoneclient tool isn't available, follow the steps described at http://bit.ly/OpenStackCookbookClientInstall.

Ensure that we have our environment set correctly to access our OpenStack environment for administrative purposes:

export OS_TENANT_NAME=cookbook
export OS_USERNAME=admin
export OS_PASSWORD=openstack
export OS_AUTH_URL=https://192.168.100.200:5000/v2.0/
export OS_NO_CACHE=1
export OS_KEY=/vagrant/cakey.pem
export OS_CACERT=/vagrant/ca.pem

vagrant ssh controller

To create the required roles in our OpenStack environment, perform the following steps:

Creation of the roles is simply achieved by using the keystone client and specifying the role-create option with the following syntax:

keystone role-create --name role_name

The role_name attribute can't be arbitrary for admin and Member roles. The admin role has been set by default in /etc/keystone/policy.json as having administrative rights:

{
    "admin_required": [["role:admin"], ["is_admin:1"]]
}

The Member role is also configured by default in the OpenStack Dashboard, Horizon, for a non-admin user created through the web interface.

On creation of the role, the ID associated with is returned, and we can use it when assigning roles to users. To see a list of roles and the associated IDs in our environment, we can issue the following command:

keystone role-list

We will be using the keystone client to operate Keystone. If the python-keystoneclient tool isn't available, follow the steps described at http://bit.ly/OpenStackCookbookClientInstall.

Ensure that we have our environment set correctly to access our OpenStack environment for administrative purposes:

export OS_TENANT_NAME=cookbook
export OS_USERNAME=admin
export OS_PASSWORD=openstack
export OS_AUTH_URL=https://192.168.100.200:5000/v2.0/
export OS_NO_CACHE=1
export OS_KEY=/vagrant/cakey.pem
export OS_CACERT=/vagrant/ca.pem

vagrant ssh controller

To create the required users in our OpenStack environment, perform the following steps:

Adding users in the OpenStack Identity service involves a number of steps and dependencies. First, a tenant is required for the user to be part of. Once the tenant exists, the user can be added. At this point, the user has no role associated, so the final step is to designate the role to this user, such as Member or admin.

Use the following syntax to create a user with the user-create option:

keystone user-create \
    --name user_name \
    --tenant_id TENANT_ID \
    --pass PASSWORD \
    --email email_address \
    --enabled true

The user_name attribute is an arbitrary name but cannot contain any spaces. A password attribute must be present. In the previous examples, these were set to openstack. The email_address attribute must also be present.

To assign a role to a user with the user-role-add option, use the following syntax:

keystone user-role-add \
    --user USER_ID \
    --role ROLE_ID \
    --tenant_id TENANT_ID

This means that we need to have the ID of the user, the ID of the role, and the ID of the tenant in order to assign roles to users. These IDs can be found using the following commands:

keystone tenant-list
keystone user-list
keystone role-list

We will be using the keystone command line client to operate Keystone. If the python-keystoneclient tool isn't available, follow the steps described at http://bit.ly/OpenStackCookbookClientInstall.

Ensure that we have our environment set correctly to access our OpenStack environment for administrative purposes:

export OS_TENANT_NAME=cookbook
export OS_USERNAME=admin
export OS_PASSWORD=openstack
export OS_AUTH_URL=https://192.168.100.200:5000/v2.0/
export OS_NO_CACHE=1
export OS_KEY=/vagrant/cakey.pem
export OS_CACERT=/vagrant/ca.pem

vagrant ssh controller

Defining the services and their endpoints in the OpenStack Identity service involves running the keystone client command. Although we might not have all services currently running in our environment, we will be configuring them within the OpenStack Identity service for future use. To define endpoints for services in our OpenStack environment, carry out the following steps:

Configuring the services and endpoints within the OpenStack Identity service is done with the keystone client command.

We first add the service definitions using the keystone client and the service-create option with the following syntax:

keystone service-create \
    --name service_name \
    --type service_type \
    --description 'description'

In the service_name is an arbitrary name or label defining our service of a particular type. We refer to the name when defining the endpoint to fetch the ID of the service.

The type option can be one of the following: compute, object-store, image-service, network, and identity-service. Note that we haven't configured the OpenStack Object Storage service (type object-store) at this stage, as this is covered in later recipes in the book.

The description field is again an arbitrary field describing the service.

Once we have added in our service definitions, we can tell OpenStack Identity service from where these services run by defining the endpoints using the keystone client and the endpoint-create option. The syntax is as follows:

keystone endpoint-create \
    --region region_name \
    --service_id service_id \
    --publicurl public_url \
    -–adminurl admin_url \
    --internalurl internal_url

Here, service_id is the ID of the service when we created the service definitions in the first step. The list of our services and IDs can be obtained by running the following command:

keystone service-list

As OpenStack is designed for global deployments, a region defines a physical datacenter or a geographical area that comprises of multiple connected datacenters. For our purpose, we define just a single region—RegionOne. This is an arbitrary name that we can reference when specifying what runs in what datacenter/area and we carry the region name through to when we configure our client for use with these regions.

All of our services can be configured to run on three different URLs, as follows, depending on how we want to configure our OpenStack cloud environment:

We will be using the keystone client to operate Keystone. If the python-keystoneclient tool isn't available, follow the steps described at http://bit.ly/OpenStackCookbookClientInstall.

Ensure that we have our environment set correctly to access our OpenStack environment for administrative purposes:

export OS_TENANT_NAME=cookbook
export OS_USERNAME=admin
export OS_PASSWORD=openstack
export OS_AUTH_URL=https://192.168.100.200:5000/v2.0/
export OS_NO_CACHE=1
export OS_KEY=/vagrant/cakey.pem
export OS_CACERT=/vagrant/ca.pem

vagrant ssh controller

To configure an appropriate service tenant, carry out the following steps:

Creation of the service tenant, which is populated with the services required to run OpenStack, is no different from creating any other users on our system that require the admin role. We create the usernames and passwords and ensure that they exist in the service tenant with the admin role assigned to each user. We then use these credentials when configuring the services to authenticate with the OpenStack Identity service.

We will be using the keystone client to operate Keystone. If the python-keystoneclient tool isn't available, follow the steps described at http://bit.ly/OpenStackCookbookClientInstall.

Ensure that we have our environment set correctly to access our OpenStack environment for administrative purposes:

export OS_TENANT_NAME=cookbook
export OS_USERNAME=admin
export OS_PASSWORD=openstack
export OS_AUTH_URL=https://192.168.100.200:5000/v2.0/
export OS_NO_CACHE=1
export OS_KEY=/vagrant/cakey.pem
export OS_CACERT=/vagrant/ca.pem

vagrant ssh controller

Additionally, to connect to an external LDAP service, you will need to possess the hostname or IP address of the LDAP server and have appropriate access to the server. You will also need to have the LDAP path information for an admin user, and for the Organizational Units that contain the Users, Roles, and Tenants.

To configure OpenStack Identity to communicate with LDAP, perform the following steps:

The OpenStack Identity service, like other OpenStack services, is based on plugins. In its default state, Keystone will store and access all user identity and authentication data from a SQL database. However, when integrating OpenStack into an existing environment, this is not always the most desirable or secure method. To accommodate this, we changed the identity back end to LDAP. This allows for integration with OpenLDAP, Active Directory, and many others. However, when configuring the backend, you need to pay special attention to the LDAP paths.

To begin with, ensure you're logged in to our OpenStack Controller host where OpenStack Image Service will be installed.

To log in to our OpenStack Controller host that was created using Vagrant, issue the following command:

vagrant ssh controller

Ensure that our Ubuntu 14.04 LTS release is using the Ubuntu Cloud Archive that has the packages required for the Juno release. For more information, visit http://bit.ly/OpenStackCookbookCloudArchive.

We will configure Glance to use MariaDB as the database backend, so this needs to be installed prior to installing Glance.

We will also need to have RabbitMQ installed as our message queue service, so this needs to also be installed prior to installing Glance.

The instructions in this section assume the controller node has two IP addresses. It will have a front-facing IP address 192.168.100.200 and a backside IP address 172.16.0.200 (which is also the address of the MariaDB server). It has two addresses because the internal data will communicate over the backside IP address (for example, database traffic) and any Glance traffic will traverse the front.

Carry out the following steps to install OpenStack Image Service:

Congratulations! We now have OpenStack Image service installed and ready for use in our OpenStack environment.

OpenStack Image Service is split into two running services: glance-api and glance-registry. It is the glance-registry service that connects to the database backend. The first step is to create our glance database and the glance user, so it can perform operations on the glance database that we have created.

Once this is done, we modify the /etc/glance/glance-registry.conf and /etc/glance/glance-api.conf files so that glance knows where to find and connect to our MySQL database. This is provided by the standard SQLAlchemy connection string that has the following syntax:

sql_connection = mysql://USER:PASSWORD@HOST/DBNAME

To begin with, ensure you're logged in to our OpenStack Controller host or the host that is running OpenStack Image Service. If the OpenStack Identity Service is not installed, carry out the steps in the Installing the OpenStack Identity Service recipe of Chapter 1, Keystone – OpenStack Identity Service. We also require that the Glance service user and endpoints have been set up. See the Defining Service Endpoints and Creating the service tenant and service users recipes of Chapter 1, Keystone – OpenStack Identity Service.

To log in to our OpenStack Controller host that was created using Vagrant, issue the following command:

vagrant ssh controller

To configure OpenStack Image Service to use OpenStack Identity Service, carry out the following steps:

OpenStack Image Service runs two services: glance-api, which is the service that our clients and services talk to, and the glance-registry service that manages the objects on the disk and database registry. Both of these services need to have matching credentials that were defined previously in OpenStack Identity Service in their configuration files in order to allow a user to authenticate with the service successfully.

To begin with, ensure you're logged in to our OpenStack Controller host or the host that is running OpenStack Image Service.

To log in to our OpenStack Controller host that was created using Vagrant, issue the following command:

vagrant ssh controller

To configure OpenStack Image Service to use OpenStack Object Storage, carry out the following steps:

OpenStack Image Service can be configured to use several different backend for storing images, such as Ceph, OpenStack Object Storage, and raw disk. Once Object Storage is configured as a backend, images will be uploaded to Swift instead of being stored locally. Check Chapter 5, Swift – OpenStack Object Storage on configuring and using Object Storage.

To begin with, ensure that you are either logged in to an Ubuntu client where we can run the glance tool, or on our OpenStack Controller where OpenStack Image Service is running directly. If the Glance client isn't installed, this can be installed using the following commands:

sudo apt-get update
sudo apt-get install python-glanceclient

Ensure that you have your environment variables set up correctly with our admin user and password, as created in the previous chapter:

export OS_TENANT_NAME=cookbook
export OS_USERNAME=admin
export OS_PASSWORD=openstack
export OS_AUTH_URL=https://192.168.100.200:5000/v2.0/
export OS_NO_CACHE=1
export OS_KEY=/vagrant/cakey.pem
export OS_CACERT=/vagrant/ca.pem

We can upload and view images in our OpenStack Image Service in a number of ways. Carry out the following steps to upload and show details of our uploaded images.

Listing images

To list the images in our OpenStack Image Service repository, we use the Glance client to interrogate the Image Service directly, or use the Nova client that is used to manage our OpenStack environment. This is covered in Chapter 4, Nova – OpenStack Compute.

To list the images available to our user using the Glance client, we issue the following command:

glance image-list

The preceding command produces a result like this:

glance image-show IMAGE_ID

glance image-show 18584bff-2c12-4c2d-85f6-59771073c936

OpenStack Image Service is a very flexible system for managing images in our private cloud environment. It allows us to modify many aspects of our OpenStack Image Service registry—adding new images, deleting them, updating information, such as the name that is used so that end users can easily identify them, and making private images public or vice-versa.

To do all this, we use the glance tool from any connected client.

To begin with, ensure you are logged in to our Ubuntu client where we can run the glance tool. This can be installed using the following command:

sudo apt-get update
sudo apt-get install python-glanceclient

Ensure that you have your environment variable set up correctly with our admin user and password, as created in the previous chapter:

export OS_TENANT_NAME=cookbook
export OS_USERNAME=admin
export OS_PASSWORD=openstack
export OS_AUTH_URL=https://192.168.100.200:5000/v2.0/
export OS_NO_CACHE=1
export OS_KEY=/vagrant/cakey.pem
export OS_CACERT=/vagrant/ca.pem

Carry out the following steps to remotely store an image in our OpenStack Image Service:

Using the glance tool to specify remote images directly provides a quick and convenient way to add images to our OpenStack Image Service repository. The way this happens is with the location parameter. We add in our usual meta information to accompany this, as we would with a locally-specified image.

To begin with, ensure you are logged in to our Ubuntu client where we can run the glance tool. This can be installed using the following command:

sudo apt-get update
sudo apt-get install glance-client

Ensure that you have your environment variable set up correctly with our admin user and password, as created in the previous chapter:

export OS_TENANT_NAME=cookbook
export OS_USERNAME=admin
export OS_PASSWORD=openstack
export OS_AUTH_URL=https://192.168.100.200:5000/v2.0/
export OS_NO_CACHE=1
export OS_KEY=/vagrant/cakey.pem
export OS_CACERT=/vagrant/ca.pem

Carry out the following steps to share a private image in our cookbook tenant to another tenant:

The member-create option for the glance command allows us to share images with other tenants. The syntax is as follows:

glance [--can-share] member-create image-id tenant-id

The preceding command comes with an optional extra parameter, --can-share, that gives permission to that tenant to share the image.

To begin with, ensure that you are logged in to our Ubuntu client where we can run the glance tool. This can be installed using the following command:

sudo apt-get update
sudo apt-get install python-glanceclient

Ensure that you have your environment variable set up correctly with our admin user and password, as created in the previous chapter:

export OS_TENANT_NAME=cookbook
export OS_USERNAME=admin
export OS_PASSWORD=openstack
export OS_AUTH_URL=https://192.168.100.200:5000/v2.0/
export OS_NO_CACHE=1
export OS_KEY=/vagrant/cakey.pem
export OS_CACERT=/vagrant/ca.pem

Carry out the following steps to view the images that have been shared for a particular tenant:

The member-list option in the glance command allows us to view which images have been shared with other tenants. The syntax is as follows:

glance member-list --image-id IMAGE_ID
glance member-list –-tenant-id TENANT_ID

To begin with, ensure you are logged in to our Ubuntu client where we can run the glance tool. This can be installed using the following command:

sudo apt-get update
sudo apt-get install python-glanceclient

Ensure that you have your environment variable set up correctly with our admin user and password, as created in the previous chapter:

export OS_TENANT_NAME=cookbook
export OS_USERNAME=admin
export OS_PASSWORD=openstack
export OS_AUTH_URL=https://192.168.100.200:5000/v2.0/
export OS_NO_CACHE=1
export OS_KEY=/vagrant/cakey.pem
export OS_CACERT=/vagrant/ca.pem

Image metadata can be added, updated, and deleted, as well as used for host scheduling.

The glance image-update option in the glance command allows us to add, modify, and remove custom image properties. The syntax is as follows:

glance image-create [other options] --property <key=value>
glance image-update IMAGE_ID --property <key=value>

To begin with, ensure you are logged in to our Ubuntu client where we will be doing the image conversion. Make sure you have qemu-util installed; if not, you may install it using the following:

sudo apt-get install qemu-utils

Carry out the following steps to convert a VMDK image to the QCOW2 format:

The qemu-img convert command-line tool works on multiple formats, including VMDK. Conversion to VMDK or other desired formats would work as well. Since the QCOW format supports image compression, it can be useful to get a smaller image which then can grow.

To begin with, ensure you are logged in to a Linux system that is not your OpenStack environment.

On Ubuntu, install the kvm/qemu and libvirt libraries:

sudo apt-get install qemu-kvm libvirt-bin virt-manager

Start the libvirt-bin service with the following command:

sudo start libvirt-bin

On CentOS or RHEL:

sudo yum groupinstall "Virtualization" "Virtualization Platform"
sudo chkconfig libvirtd on  
sudo service libvirtd start

On Fedora:

sudo yum groupinstall "Virtualization" "Virtualization Platform"
sudo systemctl enable libvirtd  
sudo systemctl start libvirtd

Ideally, you will also need a VNC client, though our example could be done without using one.

Carry out the following steps to create a custom image:

The qemu-img convert command-line tool works on multiple formats, including VMDK. Conversion to VMDK or other desired formats would work as well. Since the QCOW format supports image compression, it can be useful to get a smaller image that can grow later.

Ensure that you have a suitable server available for installation of the OpenStack network components. If you are using the accompanying Vagrant environment, this will be the network node that we will be using.

Ensure that you are logged in to the network node and that it has Internet access to allow us to install the required packages in our environment for running OVS and Neutron. If you created this node with Vagrant, you can execute the following command:

vagrant ssh network

To configure our OpenStack network node, carry out the following steps:

We have completed the installation of the packages on a new node in our environment that runs the software networking components of our SDN environment. This includes the OVS service through the ML2 Neutron plugin system and various Neutron components that interact with this. While we have used OVS in our example, there are many vendor plugins that include Nicira and Cisco UCS/Nexus among others. More details on the plugins that Neutron supports can be found at https://wiki.openstack.org/wiki/Neutron.

First, we configured our interface on this switch node that will serve as our tenant Neutron and External networks. The External network in OpenStack terms is often referred to as the Provider Network. On a physical server in a datacenter, this externally bridged interface (br-ex) will be connected to the network that routes to the rest of our physical servers. The assignment of this network is described in the recipe Creating an external Floating IP Neutron network. Both of the interfaces used by Neutron are created without an IP address so that our OpenStack environment can control this by bridging new networks to it. We assign IP addresses to the bridges themselves to create tunnels between these IP endpoints that have overlay networks created on them. It is these networks created within the tunnels that our instances get attached to in OpenStack.

A number of packages were installed on this network node. The list of packages that we specify for installation (excluding dependencies) is as follows:

Ensure that you have a suitable server available for installation of the OpenStack network components. If you are using the accompanying Vagrant environment, this will be the network node that we will be using.

Ensure that you are logged in to the network node and it has the required packages in our environment for running OVS and Neutron. If you created this node with Vagrant, you can execute the following command:

vagrant ssh network

To configure OVS and Neutron on our OpenStack network node, carry out the following steps:

We completed the configuration of a new node in our environment that runs the software networking components of our SDN environment.

Once we installed our applications and service dependencies and started the services, we configured our environment by assigning a bridge that acts as the integration bridge that internally bridges our instances with the rest of the network. It also connects bridges to our interfaces on the Tenant and Provider networks.

We then edit a number of files to get Neutron up-and-running in our environment. The first is the /etc/neutron/neutron.conf file. This is the main configuration file for our Neutron services. In this file, we define how Neutron is configured and what components, features, and plugins should be used.

In the /etc/neutron/l3_agent.ini file, we specify that we are allowing tenants to create overlapping IP ranges (use_namespaces = True). This means that Tenant A users can create and use a private IP CIDR that also exists within Tenant B. We also specify that we are to use OVS to provide L3 routing capabilities.

The /etc/neutron/dhcp_agent.ini file specifies that we are going to use Dnsmasq as the service for DHCP within our environment. We also reference the /etc/neutron/dnsmasq-neutron.conf file, which allows us to pass extra options to Dnsmasq when it starts up processes for that network. We do this so we can specify an MTU of 1400 that gets set on the instance network interfaces. This is because the default of 1500 conflicts with the extra bytes that tunneling adds to the packets and its inability to handle fragmentation. By lowering the MTU, all the normal IP information plus the extra tunneling information can be transmitted at once without fragmentation.

The /etc/neutron/metadata_agent.ini file notifies Neutron and our instances where to find the metadata service. It points to our controller node and ultimately the nova API service. Here, we set a secret key as described in the metadata_proxy_shared_secret = foo line that matches the same random keyword that we will eventually configure in /etc/nova/nova.conf on our controller node: neutron_metadata_proxy_shared_secret=foo.

The last configuration file, /etc/neutron/plugins/ml2/ml2_conf.ini, configures the L2 plugins within our environment and describes our L2 capabilities. The configuration options are as follows:

[ml2]
type_drivers = gre,vxlan
tenant_network_types = vxlan
mechanism_drivers = openvswitch

We're configuring our networking type to be either Generic Routing Encapsulation (GRE) or Virtual eXtensible LAN (VXLAN) tunnels. This allows our SDN environment to capture a wide range of protocols over the tunnels we create.

We specify that VXLAN tunnels are to be created when a non-admin user creates their own private Neutron networks. An admin user is able to specify GRE as an option on the command line:

[ml2_type_gre]
tunnel_id_ranges = 1:1000

This specifies that, when a user specifies a private Neutron tenant network without specifying an ID range for a GRE network, an ID is taken from this range. OpenStack ensures that each tunnel created is unique. The code is as follows:

[ml2_type_vxlan] 
vxlan_group =
vni_ranges = 1:1000

[vxlan]
enable_vxlan = True
vxlan_group = 
local_ip = 10.10.0.201 
[agent]
tunnel_types = vxlan
vxlan_udp_port = 4789

The preceding sections describe our VXLAN options. In the same way as for GRE, we have an endpoint IP that is the IP assigned to the interface that we want tunneled traffic to flow over, and we specify the valid vxlan IDs to use within our environment. The code is as follows:

[ovs]
local_ip = 10.10.0.201
tunnel_type = gre
enable_tunneling = True

The preceding section describes the options to pass to OVS, and details our tunnel configuration. Its endpoint address is 10.10.0.201 and we're specifying the tunnel type GRE to be used. The code is as follows:

[securitygroup]
firewall_driver = neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver
enable_security_group = True

The preceding code tells Neutron to use IPtables rules when creating security groups.

Ensure you have a suitable server available for installation of the OpenStack network components. If you are using the accompanying Vagrant environment, this will be the controller node that we will be using.

Ensure you are logged in to the controller node. If you created this node with Vagrant, you can execute the following command:

vagrant ssh controller

To configure our OpenStack Controller node for Neutron, carry out the following steps:

Configuring our Neutron API service on the controller node is very straightforward with the right information at hand. We install a couple of required packages.

Use the following commands to install the Neutron package:

neutron-server
neutron-plugin-ml2

Once the Neutron package is installed, we configure the /etc/neutron/neutron.conf file that matches our network node config, with only one new section: the neutron nova interaction section. Here, we ensure correct settings to allow nova to interoperate with Neutron. We also configure the ML2 plugin file that also matches our network node, but we can omit the OVS section because it is surplus on our controller node.

We then run a command to ensure that our Neutron database has the correct rows and columns for use with the OpenStack Juno release.

Finally, we configure /etc/nova/nova.conf, which is the most important configuration file for our OpenStack Compute services:

Ensure you have a suitable client available for using Neutron. If you are using the accompanying Vagrant environment, you can use the controller node. This has the python-neutronclient package that provides the neutron command-line client.

If you created this node with Vagrant, you can execute the following command:

vagrant ssh controller 

Ensure you have the following credentials set (adjust the path to your certificates and key file to match your environment if not using the Vagrant environment):

export OS_TENANT_NAME=cookbook
export OS_USERNAME=admin
export OS_PASSWORD=openstack
export OS_AUTH_URL=https://192.168.100.200:5000/v2.0/
export OS_NO_CACHE=1
export OS_KEY=/vagrant/cakey.pem
export OS_CACERT=/vagrant/ca.pem

To create a private Neutron network for a particular tenant, follow these steps:

We created a network with a defined subnet that our VMs utilize when they start up. To create a network, the following syntax is used:

neutron net-create \
  --tenant-id TENANT_ID \
  NAME_OF_NETWORK

To create a subnet, the following syntax is used:

neutron subnet-create \
  --tenant-id TENANT_ID \
  --name NAME_OF_SUBNET \
  NAME_OF_NETWORK \
  CIDR 

Routers are optional on networks and the function is to route traffic from one subnet to another. In a Neutron SDN, this is no different. Layer 3 (L3) Routers allow you to configure gateways and routes to other networks on-demand. If we only require our instances to communicate between each other on the same subnet, there is no need to have a router because there will be no other network that needs to be routed to or from. The syntax to create routers is as follows:

neutron router-create \
  --tenant-id TENANT_ID \
  NAME_OF_ROUTER 

The syntax to add the router to our Subnet (used to allow routes from one network (physical or software-defined)) is as follows:

neutron router-interface-add \
  ROUTER_NAME \
  SUBNET_NAME 

We can then add further subnets using the preceding syntax to this router and allow traffic to flow between instances on different OpenStack Neutron-created subnets.

Ensure that you have a suitable client available for using Neutron. If you are using the accompanying Vagrant environment, you can use the controller node. This has the python-neutronclient package that provides the neutron command-line client.

If you created this node with Vagrant, you can execute the following command:

vagrant ssh controller 

Ensure you have the following credentials set (adjust the path to your certificates and key file to match your environment if not using the Vagrant environment):

export OS_TENANT_NAME=cookbook
export OS_USERNAME=admin
export OS_PASSWORD=openstack
export OS_AUTH_URL=https://192.168.100.200:5000/v2.0/
export OS_NO_CACHE=1
export OS_KEY=/vagrant/cakey.pem
export OS_CACERT=/vagrant/ca.pem

To delete a Neutron network for a particular tenant, follow these steps:

In the preceding steps, we performed a series of steps to remove a network. This involves first removing any (virtual) devices attached to this network such as instances and routers, removing the subnet that has been attached to that network, and removing the underlying network itself. Let's see the net list:

Ensure that you have a suitable client available for using Neutron. If you are using the accompanying Vagrant environment, you can use the controller node. This has the python-neutronclient package installed that provides the neutron command-line client.

If you created this node with Vagrant, you can execute the following command:

vagrant ssh controller 

Ensure you have the following credentials set (adjust the path to your certificates and key file to match your environment if not using the Vagrant environment):

export OS_TENANT_NAME=cookbook
export OS_USERNAME=admin
export OS_PASSWORD=openstack
export OS_AUTH_URL=https://192.168.100.200:5000/v2.0/
export OS_NO_CACHE=1
export OS_KEY=/vagrant/cakey.pem
export OS_CACERT=/vagrant/ca.pem

To create an external router on our Neutron network for a particular tenant, we need to have tenant admin privileges. We will first create a public network in our admin tenant and then attach this to a tenant's router that requires external access to our instances. This will be achieved by assigning of a floating IP to the instance.

Once our environment has been set correctly with admin privileges, follow these steps:

We have created a network that allows us to assign floating addresses to our instances. This subnet is routable from the rest of the network outside OpenStack, or a public address space directly on the Internet. To do this, we first create a network in an admin tenant that can have a gateway set by using the --router:external=True flag to our neutron net-create command:

neutron net-create \
  --tenant-id ADMIN_TENANT_ID \
  --router:external=True \
  NAME_OF_EXTERNAL_NETWORK

As we will be configuring addresses manually to allow us to assign floating IP addresses to instances, we specify a subnet where we define the range of IP addresses but disable DHCP:

neutron subnet-create \
  --tenant-id ADMIN_TENANT_ID \
  --name NAME_OF_SUBNET \
  --allocation-pool start=IP_RANGE_START,end=IP_RANGE_END \
  --enable_dhcp=False \
 EXTERNAL_NETWORK_NAME \
  SUBNET_CIDR

We assign a router gateway to the network by issuing the following command on an existing router on our network. This router then provides the appropriate NAT when we assign this to an instance on the private network connected to that router:

neutron router-gateway-set \
  ROUTER_NAME \
  EXTERNAL_NETWORK_NAME

Once configured, we can now allocate a floating IP address from this new range to our running instance. To do this, we run the following command:

nova list

Get the IP address of our running instance using the following command:

neutron router-show ROUTER_NAME

To get the ports in use on our router, use the following command:

neutron port-list \
  --router_id=ROUTER_ID

To create a floating IP for our use from our external network, use the following command (note the tenant ID doesn't have to be the admin tenant as used in the example):

neutron floatingip-create \
  --tenant-id=TENANT_ID \
  EXTERNAL_NETWORK_NAME

To associate the Floating IP to the instance, we use the port ID associated with the instance (as shown in the port listing on our router):

neutron floatingip-associate \
  FLOATING_IP_ID \
  VM_PORT_ON_ROUTER

At this point, we can access this instance from our physical network on this floating IP address.

Ensure that you are logged in to both the Network and Compute nodes, as we will be configuring a new interface for use with OpenStack Networking on each. If you created these nodes with Vagrant, you can execute the following command:

vagrant ssh network
vagrant ssh compute

As we will be utilizing the Neutron client too, log in to the controller node (or a suitable computer that has the python-neutronclient available). If you created these nodes with Vagrant, you can execute the following command:

vagrant ssh controller

Ensure that you have set the following credentials (adjust the path to your certificates and key file to match your environment if not using the Vagrant environment):

export OS_TENANT_NAME=cookbook
export OS_USERNAME=admin
export OS_PASSWORD=openstack
export OS_AUTH_URL=https://192.168.100.200:5000/v2.0/
export OS_NO_CACHE=1
export OS_KEY=/vagrant/cakey.pem
export OS_CACERT=/vagrant/ca.pem

An example environment might have a tenant Neutron network configured such that the tunneling occurs over 1G interfaces; in our environment, this could be our eth2 bridge, br-eth2. The environment can also utilize any number of network interfaces that might route to different devices or be cabled up to different segments of the network. In OpenStack networking, we create new bridges that Neutron knows about that an administrator can use when creating networks.

As an administrator of the tenant, carry out the following instructions to set up this new interface bridge and specify a Neutron network, of type VLAN, that allows us to communicate with the physical servers on 192.168.200.0/24:

We can now spin up OpenStack instances using this network, defined as sqlServerNet on the subnet 192.168.200.0/24, that can communicate with physical servers on the same subnet.

We created another interface bridge on our Compute and network nodes that we can then use when creating VLAN Neutron networks. By using VLAN networks in this way with OpenStack, we can set up communication between our OpenStack Compute cloud environment and physical servers on that same Subnet and VLAN.

To do this, we ensured that our new eth4 interface was set to promiscuous mode and we created a bridge called br-eth4 within OVS. This bridge is then referenced in the /etc/neutron/plugins/ml2/ml2_conf.ini file within the [ovs] section, as shown here:

[ovs]
bridge_mappings = physnet4:br-eth4

We assign a mapping between that bridge and a name we can use on the neutron command line when specifying it for use, as shown in the following neutron net-create command:

neutron net-create sqlServerNet \
    --provider:physical_network=physnet4 \
    --provider:network_type=vlan \
    --provider:segmentation_id=200 \
    --shared

As you can see, we also specify that we are creating a network of type vlan and we are assigning the VLAN ID 200.

Finally, as we are creating this as an admin user, the --shared flag allows us to ensure that this network is available to all tenants.

With this network in place, we assign the relevant subnet associated with the VLAN and restrict the DHCP range to avoid conflict with the other part of this subnet. We do this within the neutron subnet-create command by specifying the --allocation-pool flag as shown here:

neutron subnet-create sqlServerNet 192.168.200.0/24 \--name sqlServerSubnet \--allocation-pool start=192.168.200.201,end=192.168.200.240 \
    --gateway 192.168.200.1

We only allow OpenStack to spin up instances between the IP addresses 192.168.200.201 and 192.168.200.240.

To demonstrate the features of DVR, we naturally require more than one Compute host in our environment. Ensure that you have a second Compute host that has been configured for Neutron networking. Complete installation instructions for Compute hosts can be found in the next chapter.

If you are using the accompanying Vagrant environment, ensure that the second compute host, compute2, is running in our environment. Edit the Vagrant file, to ensure that compute2 is available.

Ensure that you are logged in to the network, compute, compute2, and controller nodes as we will be configuring configuration files for DVR on all of these nodes. If you created these nodes with Vagrant, you can execute the following commands in separate shells:

vagrant ssh controller
vagrant ssh network
vagrant ssh compute
vagrant ssh compute2

To set up DVR, we make small adjustments in a number of Neutron configuration files in our environment. These are described in the following sections.

We modified a typical Neutron installation to add DVR capabilities. This moves L2 Plugin and L3 Agents to our Compute hosts so that instances running on that Compute host utilize that L3 router agent as their router, rather than an L3 router running centrally on the network nodes. We are performing steps similar to the ones we used to set up a network node, but replicating these steps on our Compute hosts. This makes sense as we're adding in routing capabilities that were previously possessed only by our Network host in Legacy L3 Routing mode.

The key steps were as follows:

Ensure that you have a suitable client available for using Neutron. If you are using the accompanying Vagrant environment, you can use the controller node. This has the python-neutronclient package that provides the neutron command-line client.

If you created this node with Vagrant, you can execute the following command:

vagrant ssh controller

Ensure that you have the following credentials set (adjust the path to your certificates and key file to match your environment if not using the Vagrant environment):

export OS_TENANT_NAME=cookbook
export OS_USERNAME=admin
export OS_PASSWORD=openstack
export OS_AUTH_URL=https://192.168.100.200:5000/v2.0/
export OS_NO_CACHE=1
export OS_KEY=/vagrant/cakey.pem
export OS_CACERT=/vagrant/ca.pem

In this section, we will create and view the details of a DVR mode router and see how these present themselves to our Compute hosts. The steps are as follows:

We discussed a few steps to highlight the difference when running routers in distributed mode. By default, due to the setting in distributed /etc/neutron/neutron.conf where we set router_distributed = True, any routers we normally create will be created on our distributed Compute hosts. To troubleshoot them, we can connect to our Compute hosts and view the namespaces created.

Ensure that you are logged in to the OpenStack controller node. If you used Vagrant to create this, as described in Chapter 1, Keystone – OpenStack Identity Service, we can access this with the following command:

vagrant ssh controller

Installation of OpenStack under Ubuntu 14.04 is simply achieved using the apt-get tool, as the OpenStack packages are available from the Ubuntu Cloud Archive repositories.

We can install the required packages with the following command:

sudo apt-get update
sudo apt-get install nova-api \
    nova-conductor nova-scheduler nova-objectstore

Installation of OpenStack Compute controller packages from the Ubuntu Cloud Archive package repository represents a very straightforward and well-understood way of getting the latest OpenStack onto our Ubuntu server. This adds a greater level of certainty around stability and upgrade paths by not deviating away from the main archives.

Ensure that you are logged in to the server that you will install as the Openstack Compute node. This should be a server running Ubuntu 14.04 LTS, and it should have networking configured, as shown in the figure in the Introduction section of this chapter.

Once logged in to the node where you plan to install the OpenStack Compute services, proceed with the following steps:

Installation of OpenStack Compute from the Ubuntu Cloud Archive package repository represents a very straightforward and well-understood way of getting the latest OpenStack onto our Ubuntu server. This adds a greater level of certainty around stability and upgrade paths by not deviating away from the main archives.

There are various ways to install OpenStack, from source code building to installation from packages, but this represents the easiest and most consistent method available. There are also alternative releases of OpenStack available. By using the Ubuntu Cloud Archive, we are able to use various releases on our Ubuntu 14.04 LTS platform.

sudo apt-get update
sudo apt-get install software-properties-common python-software-properties

sudo add-apt-repository cloud-archive:kilo

We will configure our OpenStack controller services to use MariaDB as the database backend, so this needs to be installed prior to configuring our OpenStack Compute environment.

If you are not already logged into the OpenStack Controller, ssh into it now.

To use OpenStack Compute (Nova), we first need to ensure that our backend database has the required nova database. To create this, perform the following steps on our controller host running MySQL:

MySQL is an essential service to OpenStack as a number of services rely on it. Configuring MySQL appropriately ensures your servers operate smoothly. We added in a database called nova that will eventually be populated by tables and data from the OpenStack Compute services, and granted all privileges to the nova database user so that user can use it. Finally, we configured our OpenStack.

Compute installation to specify these details so they can use the nova database.

We will be configuring the /etc/nova/nova.conf file on both the Controller host and Compute host.

If you are using the Vagrant environment provided with this book, log in to our OpenStack Controller and Compute hosts using the following commands:

vagrant ssh controller
vagrant ssh compute-01

To run our sandbox environment, we will configure OpenStack Compute so that it is accessible from our underlying host computer. We will have the API service (the service our client tools talk to) listen on our public interface and configure the rest of the services to run on the correct ports. The complete nova.conf file, as used by the sandbox environment, is laid out next and an explanation of each line (known as flags) follows:

The /etc/nova/nova.conf file is an important file in our OpenStack Compute environment and the same file is used on all compute and controller nodes. We create this once and then we ensure this is present on all of our nodes. The following flags are present in our /etc/nova/nova.conf configuration file:

After changing configuration options, we will need to restart the Nova services. We will show you how to do so in the Stopping and starting Nova services recipe.

There are a wide variety of options that are available for configuring OpenStack Compute. These will be explored in more detail in later chapters as the nova.conf file underpins most of OpenStack Compute services.

To begin with, ensure that you’re logged in to our OpenStack compute and Controller hosts. If you did this through Vagrant, you can log in with the following commands in separate shells:

vagrant ssh controller
vagrant ssh compute-01

Configuring the authentication mechanism in our OpenStack Compute sandbox environment is achieved with the following steps:

Configuration of OpenStack Compute to use OpenStack Identity Service is done on all hosts in our environment running OpenStack Compute (Nova) services (for example, the Controller and Compute hosts). This first involves editing /etc/nova/nova.conf file, and adding the credentials and Keystone details.

We then configure the /etc/nova/api-paste.ini file and fill the [filter:keystonecontext] and [filter:authtoken] parts of the file with details of the keystone factory.

If you haven’t done so already, ssh to our OpenStack controller and OpenStack Compute virtual machines. If you created these using Vagrant, you can log in to these using the following commands in separate shells:

vagrant ssh controller
vagrant ssh compute-01

This ensures that we can access our virtual machines, as we will need access to spin up instances from your personal computer. Let’s see the OpenStack services that we have running as part of our sandbox environments.

Carry out the following steps to stop the OpenStack Compute services that we have running:

Stopping and starting OpenStack Compute services under Ubuntu are controlled using upstart scripts. This allows us to simply control the running services by the start and stop commands, followed by the service we wish to control.

The tools will be installed on your host computer if it’s running Ubuntu, which is the easiest way to get hold of the nova client packages that are ready to manage your cloud environment.

The nova client packages are conveniently available from the Ubuntu repositories. If the host PC isn’t running Ubuntu, creating an Ubuntu virtual machine alongside our OpenStack Compute virtual machine is a convenient way to get access to these tools.

As a normal user on our Ubuntu machine, type the following commands:

sudo apt-get update
sudo apt-get install python-novaclient

Using nova client on Ubuntu is a very natural way of managing our OpenStack cloud environment. Installation is very straightforward as these are provided as part of standard Ubuntu packaging.

The tools will be installed on your host computer if it’s running Ubuntu, which is the easiest way to get hold of the nova client packages ready to manage your cloud environment. If using our Vagrant lab environment, self-signed certificates are installed and set up for using with HTTPS endpoints. We recommend that you use certificates issued by a trusted Certificate Authority (CA) for your production environment.

The nova client packages are conveniently available from the Ubuntu repositories. SSL certificates are already installed and configured for use by Keystone for validation.

Using nova client on Ubuntu is a very natural way to manage our OpenStack cloud environment. However, if your authentication endpoints are setup to use HTTPS, you will need to point your command-line client to the certificates installed on your system. Adding environment variables to point to certificates will automatically validate against them.

Log in to the OpenStack controller node. If you used Vagrant to create this node, log in to it using the following command:

vagrant ssh controller

To check whether the OpenStack Compute services are running, we invoke the nova-manage tool and ask it various questions of the environment as follows:

We have used some basic commands that communicate with OpenStack Compute and other services to show they are running. This elementary level of troubleshooting ensures you have the system running as expected:

To begin with, log in to an Ubuntu client and ensure that Nova client is available. If it isn’t, it can be installed as follows:

sudo apt-get update
sudo apt-get python-novaclient

To use OpenStack Identity Service as the authentication mechanism in our OpenStack environment, we need to set our environment variables accordingly. For our demo user, this is achieved as follows:

Configuring our environment to use OpenStack Identity Service for authentication for Nova client, so that we can launch our instances, involves manually creating an environment resource file with the appropriate environment variables in.

Our environment passes on our username, password, and tenant to OpenStack Identity Service for authentication and passes back—behind the scenes—an appropriate token that validates our user. This allows us to seamlessly spin up instances within our tenancy (project) of cookbook.

To begin with, ensure that you’re logged in to a client that has access to the Nova client tools. These packages can be installed using the following commands:

sudo apt-get update
sudo apt-get install python-novaclient

And ensure you have set the following credentials:

export OS_TENANT_NAME=cookbook
export OS_USERNAME=admin
export OS_PASSWORD=openstack
export OS_AUTH_URL=https://192.168.100.200:5000/v2.0/
export OS_NO_CACHE=1
export OS_KEY=/vagrant/cakey.pem
export OS_CACERT=/vagrant/ca.pem

The following sections describe how to create and modify security groups in our OpenStack environment.

nova secgroup-create webserver “Web Server Access”
nova secgroup-add-rule webserver tcp 80 80 0.0.0.0/0
nova secgroup-add-rule webserver tcp 443 443 0.0.0.0/0

nova boot myInstance \
    --image 0e2f43a8-e614-48ff-92bd-be0c68da19f4 
    --flavor 2 \
    --key_name demo \
    --security_groups default,webserver

nova secgroup-delete-rule webserver tcp 443 443 0.0.0.0/0

nova secgroup-delete webserver

Creation of a security group is done in just two steps. We add a group using the nova secgroup-create command. Following the creation of a security group, we can define rules in that group using the nova secgroup-add-rule command. With this command, we can specify the destination ports that we can open up on our instances and the networks that are allowed access.

nova secgroup-create group_name “description”

nova secgroup-add-rule group_name protocol port_from port_to source

To begin with, ensure that you are logged in to your Ubuntu client that has access to the Nova client tools. This can be installed using the following commands:

sudo apt-get update
sudo apt-get install python-novaclient

Ensure you have set the following credentials:

export OS_TENANT_NAME=cookbook
export OS_USERNAME=admin
export OS_PASSWORD=openstack
export OS_AUTH_URL=https://192.168.100.200:5000/v2.0/
export OS_NO_CACHE=1
export OS_KEY=/vagrant/cakey.pem
export OS_CACERT=/vagrant/ca.pem

To create a key pair, we use the nova keypair-add command. We name the key accordingly, and we will subsequently refer to it when launching instances. The output of the command is the SSH private key that we will use to access a shell on our instance:

This preceding command has generated a key pair and stored the public portion within our database, at the heart of our OpenStack environment. The private portion has been written to a file on our client, which we will protect by making sure that only our user can access this file.

When we want to use this new key under Nova client, this looks as follows, using the nova boot command:

nova boot myInstance \
    --image 0e2f43a8-e614-48ff-92bd-be0c68da19f4 \
    --flavor 2 --key_name demokey

When we want to run the ssh instance, we specify the private key on the ssh command line with the -i option:

ssh ubuntu@172.16.1.1 -i demokey

nova keypair-list

+---------+-------------------------------------------------+
| Name    | Fingerprint                                     |
+---------+-------------------------------------------------+
| demokey | 77:ad:94:d6:8b:c6:d8:45:85:55:22:2b:ad:b3:22:e9 |
+---------+-------------------------------------------------+

Key pairs are important in our cloud environment as most Linux images don’t allow access to a command-line prompt using usernames and passwords. An exception to this is the Cirros image, which comes with a default username cirros and password cubswin:).

The Cirros image is a cut down image that is used for troubleshooting and testing OpenStack environments. Images like Ubuntu only allow access using key pairs.

Creation of a key pair allows us SSH access to our instance and it is carried out using the nova keypair-add command. This stores the public key in our backend database store that will be injected into the .ssh/authorized_keys file on our cloud instance, as a part of the cloud instance’s boot/cloud init script. We can then use the private key that gets generated to access the system by specifying this on the ssh command line with the -i option.

We can, of course, also remove keys from our project, and we do this to prevent further access by that particular key pair. The command nova keypair-delete does this for us, and we can verify which keys are available in our project by running the nova keypair-list commands.

The following steps are to be carried out on our network node under the user that has access to our OpenStack Compute credentials (as created in the Installation of command-line tools on network recipe).

Ensure you are logged in to the network node and that it has Internet access to allow us to install the required packages in our environment for running OVS and Neutron. If you created this node with Vagrant, you can execute the following command:

vagrant ssh network

Before we spin up our first instance, we must create the default security settings that define the access rights. We do this only once (or when we need to adjust these) using the nova secgroup-add-rule command under Nova client. The following set of commands gives us SSH access (port 22) from any IP address and also allows us to ping the instance to help with troubleshooting. Note the default group and its rules are always applied if no security group is mentioned on the command line.

The steps are as follows:

Now that our environment is set up correctly, we carry out the following steps to launch our first instance:

Congratulations! We have successfully launched and connected to our first OpenStack cloud instance.

After creating the default security settings, we made a note of our machine image identifier, UUID value, and then called a tool from Nova client to launch our instance. Part of that command line refers to the key pair to use. We then connect to the instance using the private key as part of that key pair generated.

How does the cloud instance know what key to use? As part of the boot scripts for this image, it makes a call back to the meta-server, which is a function of the nova-api and nova-api-metadata services. The meta-server provides a go-between that bridges our instance and the real world that the Cloud init boot process can call. In this case, it downloads a script to inject our private key into the Ubuntu user’s .ssh/authorized_keys file. We can modify which scripts are called during this boot process, and this will be covered later on.

When a cloud instance is launched, it generates a number of useful metrics and details about that instance. This is presented by the nova list and nova show commands. The nova list command shows a convenient short version listing the ID, name, status, and IP addresses of our instance.

The type of instance we chose was specified as an ID of 2 when using the nova boot command. The instance types supported can be listed by running the following command:

nova flavor-list

These flavors (specification of instances) are summarized as follows:

If you are using the Vagrant environment, these steps are to be carried out on our network node under the user that has access to our OpenStack Compute credentials (as created in the Installation of command-line tools on network recipe).

Ensure that you are logged onto the network node and that it has Internet access to allow us to install the required packages in our environment for running OVS and Neutron. If you created this node with Vagrant, you can execute the following command:

vagrant ssh network

From our network machine, list the running instances to identify the instance you want to fix using the following steps:

We identify a server that needs rescuing via the nova list command. Then, we use either the server name or the server ID to set the server in rescue mode using the nova rescue command. This reboots the server into a rescue mode, which starts the machine from the initial image and attaches the current boot disk as a secondary. After repairing the server, we need to set it back to ACTIVE status and reboot by using the nova unrescue command.

From our Ubuntu machine, list the running instances to identify the instance you want to terminate:

We simply identify the instance we wish to terminate by its UUID or by name when using nova list. Once identified, we can specify this as the instance to terminate using nova delete. Once terminated, that instance no longer exists—it has been destroyed. So if you had any data in there, it will be deleted along with the instance.

Let’s assume that you have more than one host running the Nova Compute services, as described in the Configuring OpenStack Compute section. If that is not the case, you will need to configure a second host before continuing. The destination host also needs to be remotely accessible and have resources available to run the instance(s) that will be migrated.

$ ping compute-02
PING compute-02.book (192.168.100.203) 56(84) bytes of data.
64 bytes from compute-02.book (192.168.100.203): icmp_seq=1 ttl=64 time=2.14 ms
64 bytes from compute-02.book (192.168.100.203): icmp_seq=2 ttl=64 time=0.599 ms
$ ping compute-01
PING compute-01.book (192.168.100.202) 56(84) bytes of data.
64 bytes from compute-01.book (192.168.100.202): icmp_seq=1 ttl=64 time=1.29 ms
64 bytes from compute-01.book (192.168.100.202): icmp_seq=2 ttl=64 time=0.389 ms

$ nova host-describe compute-02
+------------+------------+-----+-----------+---------+
| HOST       | PROJECT    | cpu | memory_mb | disk_gb |
+------------+------------+-----+-----------+---------+
| compute-02 | (total)    | 2   | 3107      | 37      |
| compute-02 | (used_now) | 0   | 512       | 0       |
| compute-02 | (used_max) | 0   | 0         | 0       |
+------------+------------+-----+-----------+---------+

If you are not already logged into a host with the Nova command-line utilities, you will need to be before proceeding. To migrate a VM-based instance between nodes, run the following commands:

export OS_TENANT_NAME=cookbook
export OS_USERNAME=admin
export OS_PASSWORD=openstack
export OS_AUTH_URL=https://192.168.100.200:5000/v2.0/

nova live-migration --block-migrate <UUID> compute-02

Live migration is an essential feature that enables OpenStack operators and administrators to perform maintenance of the underlying cloud infrastructure without affecting the consumers of said cloud. Additionally, the OpenStack administrator can use telemetry data from Ceilometer and make live-migration decisions to balance workloads across the OpenStack cloud.

Live-migration in OpenStack is handled by the libvirt drivers. Specifically, when you issue the nova live-migration command, OpenStack compute creates a connection from libvirtd on one compute host to the same process on the remote host. Once this connection is established, depending on the parameters you specified, the memory state of the instance is synchronized and control is transferred. In our example, we specified the additional --block-migrate parameter, which handles the movement of the instance’s disk files in the absence of shared storage.

Ensure that you are logged in to the OpenStack controller node. If you used Vagrant to create this, we can access this with the following command:

vagrant ssh controller

Let’s modify the /etc/nova/nova.conf file to enable all the scheduler filters discussed:

You can modify the nova.conf file to expose additional features of the nova-scheduler to be used in our environment. In this example, the default scheduler enabled with OpenStack Juno will consider scheduling an instance to a host, if the host meets all of the following criteria:

There are a number of schedulers available for a wide variety of scenarios. For more information, visit http://docs.openstack.org/juno/config-reference/content/section_compute-scheduler.html.