User Guide for Administrators

Tanja Roth

Frank Sundermeyer

Copyright © 2006– 2013 Novell, Inc. and contributors. All rights reserved.

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

For Novell trademarks, see the Novell Trademark and Service Mark list http://www.novell.com/company/legal/trademarks/tmlist.html. All other third party trademarks are the property of their respective owners. A trademark symbol (®, ™ etc.) denotes a Novell trademark; an asterisk (*) denotes a third party trademark.

All information found in this book has been compiled with utmost attention to detail. However, this does not guarantee complete accuracy. Neither Novell, Inc., SUSE LINUX Products GmbH, the authors, nor the translators shall be held liable for possible errors or the consequences thereof.

About This Guide

SUSE® Cloud is an open source software solution that provides the fundamental capabilities to deploy and manage a cloud infrastructure based on SUSE Linux Enterprise. SUSE Cloud is powered by OpenStack, the leading community-driven, open source cloud infrastructure project. It seamlessly manages and provisions workloads across a heterogeneous cloud environment in a secure compliant, and fully-supported manner. The product tightly integrates with other SUSE technologies and with the SUSE maintenance and support infrastructure.

This guide helps cloud administrators in the execution of their daily tasks like managing projects and users, images, or flavors, setting quotas, or managing networks. Most of these tasks can either be achieved with the Web interface (the SUSE Cloud Dashboard) or the OpenStack command line tools.

Many chapters in this manual contain links to additional documentation resources. These include additional documentation that is available on the system as well as documentation available on the Internet.

For an overview of the documentation available for your product and the latest documentation updates, refer to http://www.suse.com/documentation/suse_cloud20.

For the documentation on SUSE Linux Enterprise Server and Subscription Management Tool (SMT) and the latest documentation updates, refer to http://www.suse.com/documentation/.

Available Documentation

The following manuals are available for this product:

“Deployment Guide” (↑Deployment Guide)

Gives an introduction to the SUSE® Cloud architecture and describes how to set up, deploy, and maintain the individual components.

User Guide for Administrators

Guides you through management of projects and users, images, flavors, quotas, and networks with SUSE Cloud Dashboard or the command line interface.

“End User Guide” (↑End User Guide)

Describes how to manage images, networks, instances, volumes, and track usage.

HTML versions of the product manuals can be found in the installed system under /usr/share/doc/manual. Find the latest documentation updates at http://www.suse.com/documentation where you can download the manuals for your product in multiple formats.

Feedback

Several feedback channels are available:

Bugs and Enhancement Requests

For services and support options available for your product, refer to http://www.suse.com/support/.

To report bugs for a product component, log in to the Novell Customer Center from http://www.suse.com/support/ and select My Support+Service Request.

User Comments

We want to hear your comments about and suggestions for this manual and the other documentation included with this product. Use the User Comments feature at the bottom of each page in the online documentation or go to http://www.suse.com/documentation/feedback.html and enter your comments there.

Mail

For feedback on the documentation of this product, you can also send a mail to doc-team@suse.de. Make sure to include the document title, the product version, and the publication date of the documentation. To report errors or suggest enhancements, provide a concise description of the problem and refer to the respective section number and page (or URL).

Documentation Conventions

The following typographical conventions are used in this manual:

/etc/passwd: directory names and filenames

placeholder: replace placeholder with the actual value

PATH: the environment variable PATH

ls, --help: commands, options, and parameters

user: users or groups

Alt, Alt+F1: a key to press or a key combination; keys are shown in uppercase as on a keyboard

File, File+Save As: menu items, buttons

Dancing Penguins (Chapter Penguins, ↑Another Manual): This is a reference to a chapter in another manual.

About the Making of This Manual

This book is written in Novdoc, a subset of DocBook (see http://www.docbook.org). The XML source files were validated by xmllint, processed by xsltproc, and converted into XSL-FO using a customized version of Norman Walsh's stylesheets. The final PDF is formatted through XEP from RenderX.

Chapter 1. Using SUSE Cloud Dashboard

The SUSE® Cloud Dashboard is a Web interface that enables cloud administrators and users to manage various OpenStack services. It is based on OpenStack Dashboard (also known under its codename Horizon).

After a short introduction to the Dashboard, learn how to execute key administration tasks such as managing projects and users, adding images, adding flavors, and setting quotas.

Requirements

The following requirements need to be fulfilled to access the SUSE Cloud Dashboard:

The cloud operator has set up SUSE Cloud.

You have a recent Web browser that supports HTML5. It must have cookies and JavaScript enabled. For using the Dashboard's VNC client, which is based on noVNC, your browser needs to support HTML5 Canvas and HTML5 WebSockets. For more details and a list of browsers that support noVNC, refer to https://github.com/kanaka/noVNC/blob/master/README.md, and https://github.com/kanaka/noVNC/wiki/Browser-support, respectively.

SUSE Cloud Dashboard—Overview

Learn how to log in to SUSE Cloud Dashboard and get a short overview of its Web interface.

Logging in to the SUSE Cloud Dashboard

To access the SUSE Cloud Dashboard, ask the cloud operator for the following information:

Hostname or (public) IP address of the SUSE Cloud Dashboard. (The Dashboard is available on the node that has the nova_dashboard-server role.)

Username and password of the cloud administrator or cloud user with which you can log in to SUSE Cloud Dashboard.

Start a Web browser and make sure that JavaScript and cookies are enabled.

As a URL, enter the hostname or IP address that you got from the cloud operator.

https://IP_ADDRESS_OR_HOSTNAME/

Certificate Warning

Depending on your browser and browser options, you may get a certificate warning when trying to access the URL for the first time. (In case no certificate is provided when setting up the Dashboard, SUSE Cloud uses a self-signed certificate that is not considered trustworthy by default).

In this case, verify the certificate.

To proceed anyway, you can add an exception in the browser to bypass the warning.

On the SUSE Cloud Dashboard login screen, enter the User Name and Password and click Sign In.

Figure 1.1. SUSE Cloud Dashboard—Login Screen

After logging in, the Dashboard's Main Screen (Administrator's View) appears.

Main Screen (Administrator's View)

The top-level row of the main screen shows the username with which you are logged in. It also lets you access the Settings (regarding language and timezone), the Help pages, or lets you Sign Out of the Web interface.

Available Functions

The visible tabs and functions in the Dashboard depend on the access permissions of the user that is logged in. They are defined by roles.

If you are logged in as an administrator, the main screen shows the following tabs on the left navigation bar: Project and Admin.

Main Screen—Project Tab

The Project tab shows details for the projects that the user who is logged in belongs to.

Figure 1.2. SUSE Cloud Dashboard—Project Tab

Select a Project from the drop-down list on the left-hand side to access the following categories. They are sorted into the groups: Manage Compute, Manage Network, and Object Store.

Manage Compute

Overview

Shows basic reports on the project and lets you track usage.

Instances

Lists instances launched by users of the project. From here, you can launch, terminate, pause, or reboot any instances, connect to them via VNC or create a snapshot of an instance.

Volumes

Lists volumes created by users of the project. Form here, you can create volumes and attach them to instances.

Images & Snapshots

Lists images, instance snapshots and volume snapshots created by users of the project, plus any images that are publicly available, or that have been shared with the current user. From here, you can launch instances from images or from instance snapshots.

Access & Security

Lets you manage security groups and keypairs, allocate or release floating IP addresses, access the API, and download RC files.

Manage Network

Networks

Shows all networks and subnets that are available to the currently selected project. Lets you create networks and subnets for the current project.

Routers

Lets you create routers and set gateways.

Network Topology

Displays a graphical representation of the network topology. From here, you can also launch instances, and create networks or routers.

Object Store

Containers

Lets you create containers and upload objects to OpenStack Object Storage.

Main Screen—Admin Tab

Figure 1.3. SUSE Cloud Dashboard—Admin Tab

On this tab, you can access the following categories that belong to the System Panel:

Overview

Shows basic reports.

Instances

Lists all currently running instances belonging to various users and projects.

Volumes

Lists all volumes belonging to various users and projects. (Not all projects may be visible to the administrator, though.) From here, administrators can also create volume types, according to the capabilities of the storage back-end drivers to be used.

Flavors

Lists the available “sizes” of the VMs that users may launch. From here, administrators can modify existing flavors or create new flavors.

Images

Shows the public images that have been uploaded, and custom images of any projects that have been made visible to the administrator. Lets the administrator add images, edit image properties or delete images, if needed.

Projects

Lists the available projects. From here, administrators can create new projects, assign users to the projects, view the usage, or modify the quota settings for a project.

Users

Gives an overview of all users and lets administrators add, modify, delete or disable user accounts.

Networks

Lets administrators create networks and define options such as Admin State, Shared, or External Network. Shows all networks and subnets that are visible to the administrator.

Routers

Shows the routers that have been created. From here, routers can only be listed and deleted. To create routers, use the Routers category in the Project tab, as this can be done with normal user permissions.

System Info

Lists the defined Services, and the Default Quotas (hard-coded in OpenStack Compute). Includes parameters such as the number of CPUs, RAM, or instances.

Managing Projects and Users

SUSE Cloud enables you to manage projects independently from each other. Projects represent different organizational units in the cloud to which users can be assigned. Both project and user management are cloud administrator's tasks.

During the basic system setup, the cloud operator needs to minimally define one project, one user, and one role to link the project and user. Roles define which actions users are allowed to perform.

As a SUSE Cloud administrator, you can create additional projects and user accounts as needed. The following procedures guide you through the main management tasks like adding, modifying, or deleting projects and user accounts. Learn how to assign users to one or multiple projects, or how to change or remove the assignment.

Users are members of one or multiple projects. Both project and user management are cloud administrator's tasks. When a new user account is created, the user has to be assigned to a primary project. The user can also be assigned to additional projects.

User accounts can be created, deleted, or temporarily deactivated. If a user account is deactivated, the user can no longer log in, but his data is kept so that the account can be re-enabled at any time.

Roles define the actions that the user is allowed to perform and are configured by the cloud operator in OpenStack Identity (Keystone). Out of the box, OpenStack comes with two default roles:

member: a typical user.

admin: a super user with full permission across all projects.

Actions are defined per OpenStack service in the respective /etc/[SERVICE_CODENAME]/policy.json file, for example in /etc/nova/policy.json for the Compute (Nova) service. For details, refer to http://docs.openstack.org/essex/openstack-compute/install/content/keystone-concepts.html.

Procedure 1.1. Creating or Deleting A Project

Projects can be created, deleted, or temporarily disabled by cloud administrators. Disabling a project has the following consequences:

Consequences of Temporarily Disabling a Project

In the SUSE Cloud Dashboard, the project can no longer be accessed from the Project drop-down list on the Project tab.

Users that are only members of the disabled project can no longer log in.

It is impossible to launch new instances for a disabled project. Instances already running are not automatically terminated though—you have to stop them manually.

All data of a disabled project is kept so that the project can be re-enabled at any time.

Log in to SUSE Cloud Dashboard.

On the Admin tab, select the Projects category.

To add a new project:

Click Create Project.

In the window that opens, enter a Name and Description for the project.

For details about defining project members or setting quotas for the project, refer to Procedure 1.4, “Modifying User Assignments for a Project” and Procedure 1.8, “Setting Quotas for a Project” respectively.

Confirm your changes.

The Dashboard automatically assigns an ID and shows the newly created project in the Projects category.

To delete one or multiple projects:

Activate the check boxes in front of the projects that you want to delete.

Click Delete Projects and confirm your choice in the pop-up that appears.

A message on the Web page shows if the action has been successful.

To temporarily deactivate a project: Click More+Edit Project and deactivate the Enabled check box.

Figure 1.4. SUSE Cloud Dashboard—List of Projects (Administrator's View)

Procedure 1.2. Creating Users Accounts

Log in to SUSE Cloud Dashboard.

On the Admin tab, select the Users category.

Click Create User.

In the window that opens, enter a User Name and an Email address for the user.

Set a preliminary Password for the user and confirm it.

Assign the user to a Primary Project by selecting the respective project from the drop-down list.

If you need to create a new project:

Click the plus icon next to Primary Project.

In the window that opens, enter a Name and Description for the project.

For details about defining project members or setting quotas for the project, refer to Procedure 1.4, “Modifying User Assignments for a Project” and Procedure 1.8, “Setting Quotas for a Project” respectively.

Select a Role which to assign to the user. By default, the user is automatically assigned a Member role. This is appropriate in most cases.

Admin Role: Administrative Rights Across the Cloud

The admin role is global. If you assign a user to a project and give him the admin role, the role is not restricted to the current project. Instead, the user will be granted full administrative rights across all projects.

Confirm your changes.

The Dashboard automatically assigns an ID and shows the newly created user account in the Users category.

Procedure 1.3. Deleting or Temporarily Disabling Users Accounts

Log in to SUSE Cloud Dashboard.

On the Admin tab, select the Users category.

If you only want to temporarily deactivate a user account: Select the user, and from the More drop-down list, select Disable.

To delete one or more user accounts:

Activate the check boxes in front of the user accounts that you want to delete.

Click Delete Users and confirm your choice in the pop-up that appears.

A message on the Web page shows if the action has been successful.

Figure 1.5. SUSE Cloud Dashboard—List of Users (Administrator's View)

Procedure 1.4. Modifying User Assignments for a Project

When creating new users, you must assign them to a primary project as described in Procedure 1.2, “Creating Users Accounts”. To assign users to additional projects or to modify and remove assignments or roles, proceed as follows:

Log in to SUSE Cloud Dashboard.

On the Admin tab, select the Projects category.

Select the project for which to modify user assignments.

Click Modify Users.

The dialog that opens shows two lists of users on its Project Members' tab: All Users and Project Members.

To assign a user to the current project:

Select a user from the All Users list and click the plus icon next to the user.

This moves the user to the Project Members list. By default, the user is automatically assigned a Member role. This is appropriate in most cases.

If you want to change the role with which the user has been added, select a different role from the drop-down list next to the minus icon.

Admin Role: Administrative Rights Across the Cloud

The admin role is global. If you assign a user to a project and give him the admin role, the role is not restricted to the current project. Instead, the user will be granted full administrative rights across all projects.

To remove a user from the current project, select the respective user in the Project Members list and click the minus icon next to the user.

This moves the user to the All Users list.

Confirm your changes.

Managing Images

In the SUSE Cloud context, images are virtual disk images that represent the contents and structure of a storage medium or device, such as a hard drive, in a single file. Images are used as a template from which a virtual machine can be started. For starting a virtual machine, SUSE Cloud always uses a copy of the image.

Permissions to manage images are defined by the cloud operator during setup of SUSE Cloud. Image upload and management may be restricted to cloud administrators or cloud operators only.

After uploading an image to OpenStack Image, it cannot be changed any more (“golden image”).

Images are owned by projects and can be private (accessible to members of the particular project only) or public (accessible to members of all projects). Private images can also be explicitly shared with other projects, so that members of those projects can access the images, too. Any image uploaded to OpenStack Image will get an owner attribute. By default, ownership is set to the primary project of the user that uploads the image.

Images have both contents and metadata; the latter are also called properties. The following properties can be attached to an image in SUSE Cloud. Set them from the command line when uploading or modifying images.

Image Properties

Name (--name, optional)

Specifies a name with which the image will be listed in the SUSE Cloud Dashboard and in the command line interface.

Kernel ID (optional)

The image's kernel ID. This parameter is only needed if an external Kernel is associated with the image. The ID points to the Kernel glance image.

Ramdisk ID (optional)

The image's ramdisk ID. This parameter is only needed if an external ramdisk is associated with the image. The ID points to the ramdisk glance image.

Container Format (--container-format, optional)

Indicates if the VM image's file format contains metadata about the actual virtual machine. Set it to bare as the container format string is not currently used in any OpenStack components anyway. For details, refer to http://docs.openstack.org/developer/glance/formats.html.

Disk Format (--disk-format, required)

Specifies the image's disk format. Example formats include raw, qcow2, and ami. For details, refer to http://docs.openstack.org/developer/glance/formats.html.

Public (--is-public, optional)

Boolean value, default: false. If set to true, the image is publicly available.

Hypervisor Type (optional)

If your cloud consists of both KVM and Xen nodes, specify at least the hypervisor type the image requires, otherwise it might be scheduled on an incompatible node. For example:

hypervisor_type=xen

Further example are: kvm, qemu, xenapi, and powervm.

Architecture (optional)

Specifies the architecture the image requires. For example:

architecture=x86_64

VM Mode (optional)

Specify the hypervisor ABI (application binary interface) with the vm_mode flag. It can take the values pv, hvm, or xen. Use vm_mode=xen for XEN PV image import, or vm_mode=hvm for XEN HVM image import. For KVM, the correct mode is selected automatically.

Procedure 1.5. Adding Images

Since the OpenStack Grizzly release, it is possible to upload images also via the Dashboard. Images can either be uploaded from external URLs or from a local file system. Upload of compressed image binaries (.zip and .tar.gz) is supported.

Limitations for Image Upload via Dashboard

For upload from an external URL, the image must be available via a valid HTTP URL that leads directly to the image binary. URLs that redirect or serve error pages will result in unusable images.

Avoid upload of large images via Dashboard. For image sizes of several GB, it is strongly recommended to use the command-line tools. For details, refer to Section “Adding Images”.

Only a limited set of image properties are accessible from the Dashboard. It is therefore recommended to set and modify image properties from the command line. For details, refer to Section “Modifying Image Properties”.

Log in to SUSE Cloud Dashboard.

On the Admin tab, select the Images category.

Click Create Image.

In the window that opens, enter a Name for the image.

If you have an external URL to upload the image from, enter the URL into Image Location. For a local image to upload, enter the path into Image File or click Browse.

Select the image Format.

If you want to specify a minimum disk size or minimum RAM size that is required to boot the image, enter the values into the respective input fields. Otherwise the minimums are set to 0.

Confirm your changes.

The image is uploaded to the OpenStack Image service.

After images have been added, they appear in the SUSE Cloud Dashboard on the Admin tab. View them in the Images category.

Figure 1.6. SUSE Cloud Dashboard—List of Images (Administrator's View)

From there, you can also Edit some image properties. As only a limited set of image properties are accessible from the Dashboard, it is preferable to set and modify image properties from the command line. For example, to make sure that an image is only launched on appropriate hypervisors, you can specify image properties that refer to a certain architecture, hypervisor type or application binary interface (ABI) that the image requires. For more details, refer to Procedure 2.4, “Setting Image Properties for Architecture, Hypervisor and VM Mode”.

If you need to delete an image, proceed as follows.

Procedure 1.6. Deleting Images

Log in to SUSE Cloud Dashboard.

On the Admin tab, select the Images category.

To delete one or multiple images, activate the check boxes in front of the images that you want to delete.

Click Delete Images and confirm your choice in the pop-up that appears.

A message on the Web page shows if the action has been successful.

Managing Flavors

In OpenStack, flavors define the compute, memory, and storage capacity of nova computing instances. To put it simply, a flavor is an available hardware configuration for a server. It defines the “size” of a virtual server that can be launched.

A flavor consists of the following parameters:

Flavor Parameters

Name

Name for the new flavor.

VCPUs

Number of virtual CPUs to use.

RAM MB

Amount of RAM to use (in megabytes).

Root Disk GB

Amount of disk space (in gigabytes) to use for the root (/) partition.

Ephemeral Disk GB

Amount of disk space (in gigabytes) to use for the ephemeral partition. If unspecified, the value is 0 by default.

Ephemeral disks offer machine local disk storage linked to the lifecycle of a VM instance. When a VM is terminated, all data on the ephemeral disk is lost. Ephemeral disks are not included in any snapshots.

Swap Disk MB

Amount of swap space (in megabytes) to use. If unspecified, the value is 0 by default.

The default flavors are:

Default Flavors

m1.tiny (1 VCPU/0 GB Disk/512 MB RAM)

m1.small (1 VCPU/20 GB Disk/2048 MB RAM)

m1.medium (2 VCPU/40 GB Disk/4096 MB RAM)

m1.large (4 VCPU/80 GB Disk/8192 MB RAM)

m1.xlarge (8 VCPU/160 GB Disk/16384 MB RAM)

Via the SUSE Cloud Dashboard, you can create new flavors, edit or delete existing ones.

Procedure 1.7. Creating, Modifying or Deleting Flavors

Log in to SUSE Cloud Dashboard.

On the Admin tab, select the Flavors category.

To create a new flavor or modify an existing one:

Click Create Flavor or select a flavor and click Edit Flavor.

In the window that opens, specify the required parameters for the flavor.

Confirm your changes.

The newly created flavor will appear in the list of flavors and can be used when launching new instances.

To add additional metadata, which custom schedulers can use for appropriately scheduling instances:

Select the flavor to modify and click More+View Extra Specs.

In the Flavor Extra Specs view that opens, click Create.

Enter a Key and a Value.

Confirm your changes to create a new key-value pair for a flavor.

Create, modify, or delete extra specs as desired and Close the view to return to the Flavors category.

To delete one or multiple flavors:

Activate the check boxes in front of the flavors that you want to delete.

Click Delete Flavors and confirm your choice in the pop-up that appears.

A message on the Web page shows if the action has been successful.

Figure 1.7. SUSE Cloud Dashboard—List of Flavors (Administrator's View)

Setting Quotas

To prevent system capacities from being exhausted without notification, cloud administrators can set up quotas. In OpenStack, quotas are currently defined per project. The default quotas that are initially applied to each project are specified in the nova.conf on the Control Node. For a description of the configuration options for quotas in that file, refer to http://docs.openstack.org/grizzly/openstack-compute/admin/content/list-of-compute-config-options.html. For details about how to change the default values in nova.config, refer to http://docs.openstack.org/grizzly/openstack-ops/content/projects_users.html#quotas.

Quotas contain the following parameters:

Quota Parameters

Metadata Items

Number of metadata items per instance.

VCPUs

Number of virtual CPUs that can be allocated in total.

Instances

Total number of instances.

Injected Files

Number of injected files.

Injected File Content Bytes

Number of bytes per injected file.

Volumes

Total number of volumes.

Gigabytes

Total size of all volumes, measured in gigabytes.

RAM (MB)

Total RAM size of all instances, measured in megabytes.

Floating IPs

Total number of floating IP addresses.

Fixed IPs

Total number of fixed IP addresses.

Security Group Rules

Number of security rules per security group.

Security Groups

Number of security groups.

Procedure 1.8. Setting Quotas for a Project

Quotas for a project can also be set when creating the project. To modify them afterwards, proceed as follows:

Log in to SUSE Cloud Dashboard.

On the Admin tab, select the Projects category.

Select the project for which to set or change quota values.

From the More drop-down list, select Modify Quota.

The window that opens shows the current quota values for the selected project. If no modifications have been made yet, the values reflect the default values per project that are hard-coded in OpenStack Compute.

Change the values for the quota parameters as desired.

Confirm your changes.

Managing Networks

Use the Networks and Routers categories on the Admin tab to configure virtual networks. Certain parts of managing networks are only available to cloud administrators: for example, creating or modifying external and shared networks. The deletion of shared and external networks is also limited to administrators only, as is the creation of ports. However, networks as such, subnets, and routers can be created by any user—of course, only for the respective projects that the user belongs to.

Procedure 1.9. Creating, Modifying or Deleting Networks

In the OpenStack Networking API, a network is an isolated L2 network segment (similar to a VLAN). It forms the basis for describing the L2 network topology in a given OpenStack Networking deployment.

When creating a network, you can set the following options:

Admin State (admin_state_up)

The administrative state of the network. The default value is true. If set to false, the network is down and does not forward any packets.

Shared (--shared)

Specifies if the network resource can be accessed by any project or not.

External (--router:external=True)

Used for pools of floating IPs, and to create routers that allow access to external networks (and the Internet) from private neutron networks.

Log in to SUSE Cloud Dashboard.

On the Admin tab, select the Networks category.

To create a new network or modify an existing one:

Click Create Network or select a network and click Edit Network.

In the window that opens, enter a name for your network or change the existing name.

Select a Project to which the network should belong.

Leave the Admin State checkbox activated—unless you want the network to be marked as down and to not forward any packets.

To create a network that is visible to all projects, activate the checkbox Shared and click Create Network.

To create an external network, activate the checkbox External Network and click Create Network.

Select a Project which to assign to the new network. This is necessary because OpenStack Networking's internal data model does not allow networks without a project.

Confirm your changes to close the dialog.

To delete an existing network:

Activate the check boxes in front of the networks that you want to delete.

Click Delete Network and confirm your choice in the pop-up that appears.

A message on the Web page shows if the action has been successful.

Deleting Networks

If a network cannot be deleted (although you have the respective permissions to delete it), it is because it still has ports assigned: either from a router or from a running VM instance.

Figure 1.8. SUSE Cloud Dashboard—List of Networks (Administrator's View)

Procedure 1.10. Creating or Modifying Subnets

A subnet is a block of IP addresses and other network configuration (for example, a default gateway, DNS servers) that can be associated with an OpenStack Networking network. Each subnet represents an IPv4 or IPv6 address block. Multiple subnets can be associated with a network, if necessary.

By default, the first IP address of the specified network address is used as Gateway (for example, if you specified 192.168.0.0/24 as network address, 192168.0.1 is used as gateway).

Log in to SUSE Cloud Dashboard.

On the Admin tab, select the Networks category.

Select a network and click its Network Name to view the details for the network.

Click Create Subnet or select a subnet and click Edit Subnet.

In the window that opens, enter a name for the subnet or change the existing name.

Enter or change the Network Address. It must be specified in CIDR format, for example:

192.168.0.0/24

Choose the IP Version to use (IPv4 or IPv6).

If you want to use another Gateway IP like the default one, enter a Gateway IP. Otherwise, leave the input field blank.

If you do not want to use a gateway, activate Disable Gateway.

To specify additional attributes for the subnet, click the Subnet Detail tab and proceed as follows:

Specify if to Enable DHCP.

To define multiple Allocation Pools, enter the start and the end IP address for each pool separated by a comma and in one entry per line for each pool. For example:

192.168.1.100,192.168.1.120
192.158.1.100,192.158.1.120

To specify DNS Name Servers, enter an IP address list of servers for the current subnet (one entry per line).

For additional routes announced to the hosts, enter them into the Host Routes field as follows: One entry per line, each specifying:

DESTINATION_CIDR,NEXTHOP

Confirm your changes to close the dialog.

Procedure 1.11. Creating or Modifying Ports

Usually, you do not need to create or modify ports manually as described below. In most cases, OpenStack will take care of that automatically (for example, when an instance is launched, a floating IP is associated, or a router interface is created).

A port is an attachment port to a L2 OpenStack Networking network. When a port is created on the network, it will be associated with a security group. If no security group is specified, it will be associated with a default security group. By default, the port will be allocated an available fixed IP address out of one of the designated subnets for each IP version. Users of the OpenStack Networking API can either choose a specific IP address from the block, or let OpenStack Networking choose the first available IP address. When the port is destroyed, the allocated addresses return to the pool of available IPs on the subnet(s).

To manually create a port for the network and specify a device ID to be attached to the port, proceed as follows:

Log in to SUSE Cloud Dashboard.

On the Admin tab, select the Networks category.

Select a network and click its Network Name to view the details for the network.

Click Create Port.

The window that opens shows the Network Name and the Network ID.

Enter a Name for the port.

Leave the Admin State checkbox activated—unless you want the port to be marked as down and to not forward any traffic.

Specify the Device ID of the device that uses this port, for example, a virtual server.

In Device Owner, enter the ID of the entity that uses this port. For example, a DHCP agent.

Confirm your changes to close the dialog.

For information on how to create a router and connect an external to an internal network, refer to “Creating or Modifying Routers” (↑End User Guide).

For more information and example network setups, refer to the OpenStack Networking Administration Guide at http://docs.openstack.org/grizzly/openstack-network/admin/content/.

Chapter 2. Using OpenStack Command Line Clients

The OpenStack project provides a variety of command line tools with which you can manage the services within your cloud and automate tasks by using scripts. Each of the core OpenStack components has its own command line tool.

OpenStack Commands—Overview

Use the OpenStack command-line clients to run simple commands that make API calls. You can use these commands in scripts to automate tasks. Each OpenStack service has its own command-line client, that runs on Linux* or Mac OS* X systems. For some client commands, you can specify a debug parameter to show the underlying API request for the command.

The following command line clients are available for the respective services' APIs.

ceilometer

For managing OpenStack Metering. Provided by the python-ceilometerclient package. In SUSE Cloud 2.0 it is included as a technology preview.

cinder

For managing the block storage. Provided by the python-cinderclient package.

glance

For managing images. Provided by the python-glanceclient package.

heat

For managing OpenStack Orchestration. Provided by the python-heatclient package. In SUSE Cloud 2.0 it is included as a technology preview.

keystone

For managing users, projects, roles, endpoints, and credentials. Provided by the python-keystoneclient package.

neutron

For configuring networks for guest servers. Provided by the python-quantumclient package.

nova

For managing images, instances, and flavors. Provided by the python-novaclient package.

swift

For gathering statistics, listing items, updating metadata, and managing files stored by the Object Storage service. Provides access to a swift installation for ad hoc processing. Provided by the python-swiftclient package.

Most of them have tab completion.

Help and detailed information about the individual commands and their arguments are available with

COMMAND help

For help on subcommands, use

COMMAND help SUBCOMMAND

For example: glance help or glance help image-create

OpenStack RC File

To set the necessary environment variables for the OpenStack command line tools, you need to download and source an environment file, the OpenStack RC file. It contains the credentials used by OpenStack services like Compute, Image, and Identity services for a specific project. You can download it from the SUSE Cloud Dashboard, either as user admin or as any other user. The filename of the RC file contains the name of the project for which the credentials are valid: PROJECTNAME-openstack.rc.

The RC file requires running Bash or Bourne shell (sh) as shell environment.

Procedure 2.1. Downloading the OpenStack RC File

Log in to the SUSE Cloud Dashboard.

On the Project tab, select the project for which you want to download the OpenStack RC file from the Current Project drop-down list.

Select the Access & Security category and switch to the API Access tab.

Click Download OpenStack RC File and save the file.

Copy the RC file to the machine on which you want to execute OpenStack commands (for example, uploading an image with the glance command).

On any shell that you want to execute OpenStack commands from, source the RC file for the respective project, for example:

source PROJECTNAME-openstack.rc

You will be prompted for an OpenStack password.

Enter the OpenStack password of the user who downloaded the PROJECTNAME-openstack.rc file.

With sourcing the file and entering the password, environment variables are set for that shell. They allow the commands to communicate to the OpenStack services running in the cloud.

Managing Projects and Users

SUSE Cloud enables you to manage projects independently from each other. Projects represent different organizational units in the cloud to which users can be assigned. Both project and user management are cloud administrator's tasks.

During the basic system setup, the cloud operator needs to minimally define one project, one user, and one role to link the project and user. Roles define which actions users are allowed to perform.

The python-keystoneclient provides the keystone command line tool which you can use to manage projects and users from any machine outside the cloud. Prior to using the tool, download and source an OpenStack RC file. For details, refer to Section “OpenStack RC File”.

Administrator Credentials

Administering projects and users requires administrator credentials. Make sure to download and source the OpenStack RC file as administrator prior to running keystone commands. Alternatively, export the respective environment variables, using the token or password authentication method. For details, refer to http://docs.openstack.org/grizzly/openstack-compute/admin/content/adding-users-tenants-and-roles-with-python-keystoneclient.html

Viewing, Creating, Disabling, or Deleting Projects

Find examples for the key administration tasks below.

Listing All Projects

keystone tenant-list

Lists all projects with their ID, name, and the information if they are enabled or not.

Creating a Project

keystone tenant-create --name PROJECT_NAME

Creates a new project with the specified name.

Temporarily Disabling a Project

keystone tenant-update PROJECT_ID_OR_NAME --enabled false

For the details of the impact, refer to Consequences of Temporarily Disabling a Project .

Deleting a Project

keystone tenant-delete PROJECT_ID_OR_NAME

Deletes the specified project.

Viewing, Creating, Disabling, or Deleting User Accounts

Find examples for the key administration tasks below.

Listing All Users

keystone user-list

Lists all user accounts with their ID, name, e-mail address, and the information if they are enabled or not.

Creating a User Account

keystone user-create --name USER_NAME --tenant_id PROJECT_ID \
  --pass PRELIM_PASSWD

Creates a new user with the specified name. While the only required argument is --name, at least specify the optional parameters --tenant_id and --pass. Otherwise the newly created user cannot log in to the SUSE Cloud Dashboard.

Temporarily Disabling a User Account

keystone user-update USER_ID_OR_NAME --enabled false

If you disable a user account, the user can no longer log in, but his data is kept so that the account can be re-enabled at any time.

Deleting a User Account

keystone user-delete USER_ID_OR_NAME

Deletes the specified user account.

Managing Roles

Roles define the actions that the user is allowed to perform. Configure roles in OpenStack Identity (Keystone). Actions are defined per OpenStack service in the respective /etc/[SERVICE_CODENAME]/policy.json file, for example in /etc/nova/policy.json for the OpenStack Compute service (Nova).

Find examples for the key administration tasks below.

Listing All Roles

keystone role-list

Lists all roles with their ID and name.

Creating a Role

keystone role-create --name=ROLE_NAME

Creates a role with the specified name.

Deleting a Role

keystone role-delete ROLE_ID_OR_NAME

Deletes the specified role.

Modifying User Assignments for a Project

Whereas each user is assigned to a primary project when his user account is created, users can be members of multiple projects. The keystone client does not allow to directly assign users to additional projects. Instead you need to define a role and grant that role to a user-project pair.

On a shell, source the OpenStack RC file. For details, refer to Section “OpenStack RC File”.

Check if there is already a member role defined:

keystone role-list

If not, create it:

keystone role-create --name=member

To grant the user membership of a project:

keystone user-role-add --user USER_NAME --role ROLE_NAME \
  --tenant TENANT_NAME

To assign the user to multiple projects, repeat the last step.

To verify the assignments, use:

keystone user-role-list --user USER_NAME --tenant TENANT_NAME

Managing Images

In the SUSE Cloud context, images are virtual disk images that represent the contents and structure of a storage medium or device, such as a hard drive, in a single file. Images are used as a template from which a virtual machine can be started. For starting a virtual machine, SUSE Cloud always uses a copy of the image.

Permissions to manage images are defined by the cloud operator during setup of SUSE Cloud. Image upload and management may be restricted to cloud administrators or cloud operators only.

After uploading an image to OpenStack Image, it cannot be changed any more (“golden image”).

Images are owned by projects and can be private (accessible to members of the particular project only) or public (accessible to members of all projects). Private images can also be explicitly shared with other projects, so that members of those projects can access the images, too. Any image uploaded to OpenStack Image will get an owner attribute. By default, ownership is set to the primary project of the user that uploads the image.

Images can either be uploaded to SUSE Cloud with the glance command line tool or with the SUSE Cloud Dashboard. As the Dashboard comes with some limitations with regards to image upload and modification of properties, it is recommended to use the glance command line tools for comprehensive image management.

Building Images with SUSE Studio

To build the images to use within the cloud, use SUSE Studio or SUSE Studio Onsite. For detailed information on how to build appliance images, refer to the SUSE Studio Onsite Quick Start or the SUSE Studio Onsite User Guide, available at http://www.suse.com/documentation/suse_studio/.

SUSE Studio and SUSE Studio Onsite (starting with version 1.3) now support building native KVM images in qcow2 format. To make use of that, choose the SUSE Cloud/OpenStack/KVM appliance format. The resulting images can be directly uploaded to SUSE Cloud.

To build images for VMware, choose the VMware / VirtualBox / KVM (.vmdk) appliance format. The resulting images can be directly uploaded to SUSE Cloud.

Image Requirements

Make sure any images that you build for SUSE Cloud fulfill the following general requirements:

General Image Requirements

The network is set to DHCP.

The image does not include YaST2 Firstboot.

The image does not include any end-user license agreement (EULA) dialogs.

The image contains the cloud-init package. The package will be automatically added to the image if the following checkbox in SUSE Studio or SUSE Studio Onsite is enabled: Integrate with SUSE Cloud / OpenStack. See also http://susestudio.com/help/use/suse_cloud.html.

The cloud-init package contains tools used for communication with the instance metadata API, which is provided by Compute. The instance metadata API is specific to each virtual machine and is only accessible from inside the VM. The package is needed to pull keypairs into the virtual machine that will run the image.

If you intend to manage the image by OpenStack Orchestration, you also need to include the following package: openstack-heat-cfntools (part of the SUSE Cloud ISO).

Depending on the virtualization platform on which you want to use the image, make sure the image also fulfills the following requirements:

Image Requirements Depending on Hypervisor

KVM

Appliance format: If you are using SUSE Studio or SUSE Studio Onsite 1.3 to build images, use the SUSE Cloud/OpenStack/KVM (.qcow2) format.

If you still use SUSE Studio Onsite 1.2 to build images, you choose the USB Stick/Hard Disk Image format instead and before uploading it to SUSE Cloud, convert the image to qcow2. For details, refer to Procedure 2.2.

VMware

Appliance format: VMware / VirtualBox / KVM (.vmdk)

All images must be flat (that means contained within one file). Both thick and thin provisioned .vmdk images are supported.

Adding Images

If you have created an image for SUSE Cloud/OpenStack/KVM with SUSE Studio or with SUSE Studio Onsite 1.3, you can upload the image directly as described in Procedure 2.3, “Uploading Disk Images to SUSE Cloud”. If you used an older version of SUSE Studio Onsite and have created an image for USB Stick/Hard Disk Image, convert it first as described in Procedure 2.2, “Converting Disk Images to qcow2 Format”.

Procedure 2.2. Converting Disk Images to qcow2 Format

The qcow2 format helps to optimize disk space as it consumes disk space only when contents are written on it.

Make sure the virt-utils package is installed on the machine used for conversion.

Download the disk image from SUSE Studio.

Convert the image:

qemu-img convert -c -f raw -O qcow2 IMAGE_FILE FINAL_IMAGE_FILE

Procedure 2.3. Uploading Disk Images to SUSE Cloud

The following procedure shows how to upload a disk image using the glance command line tool that is contained in the package python-glanceclient.

Images have both content and metadata; the latter are also called properties. OpenStack Image does not check any image properties during upload. Therefore specify the image's properties as command line options. You can do so during image upload (using glance image-create) or with glance image-update after the image has already been uploaded. For details, refer to Section “Modifying Image Properties”.

In a shell, source the OpenStack RC file for the project that you want to upload an image to. For details, refer to Section “OpenStack RC File”.

Upload the image. For example, to upload a qcow2 image, use the following command:

glance image-create --name="IMAGE_NAME" \
  --is-public=True --container-format=bare \
  --disk-format=qcow2 < PATH_TO_FINAL_IMAGE_FILE

For specifying additional image properties, refer to Procedure 2.4, “Setting Image Properties for Architecture, Hypervisor and VM Mode”.

If the image upload has been successful, a message appears, displaying the ID that has been assigned to the image.

Updating Images

After having uploaded an image to SUSE Cloud, the image contents cannot be modified—only the image's metadata, see Procedure 2.4. To update image contents, you need to delete the current image and upload a modified version of the image.

Modifying Image Properties

Images have both contents and metadata; the latter are also called properties. The following properties can be attached to an image in SUSE Cloud. Set them from the command line when uploading or modifying images.

Image Properties

Name (--name, optional)

Specifies a name with which the image will be listed in the SUSE Cloud Dashboard and in the command line interface.

Kernel ID (optional)

The image's kernel ID. This parameter is only needed if an external Kernel is associated with the image. The ID points to the Kernel glance image.

Ramdisk ID (optional)

The image's ramdisk ID. This parameter is only needed if an external ramdisk is associated with the image. The ID points to the ramdisk glance image.

Container Format (--container-format, optional)

Indicates if the VM image's file format contains metadata about the actual virtual machine. Set it to bare as the container format string is not currently used in any OpenStack components anyway. For details, refer to http://docs.openstack.org/developer/glance/formats.html.

Disk Format (--disk-format, required)

Specifies the image's disk format. Example formats include raw, qcow2, and ami. For details, refer to http://docs.openstack.org/developer/glance/formats.html.

Public (--is-public, optional)

Boolean value, default: false. If set to true, the image is publicly available.

Hypervisor Type (optional)

If your cloud consists of both KVM and Xen nodes, specify at least the hypervisor type the image requires, otherwise it might be scheduled on an incompatible node. For example:

hypervisor_type=xen

Further example are: kvm, qemu, xenapi, and powervm.

Architecture (optional)

Specifies the architecture the image requires. For example:

architecture=x86_64

VM Mode (optional)

Specify the hypervisor ABI (application binary interface) with the vm_mode flag. It can take the values pv, hvm, or xen. Use vm_mode=xen for XEN PV image import, or vm_mode=hvm for XEN HVM image import. For KVM, the correct mode is selected automatically.

Procedure 2.4. Setting Image Properties for Architecture, Hypervisor and VM Mode

Setting image properties is especially relevant when using mixed virtualization environments. For example, to make sure that an image is only launched on appropriate hypervisors, you can specify properties referring to a certain architecture, hypervisor type, or application binary interface (ABI) that the image requires. Set those properties with the --property key value option. You can do so either directly during image upload (see Procedure 2.3) or after the image has been uploaded (as described below).

In a shell, source the OpenStack RC file for the project that you want to upload an image to. For details, refer to Section “OpenStack RC File”.

If you do not know the ID or the exact name of the image whose properties you want to modify, look it up with:

glance image-list

Use the glance image-update command to set the properties for architecture, hypervisor type, and virtual machine mode. For example:

glance image-update IMAGE_ID_OR_NAME \
  --property architecture=x86_64 --property hypervisor_type=xen \
  --property vm_mode=xen

For more information about the architecture, hypervisor_type, and vm_mode properties, refer to http://docs.openstack.org/grizzly/openstack-compute/admin/content/image-metadata.html.

To list all of the image's metadata, use:

glance image-show IMAGE_ID_OR_NAME

If you need to remove image properties, use the following command:

glance image-update IMAGE_ID_OR_NAME --purge-props

Viewing Images and Image Properties, Deleting Images

In the following, find some examples on how to view images or image properties or how to remove images from OpenStack Image.

Listing Images

glance image-list

Lists ID, name, disk format, and container format for all images in Image that the current user can access.

Showing Metadata for a Particular Image

glance image-show IMAGE_ID_OR_NAME

Shows metadata of the specified image.

Deleting an Image

glance image-delete IMAGE_ID_OR_NAME

Removes the specified image from OpenStack Image.

Viewing and Modifying Membership of Private Images

In the following, find some examples on how to view or modify membership of private images:

Listing Members a Private Image is Shared With

glance member-list --image-id IMAGE_ID

Lists the IDs of the projects whose members have access to the private image.

Listing Private Images Shared With a Member

glance member-list --tenant-id PROJECT_ID

Lists the IDs of private images that members of the specified project can access.

Granting Members Access to a Private Image

glance member-create [--can-share] IMAGE_ID_OR_NAME PROJECT_ID_OR_NAME

Grants the specified member access to the specified private image.

By adding the --can-share option, you can allow the members to further share the image.

Revoking Member Access to a Private Image

glance member-delete IMAGE_ID_OR_NAME PROJECT_ID_OR_NAME

Revokes the access of the specified member to the specified private image.

Managing Flavors

In OpenStack, flavors define the compute, memory, and storage capacity of nova computing instances. To put it simply, a flavor is an available hardware configuration for a server. It defines the “size” of a virtual server that can be launched.

A flavor consists of the following parameters:

Flavor Parameters

Name

Name for the new flavor.

VCPUs

Number of virtual CPUs to use.

RAM MB

Amount of RAM to use (in megabytes).

Root Disk GB

Amount of disk space (in gigabytes) to use for the root (/) partition.

Ephemeral Disk GB

Amount of disk space (in gigabytes) to use for the ephemeral partition. If unspecified, the value is 0 by default.

Ephemeral disks offer machine local disk storage linked to the lifecycle of a VM instance. When a VM is terminated, all data on the ephemeral disk is lost. Ephemeral disks are not included in any snapshots.

Swap Disk MB

Amount of swap space (in megabytes) to use. If unspecified, the value is 0 by default.

Default Flavors

m1.tiny (1 VCPU/0 GB Disk/512 MB RAM)

m1.small (1 VCPU/20 GB Disk/2048 MB RAM)

m1.medium (2 VCPU/40 GB Disk/4096 MB RAM)

m1.large (4 VCPU/80 GB Disk/8192 MB RAM)

m1.xlarge (8 VCPU/160 GB Disk/16384 MB RAM)

Flavors can be managed with the nova flavor-* commands, provided by the python-novaclient package.

Find examples for the key administration tasks below.

Listing Flavors

nova flavor-list

Lists all flavors with their ID and name, the amount of memory, the amount of disk space for the root partition and for the ephemeral partition, the swap, and the number of virtual CPUs.

Creating a Flavor

nova flavor-create FLAVOR_NAME FLAVOR_ID RAM_IN_MB ROOT_DISK_IN_GB \
  NUMBER_OF_VCPUS

When creating a flavor, you need to specify at least the parameters listed above. For optional parameters, refer to nova help flavor-create.

Deleting a Flavor

nova flavor-delete FLAVOR_ID_OR_NAME

Deletes the specified flavor.

Setting Quotas

To prevent system capacities from being exhausted without notification, cloud administrators can set up quotas. In OpenStack, quotas are currently defined per project. The default quotas that are initially applied to each project are specified in the nova.conf on the Control Node. For a description of the configuration options for quotas in that file, refer to http://docs.openstack.org/grizzly/openstack-compute/admin/content/list-of-compute-config-options.html. For details about how to change the default values in nova.config, refer to http://docs.openstack.org/grizzly/openstack-ops/content/projects_users.html#quotas.

Quotas contain the following parameters:

Quota Parameters

Metadata Items

Number of metadata items per instance.

VCPUs

Number of virtual CPUs that can be allocated in total.

Instances

Total number of instances.

Injected Files

Number of injected files.

Injected File Content Bytes

Number of bytes per injected file.

Volumes

Total number of volumes.

Gigabytes

Total size of all volumes, measured in gigabytes.

RAM (MB)

Total RAM size of all instances, measured in megabytes.

Floating IPs

Total number of floating IP addresses.

Fixed IPs

Total number of fixed IP addresses.

Security Group Rules

Number of security rules per security group.

Security Groups

Number of security groups.

Quotas can be managed with the nova quota-* commands, provided by the python-novaclient package.

Find examples for the key administration tasks below.

Showing Default Quota Values

nova quota-defaults

Lists the default quotas. They are hard-coded in OpenStack Compute.

Showing Quota Values for a Project

nova quota-show --tenant PROJECT_NAME

Lists the currently set quota values for a project.

Setting Quota Values for a Project

nova quota-update --instances 2 PROJECT_ID_OR_NAME

Sets the quota value for the instances parameter to 2 for the specified project. For a list of further options, refer to nova help quota-update.

Chapter 3. Using OpenStack APIs

The OpenStack project provides comprehensive API documentation, including an API Quick Start, a complete API reference, plus API guides dealing with individual OpenStack components like Compute, Identity, Image, or Object Storage. In addition to that, developer documentation for python developers and advanced users is available.

For details, refer to the documentation available at http://docs.openstack.org in the dedicated section Use or develop applications for OpenStack clouds.

Appendix A. Documentation Updates

This chapter lists content changes for this document since the initial release of SUSE® Cloud 1.0.

SUSE Cloud 2.0

The document was updated on the following dates:

Section “September 19, 2013 (SUSE Cloud 2.0) ”

September 19, 2013 (SUSE Cloud 2.0)

OpenStack Service Names

Replaced code names with the OpenStack services' real names, according to https://wiki.openstack.org/wiki/Documentation/Conventions#General_style_conventions. For example, talk of OpenStack Image instead of Glance.

Update to OpenStack Grizzly

The Dashboard and the command line chapter have been updated to the OpenStack Grizzly release on which SUSE Cloud 2.0 is based. This includes the following changes:

The following section has been added: Section “Managing Networks”.

Some categories have been added to the Dashboard's main screen, others changed name. Most importantly, the download option for RC files can now be found in the Access & Security category. See Section “SUSE Cloud Dashboard—Overview” and Section “OpenStack RC File”.

Image upload is now also possible via the Dashboard, though with limited options. For details, refer to Section “Managing Images”

The compute, memory, and storage capacity of the default flavors has changed. For details, refer to Section “Managing Flavors” or Section “Managing Flavors”.

The workflow for some tasks has changed, most notably for the following ones: Procedure 1.2, “Creating Users Accounts”, and Procedure 1.4, “Modifying User Assignments for a Project”, .

In addition to General Image Requirements, hypervisor-specific requirements have been added. Refer to Image Requirements Depending on Hypervisor.

SUSE Studio and SUSE Studio Onsite now have better integration with SUSE Cloud. For details, refer to Section “Building Images with SUSE Studio”.

To make sure that an image is only launched on appropriate hypervisors, you can specify respective properties that the image requires. For details, refer to Procedure 2.4, “Setting Image Properties for Architecture, Hypervisor and VM Mode”.