Managing your cloud resources with OpenStack: Difference between revisions

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 [http://docs.openstack.org/ OpenStack web site].

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.

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.

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.

Finally click the blue "Create Volume" button.

* 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.  

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.

# Click on the ''Volumes'' left hand menu.

*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.

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.

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).

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.

Sharing an image with another project is a two step process.

<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.  

To check the status of image membership use the below command.

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).

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

To '''unlock''' a VM, select the "Unlock Instance" from the Actions dropdown menu on the dashboard.<br/>

"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]]).

In Ubuntu administrative, or root user privliges, can be given to a new user with the command