Managing your cloud resources with OpenStack/en: Difference between revisions

Jump to navigation Jump to search
Updating to match new version of source page
(Updating to match new version of source page)
(Updating to match new version of source page)
Line 2: Line 2:
''Parent page: [[Cloud]]''
''Parent page: [[Cloud]]''


OpenStack is the software suite used on Compute Canada 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 [http://docs.openstack.org/ OpenStack web site].
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 complete control over the 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 website].


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 [[Terraform]]; however, some tasks require using command line tools, for example [[#Sharing_an_image_with_another_project|sharing an image with another project]].
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 [[Terraform]]; however, some tasks require using command line tools, for example [[#Sharing_an_image_with_another_project|sharing an image with another project]].


=Projects=
=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 [[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 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.
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 [[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 of the 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 selecting the project's name.


Depending on your allocation, your project may be limited to certain types of VM [[Virtual_machine_flavors|flavors]]. For example, compute allocations will generally only allow "c" flavors, while persistent allocations will generally only allow "p" flavors.
Depending on your allocation, your project may be limited to certain types of VM [[Virtual_machine_flavors|flavors]]. For example, compute allocations will generally only allow "c" flavors, while persistent allocations will generally only allow "p" flavors.
Line 29: Line 29:


== Managing security groups ==
== 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 [[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 from other VMs in the default security group.
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 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.
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 drop-down menu of actions for the VM on the ''Project->Compute->Instances'' page.


==Using CIDR rules==
==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 [https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing CIDR]).
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 of the IP address must match exactly; if <code>/0</code> is appended, no bits must match and therefore any IP address will match it.
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 bits) 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 of the IP address must match exactly; if <code>/0</code> is appended, no bits must match and therefore any IP address will match it.


=Working with Volumes=
=Working with Volumes=


A volume provides storage which is not destroyed when a VM is terminated. On Compute Canada clouds, volumes use [https://en.wikipedia.org/wiki/Ceph_(software) Ceph] storage with either a 3-fold replication factor or [https://en.wikipedia.org/wiki/Erasure_code 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 [https://docs.openstack.org/cinder/latest/cli/cli-manage-volumes.html here]
A volume provides storage which is not destroyed when a VM is terminated. On our clouds, volumes use [https://en.wikipedia.org/wiki/Ceph_(software) Ceph] storage with either a 3-fold replication factor or [https://en.wikipedia.org/wiki/Erasure_code 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 [https://docs.openstack.org/cinder/latest/cli/cli-manage-volumes.html here]


==Creating a Volume==
==Creating a Volume==
Line 55: Line 55:
*Availability Zone: On the East and Arbutus clouds, the only option is <code>nova</code><br/>
*Availability Zone: On the East and Arbutus clouds, the only option is <code>nova</code><br/>


Finally click the blue "Create Volume" button.
Finally, click the blue "Create Volume" button.


==Accessing a Volume from a VM==
==Accessing a Volume from a VM==
[[File:Manage_attachments_EN.png|400px|thumb| Managing attachments command in Actions menu (Click for larger image)]]
[[File:Manage_attachments_EN.png|400px|thumb| Managing attachments command in Actions menu (Click for larger image)]]
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.
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".
* At the right-hand end of the line describing the volume is the Actions column; from the drop-down menu, select "Manage Attachments."
* In the "Attach To Instance" dropdown menu, select a VM.  
* In the "Attach To Instance" drop-down menu, select a VM.  
* Click the blue "Attach Volume" button.  
* 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 <code>/dev/vdb</code> or some similar location.
The process should complete in a few seconds. Then the Volumes page will show the newly created volume attached to your selected VM on <code>/dev/vdb</code> or some similar location.


==Formatting and Mounting an Empty Volume==
==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 [[Using a new empty volume on a Linux VM|Linux]] or [[Using a new empty volume on a Windows VM|Windows]] VM.
Before a newly created and attached volume can be used, it must be formatted and mounted. See instructions for doing this on a [[Using a new empty volume on a Linux VM|Linux]] or [[Using a new empty volume on a Windows VM|Windows]] VM.


==Booting from a Volume==
==Booting from a Volume==
Line 85: Line 85:


===Using the Dashboard===
===Using the Dashboard===
# Click on the ''Volumes'' left hand menu.
# 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''.
# 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 name for your new image.
Line 111: Line 111:
*If attached to <code>/dev/vda</code>, 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''.
*If attached to <code>/dev/vda</code>, 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 <code>/dev/vdb</code>, <code>/dev/vdc</code>, 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.
*With volumes attached to <code>/dev/vdb</code>, <code>/dev/vdc</code>, etc. you do not need to delete the VM it is attached to before proceeding. In the ''Actions'' column drop-down list, select ''Manage Attachments'', click on the ''Detach Volume'' button and again on the next ''Detach Volume'' button to confirm.


=Working with images=
=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 [[OpenStack#Working with Volumes|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.
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 [[OpenStack#Working with Volumes|volumes]]. Images are portable in that they can be downloaded 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 the Compute Canada clouds it must have cloud-init installed and configured correctly (see openstack docs on [https://docs.openstack.org/image-guide/create-images-manually.html creating images manually] for more details).
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 [https://docs.openstack.org/image-guide/create-images-manually.html creating images manually] for more details).


For a list of images provided by staff on Compute Canada clouds see [[Cloud resources#Images| images]].
For a list of images provided by our staff, see [[Cloud resources#Images| images]].


==Creating an Image from a VM==
==Creating an Image from a VM==
Line 127: Line 127:
the [[OpenStack Command Line Clients]] can be used with the command:
the [[OpenStack Command Line Clients]] can be used with the command:
{{Command| openstack server image create <server-name>}}
{{Command| openstack server image create <server-name>}}
where <code><server-name></code> 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.
where <code><server-name></code> 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===
===If booting from a volume===
Line 133: Line 133:


==Sharing an image with another project==
==Sharing an image with another project==
Sharing an image with another project is a two step process.
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 project owning the image must share it with a second project.
Line 148: Line 148:
</source>
</source>
where
where
<code><IMAGE_ID></code> is the ID of image to be shared, and <code><MEMBER_ID></code> is the ID of project to share with.  
<code><IMAGE_ID></code> is the ID of the image to be shared, and <code><MEMBER_ID></code> is the ID of the project to share it with.  


To accept the shared image a member in the second project uses the [[OpenStack_Command_Line_Clients#Separate_Command-line_interfaces|OpenStack]] command below.
To accept the shared image a member in the second project uses the [[OpenStack_Command_Line_Clients#Separate_Command-line_interfaces|OpenStack]] command below.
Line 161: Line 161:
where <code><IMAGE_ID></code> is ID of the image to update, <code><MEMBER_ID></code> is the ID of the second project, and <code><MEMBER_STATUS></code> is the new status of the image. Valid Values for status are <code>accepted</code>, <code>rejected</code>, and <code>pending</code>. The image will then be available for use and appear in the OpenStack dashboard's list of images in the second project.
where <code><IMAGE_ID></code> is ID of the image to update, <code><MEMBER_ID></code> is the ID of the second project, and <code><MEMBER_STATUS></code> is the new status of the image. Valid Values for status are <code>accepted</code>, <code>rejected</code>, and <code>pending</code>. 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.
To check the status of image membership use the following command.
<source lang="console">
<source lang="console">
[name@server]$ glance member-list --image-id <IMAGE_ID>
[name@server]$ glance member-list --image-id <IMAGE_ID>
Line 218: Line 218:
(previously the package was called <code>qemu-img</code>) then do the conversion with
(previously the package was called <code>qemu-img</code>) then do the conversion with
{{Command|qemu-img convert -f qcow2 vdisk.qcow2 -O vmdk vdisk.vmdk}}
{{Command|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 [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).
You can then 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).


= Working with VMs=
= Working with VMs=
Line 224: Line 224:
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.
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.<br/>
To '''lock''' a VM, click on the "Lock Instance" option from the Actions drop-down menu on the dashboard.<br/>
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.  
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.<br/>
To '''unlock''' a VM, select the "Unlock Instance" from the Actions drop-down menu on the dashboard.<br/>


==Resizing VMs==
==Resizing VMs==
Line 233: Line 233:


===c flavors===
===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 [https://en.wikipedia.org/wiki/Df_(Unix) <code>df -h</code>] command will not show the size increase). To see this extra space you will need to resize your filesystem (see the [https://linux.die.net/man/8/resize2fs <code>resize2fs</code>] 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]]).
"c" flavors often have extra ephemeral drives, which will be resized when you choose a new "c" flavor. These ephemeral drives cannot become smaller, and as such "c" flavor VMs can only be resized to flavors with equal or larger ephemeral drives. After resizing however, you will not immediately see a larger ephemeral drive within your VM (e.g. the [https://en.wikipedia.org/wiki/Df_(Unix) <code>df -h</code>] command will not show the size increase). To see this extra space you will need to resize your filesystem (see the [https://linux.die.net/man/8/resize2fs <code>resize2fs</code>] 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 recommended to create backups of its contents (see [[backing up your VM]]).


===p flavors===
===p flavors===
Line 245: Line 245:


==Granting admin privileges==
==Granting admin privileges==
In Ubuntu administrative, or root user privliges, can be given to a new user with the command
In Ubuntu administrative, or root user privleges, can be given to a new user with the command
{{Command|sudo visudo -f /etc/sudoers.d/90-cloud-init-users}}
{{Command|sudo visudo -f /etc/sudoers.d/90-cloud-init-users}}
which opens an editor where a line like
which opens an editor where a line like
38,939

edits

Navigation menu