Jump to: navigation, search

Manila/docs/Manila Developer Setup Fedora19

< Manila‎ | docs

This document describes how to install devstack with Manila support on a virtual machine.

Recommended VM requirements

  • 4G RAM
  • 20G of free disk space

The instructions were tested on a Fedora 19 (f19) VM. However, the following notes should work with a Ubuntu VM as well, but some of the instructions might not be required by Ubuntu users. So whenever the notes are suspected to be Fedora specific they'd be stated as being so.

Installing DevStack

Below is the DevStack repo with Manila integrated. Besides installing other OpenStack services, it pulls and installs Manila from, https://github.com/stackforge/manila, the current upto-date Manila repo:

$ git clone git@github.com:bswartz/devstack.git
$ cd devstack

Note: Very recently, the Manila repo has been integrated with DevStack master, which you could also use. Hence, some of the below instructions might no longer be relevant. Expect appropriate changes in instructions soon.

You might need to make the following changes. The change in ./lib/manila is needed if you use F19. Otherwise, the stack.sh script, which installs the OpenStack services, would install the manila scripts in /usr/bin, but later try to execute the manila scripts from /usr/local/bin.

diff --git a/lib/manila b/lib/manila
index abd0158..7f75ebc 100644
--- a/lib/manila
+++ b/lib/manila
 if [[ -d $MANILA_DIR/bin ]]; then
-    MANILA_BIN_DIR=/usr/local/bin
+    MANILA_BIN_DIR=/usr/bin
@@ -456,4 +456,4 @@ function stop_manila() {

The changes in localrc:

  • The change in password of Rabbit service to 'guest' is needed if you use F19. A fresh installation of rabbitmq creates a user 'guest' with the password 'guest'. And for some reason, DevStack fails to set the password of the user 'guest' as desired by the user.
  • Extra variables can be set for logging the screens of the OpenStack services running. This is useful especially because the default screens have a very limited scrollback buffer.
  • The size of the backing file for a Manila-LVM share can be reduced from 8G to 2G.

diff --git a/localrc b/localrc
index 05ea5cd..4474425 100644
--- a/localrc
+++ b/localrc
@@ -1,9 +1,15 @@

+# Enable Logging

@@ -66,7 +72,7 @@ MANILA_SERVICE_PORT_INT=18776

Run stack.sh.

$ ./stack.sh

Note that the above script sets SELinux to Permissive mode for Fedora users. This setting however doesn't survive a reboot. For a permanent change in SELinux setting, you need to edit the /etc/sysconfig/selinux file to be as below:

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing - SELinux security policy is enforced.
#     permissive - SELinux prints warnings instead of enforcing.
#     disabled - No SELinux policy is loaded.

Check the status of SELinux:

$ getenforce

Launching a Guest instance using Nova

Make sure that the services, httpd, rabbitmq-server (or some other AMQP), mysqld (db) are running every time you begin (e.g. after a sytem reboot) using OpenStack. For F19, you could do this by:

$ systemctl status rabbitmq-server

If they aren't running you should get them up and running:

# systemctl restart rabbitmq-server

And also don't forget to check whether SELinux is set to Permissive mode :).

Now you need to setup the keystone login credentials before you can use the CLI of the various OpenStack services. This can be easily done by sourcing openrc file with a user and a tenant name respectively. And stack.sh already has created users (admin and demo) and tenants (admin and demo), which you could use. So, you could do the following:

$ source openrc admin admin

Bring up (if you rebooted after running stack.sh) and interact with the various OpenStack services by running rejoin-stack.sh script.

$ ./rejoin-stack.sh

You'd need Nova guests to test if the Manila shares are accessible. And it makes sense that you use a light weight image (CirrOS) to launch an instance. One such lightweight image with nfs kernel support, nfs-utils, rpcbind and strace was put together by Csaba Henk: https://mega.co.nz/#!B91VUA6Z!eNB2BSW4p1o8lRqaPeaIek4g_J1LJL_SY2OymVnurlc

Create a glance-image using the image downloaded from the above link:

$ glance image-create --name="Cirros 0.3.1" --disk-format=qcow2 \
 --container-format bare < cirros-git-disk.qcow2

List the glance images, and check if available:

$ glance image-list

Add a keypair list:

$ nova keypair-add --pub_key ~/.ssh/id_rsa.pub mykey

Set network rules to allow ssh and ping access to the guest VM:

$ nova secgroup-add-rule default tcp 22 22
$ nova secgroup-add-rule default icmp -1 -1

Boot a nova instance. Please use the image-id of the downloaded image from glance image-list:

$ nova boot --flavor m1.tiny --image 00aa37a3-0bec-4140-bbf1-617fc3b3da63 \
  --key_name mykey --security_group default myvm0

Check the status of the guest instance:

$ nova list

Check by ssh-ing to the VM. Password of the guest VM's cirros is cubswin:):

$ ssh cirros@<the ip of the vm, usually a private IP, unless setup>

Inside the guest vm. If you need to be root:

$ sudo -s
$ id

Creating a Manila LVM NFS share

Currently, Manila doesn't support multi-tenancy (the code to do so is under review as of today), and the networking model is the simple FlatNetwork model. For more info, see

Check if the Manila share driver and it's helpers are as follows, else set them:

$ cat /etc/manila/manila.conf | grep share_driver
share_driver = manila.share.drivers.lvm.LVMShareDriver
$ cat /etc/manila/manila.conf | grep share_lvm_helpers
share_lvm_helpers = CIFS=manila.share.drivers.lvm.CIFSHelper,NFS=manila.share.drivers.lvm.NFSHelper

Creating a 1G LVM Manila NFS share by carving 1G logical volume from a volume group, which is by default stack-shares:

$ manila create --name myshare0 NFS 1

Check if the share is available:

$ manila list

Allow the share to be accessed by the running instance:

$ manila allow-access <share-id> ip <instance-id>

You should now be able to ssh into your guest VM, and check for the NFS share:

$ showmount -e

If all's well, you can mount the NFS share on your guest. If not, the most probable reason could be that the firewall rules setup by Nova are working against you. The dirty way to work around this problem would be to stop and disable firewall daemon in your host VM, and restart the Nova services.

# systemctl stop firewalld
# systemctl disable firewalld