These steps will setup OpenStack nova, glance, and keystone to be accessed by the OpenStack dashboard web UI on a single host, as well as launching our first instance (virtual machine).

+

* These steps will setup OpenStack Nova, Glance, and Keystone to be accessed by the OpenStack Dashboard web UI on a single host, as well as launching our first instance (virtual machine). Fedora 17 includes OpenStack Essex release.

−

Many of the examples here require 'sudo' to be properly configured, please see [[Configuring Sudo]] if you need help.

+

* Many of the examples here require 'sudo' to be properly configured, please see [[Configuring Sudo]] if you need help.

−

== Initial Installation ==

+

* If you have already installed OpenStack with DevStack (you may also be interested by [http://berrange.com/posts/2012/11/20/what-devstack-does-to-your-host-when-setting-up-openstack-on-fedora-17/ Daniel P. Berranger's post on that subject]), you have to remove the installation tree from the file system and the MySQL users and databases:

(If you want to try latest OpenStack packages on Fedora 16, enable the [[OpenStack#Preview repository |OpenStack Preview Repository]] before following these steps)

+

* You may also want to see [[User:Denisarnaud#Cloud solutions submitted to Fedora|Denis']] [http://github.com/openstack-fedora/openstack-configuration step-by-step guide], greatly inspired by this page, but resulting from hours of debugging on Fedora 17 in November 2012.

It is recommended to install and configure the [http://wiki.openstack.org/Releases latest stable OpenStack release]. As of November 2012, the latest stable release is Folsom, aka 2012.2. For that purpose, enable the [[OpenStack#Preview repository |OpenStack Preview Repository]] before proceeding with the following sections:

The volume service has been extracted from Nova and incorporated into a new dedicated component named [http://wiki.openstack.org/ReleaseNotes/Folsom#OpenStack_Block_Storage_.28Cinder.29 Cinder (dubbed OpenStacked Block Storage)]. From the [http://wiki.openstack.org/Releases Folsom release], only Cinder has become officially supported and Nova-volumes has subsequently been deprecated.

If you are testing OpenStack in a virtual machine, you need to configure nova to use qemu without KVM and hardware virtualization.

+

Independently of the block storage service component, either Cinder from Folsom or Nova-volumes in Essex, a LVM volume group (vg) has to be created. The LVM volume group can be created either temporarily, e.g. through a simple loop-back sparse disk image, or permanently, e.g. thanks to a simple file mounted as a permanent partition. The Swift component and more permanent block devices are to be preferred for more production-oriented infrastructures.

−

The second command relaxes SELinux rules to allow this mode of operation (https://bugzilla.redhat.com/show_bug.cgi?id=753589):

+

+

==== File-based storage creation ====

+

Unless you have dedicated partitions and/or block device, a sparse disk image has to be created.

+

+

===== Cinder volumes (from Folsom) =====

+

$> sudo mkdir -p /var/lib/cinder

+

$> sudo truncate --size=20G /var/lib/cinder/cinder-volumes.img

+

+

===== Nova volumes (deprecated) =====

+

$> sudo mkdir -p /var/lib/nova

+

$> sudo truncate --size=20G /var/lib/nova/nova-volumes.img

+

+

==== Volatile set up (to be redone after every reboot) ====

+

The newly created disk image can be mounted as a simple loop-back device.

* When the OpenStack controller machine does not support virtualization hardware accelaration (for instance when it is itself running within a virtual machine), nova needs to be configured to use QEMU without KVM and hardware accelaration. See for instance the [http://docs.openstack.org/essex/openstack-compute/install/apt/content/kvm.html KVM-related configuration section of the OpenStack documentation].

+

* The second command relaxes SELinux rules to allow this mode of operation (https://bugzilla.redhat.com/show_bug.cgi?id=753589):

Check that all the services started up correctly and look in the logs in <code>/var/log/nova</code> for errors. If there are none, then Nova is up and running!

Check that all the services started up correctly and look in the logs in <code>/var/log/nova</code> for errors. If there are none, then Nova is up and running!

Line 61:

Line 200:

== Initial Keystone setup ==

== Initial Keystone setup ==

−

Keystone is the openstack identity service, providing a central place to

+

Keystone is the OpenStack identity service, providing a central place to set up OpenStack users, groups, and accounts that can be shared across all other services. This deprecates the old style user accounts manually set up with <tt>nova-manage</tt>.

−

set up openstack users, groups, and accounts that can be shared across all

−

other services. This deprecates the old style user accounts manually set

−

up with nova-manage.

−

Setting up keystone is required for using the Openstack dashboard.

+

Setting up Keystone is required for using the OpenStack dashboard.

* Configure the Keystone database, similar to how we do it for nova

* Configure the Keystone database, similar to how we do it for nova

Line 72:

Line 208:

* Set up a keystonerc file with a generated admin token and various passwords:

* Set up a keystonerc file with a generated admin token and various passwords:

* The Fedora 17 Keystone CLI version makes use of some Python PrettyTable-related functions, which have been deprecated. Upstream has reported the [https://bugs.launchpad.net/keystone/+bug/996638 bug (#996638)]. If you come across that bug (''i.e.'', the output of any <tt>keystone xxx-list</tt> command returns '<tt>printt</tt>' only), you can apply the patch suggested on their bug report:

+

$> pushd /usr/lib/python2.7/site-packages

+

$> wget https://launchpadlibrarian.net/104576486/replace-printt.diff

+

$> patch -p1 --dry-run < replace-printt.diff

+

$> # Uncomment the following line if everything seems fine:

+

$> # patch -p1 < replace-printt.diff

+

$> \rm -f replace-printt.diff

+

$> popd

+

: Note that this bug affects the calculation of temporary variables within the <tt>/usr/share/openstack-keystone/sample_data.sh</tt> Shell script (itself called by the <tt>openstack-keystone-sample-data</tt> executable). In that case, not all the users will be created by that Shell script (for instance, <tt>nova</tt> and <tt>glance</tt> may be missing). So, you will have to re-start everything from [[Getting started with OpenStack on Fedora 17#Basic Setup |Basic Setup section above]], replacing <tt>systemctl start</tt> by <tt>systemctl restart</tt> where appropriate.

If you use the Chrome browser, kill it before embarking on this section, as it has been [https://bugzilla.redhat.com/show_bug.cgi?id=727925 known] to cause the lvcreate command to fail with 'incorrect semaphore state' errors.

If you use the Chrome browser, kill it before embarking on this section, as it has been [https://bugzilla.redhat.com/show_bug.cgi?id=727925 known] to cause the lvcreate command to fail with 'incorrect semaphore state' errors.

+

+

Note when setting up volumes in production, make sure you don't put your volume nodes on the same network as your guests when using the default volume driver, as all the iscsi targets are discoverable and accessible without any security.

Basic Setup

These steps will setup OpenStack Nova, Glance, and Keystone to be accessed by the OpenStack Dashboard web UI on a single host, as well as launching our first instance (virtual machine). Fedora 17 includes OpenStack Essex release.

Many of the examples here require 'sudo' to be properly configured, please see Configuring Sudo if you need help.

If you have already installed OpenStack with DevStack (you may also be interested by Daniel P. Berranger's post on that subject), you have to remove the installation tree from the file system and the MySQL users and databases:

Independently of the block storage service component, either Cinder from Folsom or Nova-volumes in Essex, a LVM volume group (vg) has to be created. The LVM volume group can be created either temporarily, e.g. through a simple loop-back sparse disk image, or permanently, e.g. thanks to a simple file mounted as a permanent partition. The Swift component and more permanent block devices are to be preferred for more production-oriented infrastructures.

File-based storage creation

Unless you have dedicated partitions and/or block device, a sparse disk image has to be created.

Nova volumes (deprecated)

Installing without hardware acceleration / within a virtual machine (VM)

When the OpenStack controller machine does not support virtualization hardware accelaration (for instance when it is itself running within a virtual machine), nova needs to be configured to use QEMU without KVM and hardware accelaration. See for instance the KVM-related configuration section of the OpenStack documentation.

Check that all the services started up correctly and look in the logs in /var/log/nova for errors. If there are none, then Nova is up and running!

Note the network service should only be started on a single node, when setting up multiple compute nodes

Initial Keystone setup

Keystone is the OpenStack identity service, providing a central place to set up OpenStack users, groups, and accounts that can be shared across all other services. This deprecates the old style user accounts manually set up with nova-manage.

Setting up Keystone is required for using the OpenStack dashboard.

Configure the Keystone database, similar to how we do it for nova

$> sudo openstack-db --service keystone --init

Set up a keystonerc file with a generated admin token and various passwords:

The Fedora 17 Keystone CLI version makes use of some Python PrettyTable-related functions, which have been deprecated. Upstream has reported the bug (#996638). If you come across that bug (i.e., the output of any keystone xxx-list command returns 'printt' only), you can apply the patch suggested on their bug report:

Note that this bug affects the calculation of temporary variables within the /usr/share/openstack-keystone/sample_data.sh Shell script (itself called by the openstack-keystone-sample-data executable). In that case, not all the users will be created by that Shell script (for instance, nova and glance may be missing). So, you will have to re-start everything from Basic Setup section above, replacing systemctl start by systemctl restart where appropriate.

Nova Network Setup

NB the network range here, should *not* be the one used on your existing physical network. It should be a range dedicated for the network that OpenStack will configure. So if 10.0.0.0/24 clashes with your local network, pick another range

Register an Image

To run an instance, you are going to need an image. There are prebuilt Fedora 16 JEOS (Just Enough OS) images that can be downloaded.
Note this will download a 200MB image (without a progress bar)

If selinux is enabled, you will have to allow httpd to access other network services (the dashboard talks to the http API of the other OpenStack services)

$> sudo setsebool -P httpd_can_network_connect=on

The dashboard should then be accessed with a web browser at http://localhost/dashboard . Account and password should be
what you configured for the keystone setup.

Configure swift with keystone

These are the minimal steps required to setup a swift installation with keystone authentication, this wouldn't be considered a working swift system but at the very least will provide you with a working swift API to test clients against, most notably it doesn't include replication, multiple zones and load balancing.

Volumes

If you use the Chrome browser, kill it before embarking on this section, as it has been known to cause the lvcreate command to fail with 'incorrect semaphore state' errors.

Note when setting up volumes in production, make sure you don't put your volume nodes on the same network as your guests when using the default volume driver, as all the iscsi targets are discoverable and accessible without any security.

After restarting nova services on both nodes the newly created machines will run the qemu-kvm with a parameter -vnc compute_fqdn:display_number.
Then after starting the novncproxy and connecting to the dashboard it will discover the host and point to the novncproxy with the appropriate values and connect to the VM.

Note ensure than the iptables entries for VNC ports (5900+DISPLAYNUMBER) are allowed.

Migrate and Resize

This is implemented currently by transferring the images between compute nodes over ssh.
Therefore currently you need to make these adjustments on each compute node to allow that.

To improve the SELinux config in future, the nova_var_lib_t context on /var/lib/nova will,
need to be configured to allow search access by sshd_t.
Also the ssh_home_t context will need to be associated with /var/lib/nova/.ssh

Now everything should be running as before, except the VMs are launched either on controller or node.

Manual Setup of MySQL

As of openstack-nova-2011.3-9.el6 and openstack-nova-2011.3-8.fc16, openstack-nova is now set up to use MySQL by default. If you're updating an older installation or prefer to set up MySQL manually instead of using the openstack-db script, this section shows how to do it.