Scribd
Upload
6 views4 pages

LM14

open stack essentials

Uploaded by

Eugene Berna I
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
6 views4 pages

LM14

open stack essentials

Uploaded by

Eugene Berna I
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 4

Chapter 6.

Instance Management
In the past few chapters, we collected resources that laid the foundation to launch an instance.
We have created a tenant—a place for our resources to live in. We added a disk image that
the instance will use as its boot device. We created a network for the instance. Now, it is time
to launch the instance. Nova is the instance management component in OpenStack. In this
chapter, we will look at managing:

 Flavors
 Key pairs
 Instances
 Floating IPs
 Security groups
Managing flavors
When an instance is launched, there has to be a definition of the amount of resources that will
be allocated to the instance. In OpenStack, this is defined by what are called flavors. A
flavor defines the quantum of virtual CPUs, RAM, and disk space that an instance will use
when it launches. When Packstack installed your system earlier, it created a few flavors for
you. Let's take a look at those. Go ahead and source a keystonerc file. If you don't have one
sourced, then list the flavors, as follows:

control# nova flavor-list

You can create your own flavors if these don't fit your needs exactly. There's nothing magical
about the ones that Packstack has created. They have been created close to what the rest of
the cloud industry uses. We're not going to get too deep into flavors; we'll just use the
preconfigured flavors that you have just listed.

Managing key pairs


As a cloud image is a copy of an already existing disk image with an operating system
already installed, the root users are generally disabled, and if the root password is set, it is
usually not distributed. To overcome the inability to authenticate without a password,
OpenStack uses SSH key pairs. If you remember, in Chapter 4, Image Management, we
discussed the need for cloud-init to be installed in a cloud image. Then, in Chapter
5, Network Management, we discussed how cloud-init would connect to the metadata service
via the IP address provided by the router. One of the primary roles of this process is to pull
down the public SSH key that will be used for authentication. OpenStack provides a facility
for you to manage your SSH key pairs so that you can select which will be used when you
launch an instance. Let's start by generating a new key pair and listing it, as shown in the
following commands:

control# nova keypair-add my_keypair


-----BEGIN RSA PRIVATE KEY-----

{ truncated private key content }

-----END RSA PRIVATE KEY-----

control# nova keypair-list

This has generated an SSH public/private key pair and listed the record of the key pair. The
content that has been put on standard output should end up in a file in your home directory's
SSH directory with a mode of 600. OpenStack has generated the key pair, given you the
private key, and stored the public key to place on a future running instance. You could always
redirect the output to a file so that you don't have to copy and paste. This is an alternative
way to generate that key pair. The only difference is that the private key ends up in a file
instead of being printed in the terminal. Issue the following command to accomplish this:

control# nova keypair-add another_keypair > another.key

Once you have a file that contains the private key, for example, the other key file just created,
you can drop this file into your ~/.ssh directory with a mode of 600. Then, that file is
referenced to log in to a running instance that has the respective public key.
SSH key pairs are not anything specific to OpenStack. They are very commonly used in the
Linux world. OpenStack supports the importing of an already existing public key. Let's walk
through generating an SSH key pair outside of OpenStack and importing the public key into
OpenStack, as shown in the following commands:

laptop$ ssh-keygen

Generating public/private rsa key pair.

Enter file in which to save the key (/home/dradez/.ssh/id_rsa):


/home/dradez/.ssh/openstack.rsa

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved in


/home/dradez/.ssh/openstack.rsa.

Your public key has been saved in


/home/dradez/.ssh/openstack.rsa.pub.

The key fingerprint is:


4f:62:ee:b9:0f:97:35:f7:8a:91:37:84:0b:b9:cb:05 dradez@laptop

dradez@laptop:~$ ls -l /home/dradez/.ssh/openstack*

-rw-------. 1 dradez dradez 1675 /home/dradez/.ssh/openstack.rsa

-rw-r--r--. 1 dradez dradez 411


/home/dradez/.ssh/openstack.rsa.pub

As illustrated, on my laptop, I have generated a public/private key pair. The private key has a
mode of 600, and the public key is the file that will be imported into OpenStack. In the
OpenStack cluster, we're using the control node to interact with the cluster. Copy the public
key to your control node so that it can be imported, and import it into Nova, as shown in the
following command:

control# nova keypair-add --pub_key openstack.rsa.pub keypair_name

You can also manage key pairs in the web interface. In the Compute menu, select the Access
& Security submenu. On this page, there will be a Key Pairs tab. You can click on Create
Key Pair or Import Key Pair to manage key pairs through the web interface instead of on
the command line. The following screenshot captures how we can manage key pairs in the
web interface:

Launching an instance
At this point, there has been what may seem like an excessive amount of groundwork laid to
get to launching an instance. We now have a tenant for the instance to live in, an image
using which it can run, a network for it to live in, and a key pair to authenticate with. These
are all the necessary resources to create in order to launch an instance, and now that these
resources have been created, they can be reused for future instances that will be launched.
Without further delay, let's launch the first instance in this OpenStack environment as
follows:

control# nova boot --flavor 2 --image Fedora --key-name openstack --


nic net-id={network id} ""My First Instance""
This launches an instance using the small flavor, the key pair we just imported, the Fedora
image from Chapter 4, Image Management, and the tenant network from Chapter 5, Network
Management. This instance will go through a few different states before it's ready to use. You
can see the current state of your instances by listing them as follows:

control# nova list

This command will list the instances in your tenant. Once the instance boot process
completes, the instance will settle in an active state. The first time an instance boots, it will
take an extra minute or two because the image file has to be copied from Glance to the
hypervisor. Successive instance launches should happen in less than a minute. Administrative
users also have the ability to see all instances. If the admin's keystonerc file is sourced, pass
the –all-tenants option to see all instances, as shown in the following command:

control# nova list --all-tenants

Initially, the only communication you have with the instance is getting console logs or
connecting to the console via Nova, as follows:

control# nova console-log ""My First Instance""

control# nova get-vnc-console ""My First Instance"" novnc

The first command will print the console log of the instance if it's available. This is useful to
help debug why an instance won't start or to find out if it got an IP address from DHCP. The
second command will give you a URL that can be loaded into your browser to give you a
VNC console to the running instance.

You might also like