Managing your cloud resources with OpenStack
Parent page: Cloud
OpenStack is the software suite used on our clouds 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 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), CLI, or a tool called Terraform; however, some tasks require using command line tools, for example sharing an image with another project.
Projects
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 if they are a member. You can view the projects you are a member of by logging into an OpenStack dashboard for the clouds you have access to (see 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 of the cloud logo. If you are a member of more than one project, you can switch between active projects by clicking on the dropdown menu and selecting the project's name.
Depending on your allocation, your project may be limited to certain types of VM flavors. For example, compute allocations will generally only allow "c" flavors, while persistent allocations will generally only allow "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.
Availability Zones
Availability zones allow you to indicate what group of physical hardware you would like your VM to run on. On East and Graham clouds, there is only one availability zone, nova, so there isn't any choice in the matter. However, on Arbutus there are three availability zones: Compute, Persistent_01, and Persistent_02. The Compute and Persistent zones only run compute or persistent flavors respectively (see virtual machine flavors). Using two persistent zones can present an advantage; for example, two instances of a website can run in two different zones to ensure its continuous availability in the case where one of the sites goes down.
Security Groups
A security group is a set of rules to control network traffic into and out of your virtual machines. To manage security groups, go to Project->Network->Security Groups. You will see a list of currently defined security groups. If you have not previously defined any security groups, there will be a single default security group.
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.
Default security group
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:
- 2 Egress rules to allow your instance to access an outside network without any limitation; there is one rule for IPV4 and one for IPV6.
- 2 Ingress rules to allow communication for all the VMs that belong to that security group, for both IPV4 and IPV6.
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 rules for SSH or RDP to your default security group so that you could connect to your VM.
Managing security groups
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 CIDR box (use this web based tool for converting 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 from 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 with the Security Groups option, or after the VM has been launched by selecting Edit Security Groups from the dropdown menu of actions for the VM on the Project->Compute->Instances page.
Using CIDR rules
CIDR stands for Classless Inter-Domain Routing and is a standardized way of defining IP ranges (see also this wikipedia page on CIDR).
An example of a CIDR rule is 192.168.1.1/24. This looks just like a normal IP address with a /24 appended to it. IP addresses are made up of 4, 1-byte (8 bit) numbers ranging from 0 to 255. What this /24 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 192.168.1 will match this CIDR rule. If /32 is appended, the full 32 bits of the IP address must match exactly; if /0 is appended, no bits must match and therefore any IP address will match it.
Working with Volumes
A volume provides storage which is not destroyed when a VM is terminated. On our clouds, volumes use Ceph storage with either a 3-fold replication factor or erasure codes to provide safety against hardware failure. On arbutus the Default volume type uses erasure codes to provide data safety while reducing the extra storage costs of 3-fold replication while the OS or Database volume type still uses the 3-fold replication factor. The More documentation about OpenStack volumes can be found here
Creating a Volume
To create a volume click 
and fill in the following fields:
- Volume Name:
data, for example - Description: Optional text
- Volume Source:
No source, empty volume - Type:
No volume type - Size (GiB):
40, or some suitable size for your data or operating system - Availability Zone: On the East and Arbutus clouds, the only option is
nova
Finally click the blue "Create Volume" button.
Accessing a Volume from a VM
To access the volume you must first attach it to a running VM. This is analogous to inserting a USB key or plugging an external drive into your personal computer. You can attach a volume from the Volumes page.
- At the right-hand end of the line describing the volume is the Actions column; from the dropdown menu, select "Manage Attachments".
- In the "Attach To Instance" dropdown menu, select a VM.
- Click the blue "Attach Volume" button.
The process should complete in a few seconds. Then the Volumes page will show the newly created volume attached to your selected VM on /dev/vdb or some similar location.
Formatting and Mounting an Empty Volume
Before a newly created and attached volume can be used it must be formatted and mounted. See instructions for doing this on a Linux or Windows VM.
Booting from a Volume
If you want to run a persistent machine, it is safest to boot from a volume. When you boot a VM from an image rather than a volume, the VM is stored on the local disk of the actual machine running the VM. If something goes wrong with that machine or its disk the VM may be lost. Volume storage has redundancy which protects the VM from hardware failure. Typically when booting from a volume VM flavors starting with a 'p' are used (see Virtual machine flavors).
There are several ways to boot a VM from a volume. You can
- boot from an image, creating a new volume, or
- boot from a pre-existing volume, or
- boot from a volume snapshot, creating a new volume.
If you have not done this before, then the first one is your only option. The other two are only possible if you have already created a bootable volume or a volume snapshot.
If creating a volume as part of the process of launching the VM, select Boot from image (creates a new volume), select the image to use, and the size of the volume. If this volume is something you would like to remain longer than the VM ensure that the "Delete on Terminate" box is unchecked. If you are unsure about this option, it is better to leave this box unchecked. You can manually delete the volume later.
Creating an Image from a Volume
Creating an image from a volume allows you to download the image. Do this if you want to save it as a backup, or to spin up a VM somewhere other than the CC Cloud, e.g. with VirtualBox. If you want to copy a volume to a new volume within the same cloud see cloning a volume instead. To create an image of a volume, it must first be detached from a VM. If it is a boot volume, it can only be detached from a VM if the VM is terminated/deleted.
Using the Dashboard
- Click on the Volumes left hand menu.
- Under the volume you wish to create an image of click on the drop down Actions menu and select Upload to Image.
- Choose a name for your new image.
- Choose a Disk Format. QCOW2 is recommended for using within the OpenStack cloud as it is relatively compact compared to Raw image format and works well with OpenStack. If you wish to use the image with Virtualbox the vmdk or vdi image formats might be better suited.
- Finally click Upload.
Using the Command Line Clients
The command line client can do this:
[name@server ~]$ openstack image create --disk-format <format> --volume <volume_name> <image_name>
where
- <format> is the disk format (two possible values are qcow2 and vmdk),
- <volume_name> can be found from the OpenStack dashboard by clicking on the volume name, and
- <image_name> is a name you choose for the image.
You can then download the image as described below. It is best to detach the volume from the VM before you create an image from the volume. If the volume is a boot volume you will likely need to delete your VM to detach it, however, make sure you have not checked "Delete Volume on Instance Delete" when creating the VM.
Cloning a Volume
Cloning is the recommended method for copying volumes. While it is possible to make an image of an existing volume and use it to create a new volume, cloning is much faster and requires less movement of data behind the scenes. This method is handy if you have a persistent VM and you want to test out something before doing it on your production site. It is highly recommended to shut down your VM before creating a clone of the volume as the newly created volume may be left in an inconsistent state if there was writing to the source volume during the time the clone was created. To create a clone you must use the command line client with this command
[name@server ~]$ openstack volume create --source <source-volume-id> --size <size-of-new-volume> <name-of-new-volume>
Detaching a Volume
Before detaching a volume, it is important to make sure that the operating system and other programs running on your VM are not accessing files on this volume. If so, the detached volume can be left in a corrupted state or the programs could show unexpected behaviours. To avoid this, you can either shut down the VM before you detach the volume or unmount the volume.
To detach a volume, log in to the OpenStack dashboard (see the list of links) and select the project containing the volume you wish to detach. Selecting Volumes -> Volumes displays the project’s volumes. For each volume, the Attached to column indicates where the volume is attached.
- If attached to
/dev/vda, it is a boot volume; you must delete the attached VM before the volume can be detached otherwise you will get the error message Unable to detach volume.
- With volumes attached to
/dev/vdb,/dev/vdc, etc. you do not need to delete the VM it is attached to before proceeding. In the Actions column dropdown list, select Manage Attachments, click on the Detach Volume button and again on the next Detach Volume button to confirm.
Working with images
Images are files which contain the contents of a virtual disk. Often Images contain a base operating system used to create a volume or an ephemeral disk from which a virtual machine boots. An ephemeral disk is a virtual disk file which resides on the host (or hypervisor) where the virtual machine runs. Ephemeral disk files are destroyed when a VM is destroyed, in contrast to volumes. Images are portable in that they can be download from the cloud, used to create a virtual machine using virtual box or similar on your laptop, and uploaded to another cloud and used to create a new virtual machine. This is not the case with volumes or ephemeral disks. Images come in a variety of formats. Some commonly encountered formats are, raw, qcow2, vmdk, and vdi.
If sharing your virtual machine images, be sure to remove sensitive information such as public/private keys, configuration files containing passwords etc. If uploading an image created from a virtual box virtual machine to our clouds it must have cloud-init installed and configured correctly (see openstack docs on creating images manually for more details).
For a list of images provided by our staff, see images.
Creating an Image from a VM
The procedure for creating an image of a VM depends on whether it is booting from a volume (typically "p" flavors), or from an ephemeral disk (typically "c" flavors).
If booting from an ephemeral disk
the OpenStack Command Line Clients can be used with the command:
[name@server ~]$ openstack server image create <server-name>
where <server-name> should be replaced with the name of your server. This action will only include the VM's root drive (e.g. /dev/vda) in the image. Ephemeral drives and non-boot attached volumes will not be included in the image so additional measures should be taken to preserve this data. In addition, if the VM is writing to disk while the image is being created the filesystem may be captured in an inconsistent state. We recommend the VM be shut off (not deleted) before an image is created from it.
If booting from a volume
see Creating an Image from a Volume
Sharing an image with another project
Sharing an image with another project is a two step process.
- A member of the project owning the image must share it with a second project.
- A member of the second project must accept the newly shared image.
To share an image a member in the project owning the image uses the OpenStack command below.
[name@server]$ glance member-create <IMAGE_ID> <MEMBER_ID>
+------------+-------------+---------+
| Image ID | Member ID | Status |
+------------+-------------+---------+
| <IMAGE_ID> | <MEMBER_ID> | pending |
+------------+-------------+---------+
where
<IMAGE_ID> is the ID of image to be shared, and <MEMBER_ID> is the ID of project to share with.
To accept the shared image a member in the second project uses the OpenStack command below.
[name@server]$ glance member-update <IMAGE_ID> <MEMBER_ID> <MEMBER_STATUS>
+------------+-------------+----------+
| Image ID | Member ID | Status |
+------------+-------------+----------+
| <IMAGE_ID> | <MEMBER_ID> | accepted |
+------------+-------------+----------+
where <IMAGE_ID> is ID of the image to update, <MEMBER_ID> is the ID of the second project, and <MEMBER_STATUS> is the new status of the image. Valid Values for status are accepted, rejected, and pending. The image will then be available for use and appear in the OpenStack dashboard's list of images in the second project.
To check the status of image membership use the below command.
[name@server]$ glance member-list --image-id <IMAGE_ID>
+------------+-------------+----------+
| Image ID | Member ID | Status |
+------------+-------------+----------+
| <IMAGE_ID> | <MEMBER_ID> | accepted |
+------------+-------------+----------+
where <IMAGE_ID> is the ID of the image to check the membership status of.
Downloading an Image
The first step is to install the OpenStack client and download the OpenStack RC file and source it (see OpenStack Command Line Clients). The OpenStack client can list the available images on your OpenStack project with
[name@server ~]$ openstack image list
producing something like:
+--------------------------------------+---------------------------------------+-------------+------------------+-------------+--------+ | ID | Name | Disk Format | Container Format | Size | Status | +--------------------------------------+---------------------------------------+-------------+------------------+-------------+--------+ | 982761b2-c77b-4852-8ae3-bf98b32b8894 | Hadoop-2.2.4 | qcow2 | bare | 10253107200 | active | | b7bd3033-9836-406d-a8f2-2e91978026b4 | hadoopmaster | qcow2 | bare | 3493527552 | active | | 2c751755-854d-49c3-af82-d501e51e7159 | hadoopmaster-active | qcow2 | bare | 13134004224 | active | | c41012f4-ed82-4478-a81f-5efb96a31b1a | hadoopmaster-old | qcow2 | bare | 3493527552 | active | | 78e61a3f-b546-441a-b476-a7077b04ca36 | hadoopslave | qcow2 | bare | 3490971648 | active | | 516845c3-b256-4c6d-a2cb-e31e822c7e34 | hadoopslave1-active | qcow2 | bare | 8345026560 | active | | 1546bd86-5314-4fce-9576-e2f6930dad30 | hadoopslave1-old | qcow2 | bare | 3490971648 | active | | baf78e8d-8288-4854-a66b-812cdf3ccbca | TestVM | qcow2 | bare | 13167616 | active | | 2faf97d7-5b0b-44ce-8024-3bef5a634570 | test_ubuntu_initial | qcow2 | bare | 1799487488 | active | | 308b6614-396a-4360-9c33-4e86f41ea0ec | trusty | qcow2 | bare | 256180736 | active | | 9b3c3fda-2aca-43b5-a3e7-662a94f5e7fb | Ubuntu_14.04_Trusty-amd64-20150708 | qcow2 | bare | 257884672 | active | | f93e66cf-fec1-4460-8fc7-506e716fbf30 | ucernvm-prod.1.18-10 | raw | bare | 20971520 | active | +--------------------------------------+---------------------------------------+-------------+------------------+-------------+--------+
You may need an additional option(s), such as --long, to see all the columns above depending on the version of the client you are using.
You can then download a particular image with
[name@server ~]$ openstack image save --file ./<file-name-for-image>.<format> <ID>
where <format> matches the value in the Disk format column and <ID> matches the value in the ID column.
Uploading an Image
The first step is to install the OpenStack client and download the OpenStack RC file and source it (see OpenStack Command Line Clients). Then run the command
[name@server ~]$ openstack image create --file <path-to-local-file-image> --disk-format <format> <new-image-name>
where
- <path-to-local-file-image> is the path to the file containing the image you wish to upload from your local machine,
- <format> is the disk format; if not specified, the raw format is assumed, which is incorrect since it can cause issues when using the image in OpenStack,
- <new-image-name> is the name of the image as it appears on the OpenStack dashboard.
Creating a VirtualBox VM from a Cloud Image
VirtualBox is a software package which allows you to create and run virtual machines on your desktop or laptop. It can be run on many different operating systems (Windows, Linux, Mac) and the virtual machines it creates may run one of many different operating systems.
To use a QCOW2 image downloaded from an OpenStack cloud, as shown above, with VirtualBox you will need to convert the image in the qcow2 format to the vmdk format. This can be done with the qemu-img tool. This can be installed with something like
[name@server ~]$ sudo apt-get install qemu-utils
(previously the package was called qemu-img) then do the conversion with
[name@server ~]$ qemu-img convert -f qcow2 vdisk.qcow2 -O vmdk vdisk.vmdk
Then you can create a new virtual machine and attach the vmdk image to it (see how to run a vmdk file in virtualbox for detailed instructions on this).
Working with VMs
Locking VMs
When working on a project with multiple people 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" option from the Actions dropdown menu on the dashboard.
Once a vm is locked most of the Actions menu items will not be able to be executed until the instance is unlocked. There is an icon indicating the lock state for every instance.
To unlock a VM, select the "Unlock Instance" from the Actions dropdown menu on the dashboard.
Resizing VMs
It is possible to resize a VM by changing its flavor. However, there are some things to be aware of when choosing to resize a VM which depends on whether you have a "p" flavor or a "c" flavor VM (see Virtual machine flavors). Resizing a VM may involve some risk as it is similar to deleting and recreating your VM with a new flavor, if in doubt contact cloud technical support.
c flavors
"c" flavors often have extra ephemeral drives, which will be resized when you choose a new "c" flavor. These ephemeral drives can not become smaller, and as such "c" flavor VMs can only be resized to flavors with equal or larger ephemeral drives. After the resize however, you will not immediately see a larger ephemeral drive within your VM (e.g. the df -h command will not show the size increase). To see this extra space you will need to resize your filesystem (see the resize2fs command). However, filesystem resizes should be treated with caution and can take considerable time if the partitions are large. Before resizing a filesystem it is recommend to create backups of its contents (see backing up your VM).
p flavors
Unlike "c" flavors, "p" flavors do not typically have extra ephemeral drives associated with them, so they can be resized to larger and smaller flavors.
Linux VM User Management
There are a number of ways to allow more than one person to log into a VM. We recommend creating new user accounts and adding public SSH Keys to these accounts.
Creating an account and keys
A new user account can be created on Ubuntu with the command
[name@server ~]$ sudo adduser --disabled-password USERNAME
To be able to connect, the new user will need to have a key pair, see generating SSH keys in windows or creating a key pair in Linux or Mac depending on the operating system they will be connecting from. Then their public key must be added to /home/USERNAME/.ssh/authorized_keys on the VM, ensuring permissions and ownership are correct as described in steps 2 and 3 of connecting using a key pair.
Granting admin privileges
In Ubuntu administrative, or root user privliges, can be given to a new user with the command
[name@server ~]$ sudo visudo -f /etc/sudoers.d/90-cloud-init-users
which opens an editor where a line like
USERNAME ALL=(ALL) NOPASSWD:ALL
can be added. For more detailed information about the visudo command and how to edit this file see this digitalocean tutorial on the topic.
Add users with CloudInit during VM creation
Alternatively, you can do this during the creation of a VM using CloudInit. The following CloudInit script adds two users gretzky and lemieux with and without sudo permissions respectively.
#cloud-config
users:
- name: gretzky
shell: /bin/bash
sudo: ALL=(ALL) NOPASSWD:ALL
ssh_authorized_keys:
- <Gretzky's public key goes here>
- name: lemieux
shell: /bin/bash
ssh_authorized_keys:
- <Lemieux's public key goes here>
For more about the YAML format used by CloudInit, see YAML Preview. Note that YAML is very picky about white space formatting, so that there must be a space after the "-" before your public key string. Also, this configuration overwrites the default user that is added when no CloudInit script is specified, so the users listed in this configuration script will be the only users on the newly created VM. It is therefore vital to have at least one user with sudo permission. More users can be added by simply including more - name: username sections.
If you wish to preserve the default user created by the distribution (users debian, centos, ubuntu, etc.), use the following form:
#cloud-config
users:
- default
- name: gretzky
shell: /bin/bash
sudo: ALL=(ALL) NOPASSWD:ALL
ssh_authorized_keys:
- <Gretzky's public key goes here>
- name: lemieux
shell: /bin/bash
ssh_authorized_keys:
- <Lemieux's public key goes here>
After the VM has finished spawning, look at the log to ensure that the public keys have been added correctly for those users. The log can be found by clicking on the name of the instance on the "Compute->Instances" panel and then selecting the "log" tab. The log should show something like this:
ci-info: ++++++++Authorized keys from /home/gretzky/.ssh/authorized_keys for user gretzky++++++++ ci-info: +---------+-------------------------------------------------+---------+------------------+ ci-info: | Keytype | Fingerprint (md5) | Options | Comment | ci-info: +---------+-------------------------------------------------+---------+------------------+ ci-info: | ssh-rsa | ad:a6:35:fc:2a:17:c9:02:cd:59:38:c9:18:dd:15:19 | - | rsa-key-20160229 | ci-info: +---------+-------------------------------------------------+---------+------------------+ ci-info: ++++++++++++Authorized keys from /home/lemieux/.ssh/authorized_keys for user lemieux++++++++++++ ci-info: +---------+-------------------------------------------------+---------+------------------+ ci-info: | Keytype | Fingerprint (md5) | Options | Comment | ci-info: +---------+-------------------------------------------------+---------+------------------+ ci-info: | ssh-rsa | ad:a6:35:fc:2a:17:c9:02:cd:59:38:c9:18:dd:15:19 | - | rsa-key-20160229 | ci-info: +---------+-------------------------------------------------+---------+------------------+
Once this is done, users can log into the VM with their private keys as usual (see SSH Keys).