tutorial OpenStack Command Line Basics Part 2 - Creating VMs
#1
This is part two of my OpenStack tutorial on getting started with the basics. If you have not yet read part one please do so now because we will use some things we set up in that tutorial in this one. While using the web portal is much easier for someone just getting start with OpenStack, the command line client offers a lot more power and is much lighter weight.

To get started we first need to authenticate with OpenStack. If you are continuing directly from part one and have already done this once in your shell session then you can skip this step. If you have trouble with 403 errors then authenticate again just to be sure.

First set your credentials using the login-openrc file we created in the first tutorial.

[HackerMan@PentagonServer1]$ . login-openrc

Then request a token from OpenStack:

[HackerMan@PentagonServer1]$ openstack token issue

You should now have an authentication token and you will be able to create and manage your VMs. Before we can get started creating VMs we need to learn a few things about the resources available to us and set up a few other things.

The first and most important thing we will do is create a secure SSH key that we can later use to securely log in to our VMs without a password. This is very easy to do, but if you are operating from within the OpenStack shell and not a standard bash shell you should exit to the bash shell to make copying the key easy. From a standard shell it is easy to create a key using:

[HackerMan@PentagonServer1]$ openstack keypair create mykey > mykey.pem

Ok so what all just happened there? The first three parts of the command are openstack directives telling it that we want to create a new keypair for use by our VMs. The next bit sets the name for the key. Almost all objects in OpenStack can be named for easy management. The output of those first four words is the actual RSA key that is generated. It's not useful to us being printed on the screen so we need to capture it in a file to make use of it later, that is where the magic of linux command piping comes in to play. The last part of that command tells the linux operating system to take the output of the command and put it in a file called mykey.pem. If you look at the file that is created you will see the actual RSA key that was generated. It is very important to keep track of this key! Once a key has been generated in OpenStack it cannot be retrieved! That means if you lose a key there is no way to recover it and you will have to create a new one and rebuild all the instances that used the missing key.

One super critical detail with that key file is the permissions. If the permissions on that file are too open ssh will actually reject the key and you will not be able to log in. To fix this you simply need to change the permissions on the file:

[HackerMan@PentagonServer1]$ chmod go-rwx mykey.pem

This removes all permissions for all groups and all users. It makes it so that you are the only one who can view the file which makes it a much more secure key.

Next you will want to modify the default security group to allow ICMP traffic to your VMs (so you can ping your VMs) and TCP traffic on port 22 for SSH. To do this use the following command:

[HackerMan@PentagonServer1]$ openstack security group rule create --remote-ip 0.0.0.0/0 --protocol icmp --description "Allow ping" default
[HackerMan@PentagonServer1]$ openstack security group rule create --remote-ip 0.0.0.0/0 --protocol tcp --dst-port 22 --description "Allow SSH" default

This tells openstack to add a new rule to the security group 'default' that allows all icmp traffic from any remote IP address. This way you will be able to ping your VM from the controller as well as from other VMs on the network. 

All the basic setup is done at this point but we still need to learn a few things before we can create our VMs. First we need to know what flavors are available to us. A flavor is a way to tell OpenStack how much of a resource to give to a VM. Flavors control the number of processor cores and amount of RAM a VM gets, as well as how much storage space to give it. Creating flavors allows administrators to better control the usage of resources within a system while still allowing users to be flexible. We can view the list of available flavors for our VMs with:

[HackerMan@PentagonServer1]$ openstack flavor list

The output should look something like this:
Code:
+--------------------------------------+----------+------+------+-----------+-------+-----------+
| ID                                   | Name     |  RAM | Disk | Ephemeral | VCPUs | Is Public |
+--------------------------------------+----------+------+------+-----------+-------+-----------+
| 61cf8f44-10a7-4f56-b512-fed9cb851fe8 | m1.small | 2048 |   20 |         0 |     1 | True      |
| 806b21b9-ca6a-4495-9afc-5099db118745 | m1.tiny  |  512 |    1 |         0 |     1 | True      |
| d71b93db-366a-4cae-94c4-a8720ce97b9a | m1.mini  | 1024 |   10 |         0 |     1 | True      |
+--------------------------------------+----------+------+------+-----------+-------+-----------+

This shows you that there are three flavors available and what resources are available to each. We will have to chose one of these flavors when we actually create our VM.

The last thing we need to do before we can spawn our instance is to get a list of the boot images that are available. This is essentially like picking which installation disk to put in after we have built our computer. Our system has some of the more common operating systems already installed and ready to create and we can list them with:

[HackerMan@PentagonServer1]$ openstack image list

Which should produce something similar to:

Code:
+--------------------------------------+-------------------------------+--------+
| ID                                   | Name                          | Status |
+--------------------------------------+-------------------------------+--------+
| 90188f76-aeb2-456c-a78c-f5800de1bca7 | CentOS 7 Cloud                | active |
| 156f8398-e83d-47f6-9b08-059fb8da47fb | Cirros                        | active |
| b66f0bd0-aead-4247-b60c-b7577a12ca42 | Ubuntu Server 16.04 LTS Cloud | active |
+--------------------------------------+-------------------------------+--------+


At the time of writing this there are only three images available for use on the club servers. Each of these are specialized images that are meant to be run in cloud architectures. They have special features that allow them to be easily configured at startup without having to go through lengthy installation processes. If you just want to play around with creating VMs I would highly suggest Cirros as it is very small (it can run on m1.tiny with ease) and it does not require SSH keys to log in.

Now that we have our SSH key pair, modified our security group, listed flavors, and viewed our images, we can actually create or "spawn" an instance!

Creating instances is much easier than it seems. All that is required is simply:

[HackerMan@PentagonServer1]$ openstack server create --image Cirros --flavor m1.tiny --key-name mykey MyFirstServer

That command will return a large chunk of data about the instance that was just created. It's not important to save this information as you can retrieve information about any instance you own at any time. The build process takes a little time depending on the image, but you can check the progress of your VMs by running:

[HackerMan@PentagonServer1]$ openstack server list

Code:
+--------------------------------------+---------------+--------+------------------------+------------+
| ID                                   | Name          | Status | Networks               | Image Name |
+--------------------------------------+---------------+--------+------------------------+------------+
| 73a6d7fd-9f45-4ad2-9ea9-eaca1929ec62 | MyFirstServer | ACTIVE | provider=192.168.11.13 | Cirros     |
+--------------------------------------+---------------+--------+------------------------+------------+


This will show you some brief details about each instance you own within OpenStack. The two most important details are in the Status and Networks columns. The Status will tell you if your instance was created properly and is 'ACTIVE' or if it failed at startup. It will also tell you if your VM has been shutdown or is restarting. The networks column gives you a list of the IP addresses assigned to your VM. This is the IP address that you will use to log in to your VM to make changes or perform any tasks you may wish to perform.

Congrats! You now should have a running virtual machine within OpenStack! But we're not done quite yet. Now that you have a VM, how do you access it?

By default most cloud images only allow access through SSH with keys and no passwords. But that's not a problem since you should have created a keypair and assigned it to your VM. So all you need to do to log in to your new VM is provide a few extra options to SSH. So for example lets say that I want to log in to the newly created Cirros image. I know that the IP address of the instance is 192.168.11.13 and through a little google searching I can find that the default username for Cirros is simply cirros (usually with cloud images the admin account is named after the OS, so Ubuntu or Centos etc). I also remember that I have created a private key and saved it in a file called mykey.pem. So to log in to this newly running VM all I would have to do is run:

[HackerMan@PentagonServer1]$ ssh cirros@192.168.11.13 -i mykey.pem

It will ask you if you want to use the key provided, and then if everything works right you should be logged in to Cirros.

To start and stop your VM from OpenStack you can use:

[HackerMan@PentagonServer1]$ openstack server stop MyFirstServer

or

[HackerMan@PentagonServer1]$ openstack server start MyFirstServer

To reboot your VM you can use:

[HackerMan@PentagonServer1]$ openstack server reboot MyFirstServer

You can supply the reboot command with either --hard or --soft to tell it to soft or hard reboot the VM which can be useful for runaway VMs.

Each project within OpenStack has a resource quota that cannot be exceeded. This allows administrators to set a hard limit for resource use so that there are never more resources in use than what the hardware can provide. In our environment each project is allowed 2 VCPUs and 2048MB of RAM since we are limited on hardware. As our resources grow these quotas may increase and it may become useful to view your usage. Unfortunately I cannot remember the command to view quota status but I will update it when I find it again.

If at any time you want to delete your VM it is easy to do. Keep in mind that when you delete a VM all of its data will be deleted and cannot be recovered. It will not ask you to verify it so be sure that when you delete a VM you're sure you want to actually delete it. Once you are sure all you have to do is:

[HackerMan@PentagonServer1]$ openstack server delete MyFirstServer

That just about wraps up the basics of creating and managing VMs with OpenStack command line tools! If you have any additions or find any errors or issues please let me know so I can fix them!
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)