Managing your cloud resources with OpenStack: Difference between revisions

OpenStack is the software suite used on the Compute Canada Cloud to control hardware resources such as computers, storage and networking. It allows the creation and management of virtual machines ("VMs", or "instances"), which act like separate individual machines, by emulation in software. This allows users complete control over their computing environment, from choosing an operating system to software installation and configuration. Diverse use cases are supported, from hosting websites to creating virtual clusters. More documentation on OpenStack can be found at the [http://docs.openstack.org/ OpenStack web site].

This page describes how to perform common tasks encountered while working with OpenStack. It is assumed that you have already read [[Cloud Quick Start]] and understand the basic operations of launching and connecting to a VM. Most tasks can be performed using either the dashboard (as described below), [[OpenStack Command Line Clients|CLI]], or a tool called [https://www.terraform.io/ terraform]; however, some require using command line tools, for example [[#Sharing_an_image_with_another_project|sharing an image with another project]].

OpenStack projects group VMs together and provide a quota out of which VMs and related resources can be created. A project is unique to a particular cloud. All accounts which are members of a project have the same level of permissions, meaning anyone can create or delete a VM within a project they are a member of. You can view the projects you are a member of by logging into an OpenStack dashboard for the cloud(s) you have access to (see [[Cloud#Using_the_Cloud|using the cloud]] for a list of cloud URLs). The active '''project name''' will be displayed in the top left of the dashboard to the right cloud logo. If you are a member of more than one project you can switch between active projects by clicking on the drop down menu and clicking a project name.

Depending on your allocation your project may be limited to certain types of VM [[Virtual_machine_flavors|flavors]]. For example, if you have a compute allocation your project maybe limited to only "c" flavors, while if you have a persistent allocation your project maybe limited to only "p" flavors.

Projects can be thought of as owned by primary investigators (PIs) and new projects and quota adjustments can only be requested by PIs. In addition request for access to an existing project must be confirmed by the PI owning the project.

To add or remove rules from a security group, click ''Manage Rules'' beside that group. When the group description is displayed, you can add or remove rules by clicking the ''+Add Rule'' and ''Delete Rule'' buttons.  

[[File:Default_security_group_rules_en.png|400px|thumb| Default Security Group Rules (Click for larger image)]]

The '''default security group''' contains rules which allow a VM access out to the internet, for example to download operating system upgrades or package installations, but does not allow another machine to access it, except for other VMs belonging to the same default security group. We recommend you do not remove rules from the default security group as this may cause problems when creating new VMs. The image on the right shows the default security group rules that should be present:

It is safe to add rules to the default security group and you may recall that we did this in [[Cloud Quick Start]] by either adding security rule for [[Creating_a_Linux_VM#Firewall.2C_add_rules_to_allow_SSH|SSH]] or [[Creating_a_Windows_VM#Firewall.2C_add_rules_to_allow_RDP|RDP]] to your default security group so that you were able to connect to your VM.

You can define multiple security groups and a VM can belong to more than one security group. When deciding on how to manage your security groups and rules, think carefully about what needs to be accessed and who needs to access it. Strive to minimize the IP addresses and ports in your Ingress rules. For example, if you will always be connecting to your VM via SSH from the same computer with a static IP it makes sense to allow SSH access only from that IP. To specify the allowed IP or IP range use the [[OpenStack#Using_CIDR_rules|CIDR]] box (use this web based tool for converting [http://www.ipaddressguide.com/cidr IP ranges to CIDR] rules). Further, if you only need to connect to one VM via SSH from the outside and then can use that as a gateway to any other Cloud VMs, it makes sense to put the SSH rule in a separate security group and add that group only to the gateway VM. However, you will also need to ensure your SSH keys are configured correctly to allow you to use SSH between VMs (see [[SSH Keys]]). In addition to CIDR, security rules can be limited within a project using security groups. For example, you can configure a security rule for a VM in your project running a MySQL Database to be accessible form other VMs in the default security group.

The security groups a VM belongs to can be chosen when it is created on the ''Launch Instance'' screen under the ''Access & Security'' tab, or after the VM has been launched by selecting ''Edit Security Groups'' form the drop down menu of actions for the VM on the ''Project->Compute->Instances'' page.

CIDR stands for Classless Inter-Domain Routing and is a standardized way of defining IP ranges (see also this wikipedia page on [https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing CIDR]).

An example of a CIDR rule is <code>192.168.1.1/24</code>. This looks just like a normal IP address with a <code>/24</code> appended to it. IP addresses are made up of 4, 1 byte (8 bit) numbers ranging from 0 to 255. What this <code>/24</code> means is that this CIDR rule will match the first left most 24 bits (3 bytes) of an IP address. In this case any IP address starting with <code>192.168.1</code> will match this CIDR rule. If <code>/32</code> is appended the full 32 bits are specified the IP address must match exactly, likely wise if a <code>/0</code> is appended no bits must match and therefor any IP address will match it.

Then you can create a new virtual machine and attach the vmdk image to it (see [http://techathlon.com/how-to-run-a-vmdk-file-in-oracle-virtualbox/ how to run a vmdk file in virtualbox] for detailed instructions on this).

== Locking VMs ==

When working with multiple people in a project or to protect a VM from accidental deletion or shutdown it can be useful to lock it.

To '''lock''' a VM, click on the "Lock Instance" from the action menu in the dashboard.<br/>

Once a vm is locked most of the action menu item will not be able to be executed until the instance is unlocked. There is an icon indicating the lock state for every instance.  

To '''unlcok''' a VM, select the "Unlock Instance" from the action menu in the dashboard.<br/>