Session 4: Deploying a Virtual Machine from Horizon

After session 3 we have a running OpenStack deployment. Now to deploy a VM.

First off – after starting the OpenStack node I am getting connection refused when trying to connect to Horizon. To check OpenStack services I will follow: https://docs.openstack.org/fuel-docs/latest/userdocs/fuel-user-guide/troubleshooting/service-status.html. These instructions don’t really work for devstack on CentOS but they are a good starting point.

Horizon is dependent on apache so systemctl status httpd revealing apache not running was the first issue. After starting apache I receive an error “cannot import name cinder” when trying to load http://devstack/dashboard. So I need to check the status of the other OpenStack services. As this is a DevStack deployed OpenStack, the service names are not the same as the doc suggests:

[root@devstack ~]# systemctl list-units | grep stack
 devstack@c-api.service    loaded active running
 devstack@c-sch.service    loaded active running
 devstack@c-vol.service    loaded active running
 devstack@dstat.service    loaded active running
 devstack@etcd.service     loaded active running
 devstack@g-api.service    loaded active running
 devstack@g-reg.service    loaded active running
 devstack@keystone.service loaded active running
 devstack@n-api-meta.service loaded active running
 devstack@n-api.service    loaded active running
 devstack@n-cauth.service  loaded active running
 devstack@n-cond-cell1.service loaded active running
 devstack@n-novnc.service  loaded active running
 devstack@n-sch.service    loaded active running
 devstack@n-super-cond.service loaded active running
 devstack@placement-api.service loaded active running
● devstack@q-agt.service   loaded failed failed 
 devstack@q-dhcp.service loaded active running
 devstack@q-l3.service   loaded active running
 devstack@q-meta.service loaded active running
 devstack@q-svc.service  loaded active running
 system-devstack.slice  loaded active active

So I can see that q-agt.service is not running. This is a critical component of Neutron so lets continue troubleshooting by trying to start that service. The service started after running systemctl start devstack@q-agt.service but failed again within a minute or so.

journalctl -u devstack@q-agt.service revealed:

CRITICAL neutron [-] Unhandled error: Exception: Could not retrieve schema from tcp:127.0.0.1:6640: Connection refused
...
ovs|00002|db_ctl_base|ERR|transaction error: {"details":"Transaction causes multiple rows in \"Manager\" table to have identical values (\"ptcp:6640:127.0.0.1\") for index on column \"target\". First ro

A quick google search lead me to: https://ask.openstack.org/en/question/109750/systemd1-devstackq-agtservice-failed/

SELinux… just to confirm I ran a setenforce 0 and start the service again – all is fine. In a proper environment I would not be satisfied with just leaving SELinux disabled… but for the lab I will move on with it disabled. With devstack@q-agt.service running now – Horizon is loading as expected.

So back to the coursework, the objectics of session 4:

• Describe the purpose and use of tenants, users, and roles.
• Differentiate between administrative scopes in Horizon.
• Discuss the different components that are required for deploying instances from Horizon.
• Deploy an instance from Horizon.

Logging in as as admin we look at the admin interface in Horizon and discuss the separation of tenants via projects, the view of infrastructure and instances. Creating a tenant (project) and a user is then completed… pretty straight forward. Interesting note is that under projects/tenants a ‘service’ project is created by default for the OpenStack services. I can see that cinder, placement, glance, nova and neutron users have been created and added to the service project.

Project Quotas are discussed as a method for limiting the amount of resources a tenant can consume. Creating a user to add to the project is then conducts – providing them with a role, ‘User’ enables them to create VMs networks etc.

What is need to deploy an instance in an OpenStack environment:

• Compute node (nova)
• Networking – at least private network (neutron)
• VM Image (glance)
• Security – Security Groups (nova)
• Storage – Cinder

Creating an Instance via Horizon:

• Configure networking (create a SDN, private + generally attaching floating IPs)
• Assign floating IP addresses
• Define a security group in the cloud
• Create an SSH key pair
• Create a Glance image
• Choose a flavor
• The instance can be booted.

The session runs through these steps in more details. Anyone who has used AWS will be familiar with each step. The only one that  really takes some consideration with this lab environment is the software defined networks. This issue then spilled into my nova service being in accessible thus preventing VMs from being launched. Suffice to say at this point, altering the physical network underlying the whole stack is likely to end badly! I need to get a fuller understanding of how Neutron works with underlying hardware devices and how to reconfigure nova without redeploying the whole devstack.