• Overview
• Getting Started
• User Guide
• Best Practice and Policies
• Glossary of Terms
• FAQs

As an OpenStack cloud end user, you can provision your own resources within the limits set by cloud administrators.

The examples in this guide show you how to perform tasks by using the following methods:

• OpenStack dashboard: Use this web-based graphical interface, code named horizon, to view, create, and manage resources.

• OpenStack command-line clients: Each core OpenStack project has a command-line client that you can use to run simple commands to view, create, and manage resources in a cloud and automate tasks by using scripts.

Openstack volumes are logical block devices that can be attached to a single instance to provide a persistent location for data storage. Unlike a virtual machine's local disk which is destroyed along with the VM, volumes are decoupled from instances so that they may be attached and reattached to different instances. This allows you to create & destroy instances as you see fit while maintaining a persistent store for data.

1. Create Volume.

From the Openstack dashboard, click Compute > Volumes > Create Volume, fill out the form by providing a meaningful name, description and size. Once this is done, click ‘Create Volume’. Your volume will be created and you can move on to the next step, ‘Attach a volume to an instance’.

2. Launching a virtual machine, You have to accomplish a number of steps.

a) Provide the initial hostname for the instance, the availability zone where it will be deployed, and the instance count. Increase the Count to create multiple instances with the same settings.:

b) Select the instance source, the template used to create an instance. You can use an image, a snapshot of an instance (image snapshot), a volume or a volume snapshot (if enabled). You can also choose to use persistent storage by creating a new volume.

For this example. The instance is launched from the image source and a new volume is created with the instance. The allocated ubuntu-18 image is selected from the list of available images and is going to be an Operating System (OS) for the instance/s created.

c) Decide on the flavor needed when launching the instance, Flavors manage the sizing for the compute, memory and storage capacity of the instance.

For this example. The instance is launched with m1.tiny flavor selected from the list of available flavors. The m1.tiny flavor will allocate the instance with 2x vCPU, 5GB of vRAM and 20GB of root disk. In order to carefully manage our compute resources, Only allocate what you are expecting to use, This is the total compute resources allocated to the instance created.

d) Select the network that your instance will connect to. The network provide the communication channels for instances in the cloud.

For this example. The instance is launched with demo-vxlan network selected from the list of available networks. The network provide the communication channel for instance/s in the cloud.

e) Select the security groups to launch the instance in.

For this example. The instance is launched with Default security group selected from the list of available security groups. The security groups are set of restrictive rules defined for the IP space, The selected default security group allows only ssh(22) and HTTPS(443). Openstack allows security groups editing after the instance has started, so additional changes can be made later if the exact requirements are not clearly defined.

f) Select an existing key pair, import a key pair, or generate a new key pair. A key pair allows you to SSH into your newly created instance.

g) Optionally, You can customize your instance after it has launched using the options available here. “Customization Script” is analogous to “User Data” in other systems.

h) Finally, click the Launch button. It will take a few minutes for the instance to start, depending on how large the base image you chose was, and if it was already cached or not on the physical server where the VM will be scheduled to start.

i) Associate a floating/public IP address.

By default, the VM will receive a private IP that is only reachable from inside your virtual network (other VMs connected to the same network). Because public IPv4 addresses are limited and there is an inherent security risk when connecting to the Internet, it is recommended to associate a floating/public IP address only to a single VM and use that one as an access server into your cloud environment.