date	draft	weight	title
2016-05-09	false	7	Lab 07 - Nova - CLI

Mon	Mon	Mon	Mon	Tue	Tue	Tue	Tue	Wed	Wed	Wed	Thur	Thur	Thur	Thur
00	01	02	03	04	05	06		08	09	10	11	12	13	14

Lab Duration: 25 minutes

Lab Objective

The objective of this lab is to teach basic administration of instances within the OpenStack cloud. Instances all have different 'states', and it is important to understand what those might be, and when it may be appropriate for an admin to force a customer instance into a different state. This lab has you select an instance from a project (which admin may or may not be a part of), and manipulate it as the OpenStack admin. If you finish this lab early, back through it again with an instance from a different project (tenant), or practice any admin skills involving instances ( diagnostic details / start / stop / suspend / pause / reboot / rescue).

1. Getting at an instance with admin

SSH to your controller as root
Once logged into the controller, issue the following command:

[root@controller ]# source keystonerc_admin

First look at all of the instances in the on the OpenStack cloud. Note that the command we are about to issue will not tell us any details about the instances that are running (what compute node is hosting the instance, the flavor it is running, the image being utilized, and so on). Type the following command:

[root@controller ~(keystone_admin)]# nova list --all-tenants

+--------------------------------------+----------+----------------------------------+---------+------------+-------------+------------------+
| ID                                   | Name     | Tenant ID                        | Status  | Task State | Power State | Networks         |
+--------------------------------------+----------+----------------------------------+---------+------------+-------------+------------------+
| a06d7547-d380-44e6-9be8-650240faada0 | vt1      | ad1d9eeaf2884c7e8eac33ec0f3ef6e5 | ACTIVE  | -          | Running     | private=10.0.0.7 | <-- Our instance from the last lab!
+--------------------------------------+----------+----------------------------------+---------+------------+-------------+------------------+

Your output might differ, after all this table is a reflection of what instances you have created. In the last lab, we all created an instance (vt1), so we should all see it ACTIVE and Running.
If the instance is not ACTIVE and Running, let the instructor know

Hey Rocket Scientists!
An interesting shortcut on step three is to try this:
VT1=`nova list --all-tenants | grep vt1 | cut -d ' ' -f 2`
Now enter echo $VT1 and only the Tenant ID will appear. Nice!
Here how it works:
VT1 is a variable name
A command surrounded by backticks ` COMMAND ` forces the output of the command to replace the command itself.
nova list --all-tenants will list all running VMs in openstack
| grep vt1 will filter out all VMs not named vt1
| cut -d ' ' set the delimiter character to a space
-f 7 means to display only the seventh field surrounded by spaces

You just issued a nova list command. The table displayed has several columns, these are: ID, Name, Tenant ID, Status, Task State, Power State, (and) Networks. Openstack works best when you reference UUIDs, NOT the human label names. The UUID that represents the VM (vt1) is diplayed in the column labeled, ID. So, we want to work with that UUID, but we don't want to keep typing that long UUID value! This problem can be solved by issuing the following command, which will set this value to shell variable called VAR_UUID.

We'll adhere to the convention of keeping all caps for the variable name (VAR_UUID), and set it to a simple string.

[root@controller ~(keystone_admin)]# VAR_UUID=zzzzzzzz-zzzz-zzzz-zzzz-zzzzzzzz <- customize zzz... for the UUID of vt1

[root@controller ~(keystone_admin)]# nova show $VAR_UUID

If you set the UUID correctly, your output should look like the following. Answer the questions below:

+--------------------------------------+----------------------------------------------------------+ | Property | Value | +--------------------------------------+----------------------------------------------------------+ | OS-DCF:diskConfig | MANUAL | | OS-EXT-AZ:availability_zone | nova | | OS-EXT-SRV-ATTR:host | compute2.localdomain <-- D | | OS-EXT-SRV-ATTR:hypervisor_hostname | compute2.localdomain <-- D | | OS-EXT-SRV-ATTR:instance_name | instance-00000008 | | OS-EXT-STS:power_state | 1 | | OS-EXT-STS:task_state | - | | OS-EXT-STS:vm_state | active <-- C | | OS-SRV-USG:launched_at | 2015-11-03T21:53:31.000000 | | OS-SRV-USG:terminated_at | - | | accessIPv4 | | | accessIPv6 | | | config_drive | | | created | 2015-11-03T21:52:08Z <-- A | | flavor | custom.shrimpy (6) <-- B | | hostId | 9fe51a49b6f300c621228a6c4eb6662d9b14a0bf2e12771b32e27528 | | id | a7eea3ea-15fc-4da5-907f-16d924b6b920 | | image | cirros (8a724f78-2673-4ea1-b607-373626a15afb) | | key_name | - | | metadata | {} | | name | vt1 | | os-extended-volumes:volumes_attached | [] | | private network | 10.0.0.11 <--- E | | progress | 0 | | security_groups | default | | status | ACTIVE <--- C | | tenant_id | 0fe62574bea74125ac00a0a2f8bcca18 <--F | | updated | 2015-11-03T21:53:32Z | | user_id | 98a3000acc3c4c3d98a29912ad40d740 | +--------------------------------------+----------------------------------------------------------+ ```

The answers to the following quetsions (A-F), are labeled (A-F) in the screenshot above.
A. What time was this instance created?
B. What flavor is being utilized?
C. Is the machine powered on, or powered off?
D. Which compute node is hosting this instance?
E. What is the IP address of this instance?
F. To what tenant does this instance belong?

Hint: Having trouble figuring out the tenant to which this instance belongs? Here's what to do, locate the value for 'tenant_id', it is a long UUID value. Issue a request to the identity service (keystone) for a list of all of the tenant IDs.

[root@controller ~(keystone_admin)]# keystone tenant-list

+----------------------------------+-------------+---------+
|                id                |     name    | enabled |
+----------------------------------+-------------+---------+
| 006bb1b9d65d47b2be38ee8a1e4492d0 |   acme_inc  |   True  |
| 300b2cc45c3846939e589310ae714e46 |    admin    |   True  |
| a9c27d47441e432c8529f8f30ea3261e |     demo    |   True  |
| 85a11a1515f94848be7aa5b56adec8bf |   services  |   True  |
| 1af0ab97a15547bd912904d25f9d479d | temp_tenant |   True  |
| 9b1fcd5488c4483ea29e8a5bfac9b9f8 |  vault_tek  |   True  |
+----------------------------------+-------------+---------+

To reveal the name of the tenant, match the value of 'tenant_id' with the displayed ids. Sometimes administrators need to troubleshoot issues with an instance. An admin can retrieve diagnostic information about an instance with the following command (once again, highlight the id of the instance)

[root@controller ~(keystone_admin)]# nova diagnostics $VAR_UUID

+---------------------------+-------------+
| Property                  | Value       |
+---------------------------+-------------+
| cpu0_time                 | 23740000000 |
| memory                    | 524288      |
| memory-actual             | 524288      |
| memory-rss                | 331204      |
| tap0b31c871-fd_rx         | 1938        |
| tap0b31c871-fd_rx_drop    | 0           |
| tap0b31c871-fd_rx_errors  | 0           |
| tap0b31c871-fd_rx_packets | 17          |
| tap0b31c871-fd_tx         | 4616        |
| tap0b31c871-fd_tx_drop    | 0           |
| tap0b31c871-fd_tx_errors  | 0           |
| tap0b31c871-fd_tx_packets | 84          |
| vda_errors                | -1          |
| vda_read                  | 17792512    |
| vda_read_req              | 995         |
| vda_write                 | 241664      |
| vda_write_req             | 87          |
+---------------------------+-------------+

Answer the following questions about the output from nova diagnostics:

(CPU details) What is the CPU time (in nano seconds)?
(Memory details) What is the max amount of memory (in MB)?
(Memory details) What is the actual amount of memory currently being used?
(Network details) How many octets have been received?
(Network details) How many octets have been dropped?
(Network details) How many packets have been transmitted?
(Disk details) How many disk reads have their been (in bytes)?
(Disk details) How many disk write requests have their been?

Now let's set some metadata about our instance. Here I am using mtag1, but you can use anything. Try starting with the following:

[root@controller ~(keystone_admin)]# nova meta $VAR_UUID set mtag1='vault_tek box'
Look to see that your first metadata tag has been set.

[root@controller ~(keystone_admin)]# nova show $VAR_UUID
Now let's set a second metadata tag concerning our instance.

[root@controller ~(keystone_admin)]# nova meta $VAR_UUID set mtag2='uh oh I set this tag incorrectly'
Look to see that your second metadata tag has been set.

[root@controller ~(keystone_admin)]# nova show $VAR_UUID
Now remove the second metadata tag.

[root@controller ~(keystone_admin)]# nova meta $VAR_UUID delete mtag2
Confirm the second metadata tag has been deleted.

[root@controller ~(keystone_admin)]# nova show $VAR_UUID

2. Starting and Stopping instances with admin

In this section, we'll start and stop an instance. If an instance is already stopped, it can't hurt to stop it. Just like if it's started, if won't hurt it to start the instance 'again' (in both cases a 409 HTTP error is returned).

Stop the instance (vt1)

[root@controller ~(keystone_admin)]# nova stop $VAR_UUID
Check to see if the instance (vt1) is really stopped

[root@controller ~(keystone_admin)]# nova show $VAR_UUID
Start the instance (vt1). Note that admin may or may not be part of this project, and is still able to manipulate this instance.

[root@controller ~(keystone_admin)]# nova start $VAR_UUID
Is the instance running? Find out by using the nova show command

[root@controller ~(keystone_admin)]# nova show $VAR_UUID

3. Pausing and unpausing instances with admin

In this section we'll pause and unpause a running instance. Pausing an instance stores the instance in memory (RAM), so in laptop terms, think of it as putting the instance into "sleep" mode.

Try pausing the instance.

[root@controller ~(keystone_admin)]# nova pause $VAR_UUID
Use the CLI to confirm that the instance is paused

[root@controller ~(keystone_admin)]# nova show $VAR_UUID
Use the browser to confirm that the instance is paused. Log into the Horizon OpenStack dashboard as chestercopperpot // fa5tpa55w0rd and confirm that the instance is indeed paused.
Try unpausing the instance

[root@controller ~(keystone_admin)]# nova unpause $VAR_UUID
Use the CLI to confirm that the instance is ACTIVE

[root@controller ~(keystone_admin)]# nova show $VAR_UUID
Once again, use the Horizon OpenStack dashboard as chestercopperpot // fa5tpa55w0rd to confirm that the instance is Running.

4. Suspending and resuming instances with admin

In this section we'll suspend and resume a running instance. Suspending an instance stores the instance on the disk, so in laptop terms, think of it as putting the instance into "hibernation" mode.

Try suspending the instance

[root@controller ~(keystone_admin)]# nova suspend $VAR_UUID
Use the CLI to confirm that the instance is suspended

[root@controller ~(keystone_admin)]# nova show $VAR_UUID
Use the browser to confirm that the instance is suspended. Log into the Horizon OpenStack dashboard as chestercopperpot // fa5tpa55w0rd and confirm that the instance is indeed suspended.
Try resuming the instance

[root@controller ~(keystone_admin)]# nova resume $VAR_UUID
Use the CLI to confirm that the instance is resumed.

[root@controller ~(keystone_admin)]# nova show $VAR_UUID
Once again, use the Horizon OpenStack dashboard as chestercopperpot // fa5tpa55w0rd to confirm that the instance is running.

5. Restarting an instance with admin

In this section we'll perform a reset of a customer instance (vt1) from the admin account.

Issue the following commands to reboot the instance and then view the status (this is a graceful shutdown, to perform a forceful shutdown, include --hard after the reboot command)

[root@controller ~(keystone_admin)]# nova reboot $VAR_UUID

HURRY! You have less than 1 second to issue the next command...
Just try again if you do not see the REBOOT status (No one ever gets this on the first try!) Most people issue the next command and it is already too late, so the status shows ACTIVE, therefore, use the up arrow key to reissue the nova reboot $VAR_UUID and the nova show $VAR_UUID back to back. The second try usually will give the results shown below. Of course you could always try issuing both commands on the same line: nova reboot $VAR_UUID && nova show $VAR_UUID but where is the challenge in that? :)

[root@controller ~(keystone_admin)]# nova show $VAR_UUID

+--------------------------------------+----------------------------------------------------------+
| Property                             | Value                                                    |
+--------------------------------------+----------------------------------------------------------+
| OS-DCF:diskConfig                    | MANUAL                                                   |
| OS-EXT-AZ:availability_zone          | nova                                                     |
| OS-EXT-SRV-ATTR:host                 | compute2.localdomain                                     |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | compute2.localdomain                                     |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000008                                        |
| OS-EXT-STS:power_state               | 1                                                        |
| OS-EXT-STS:task_state                | reboot_started                                           |
| OS-EXT-STS:vm_state                  | active                                                   |
| OS-SRV-USG:launched_at               | 2016-01-12T20:12:30.000000                               |
| OS-SRV-USG:terminated_at             | -                                                        |
| accessIPv4                           |                                                          |
| accessIPv6                           |                                                          |
| config_drive                         |                                                          |
| created                              | 2016-01-12T20:11:20Z                                     |
| flavor                               | custom.shrimpy (6)                                       |
| hostId                               | cdc9c3bf6f7af051fdafebba0f66a46f73d5d4532cf3274dfa782584 |
| id                                   | 1baa79d5-9c70-470b-ada7-9ca800e271dc                     |
| image                                | cirros (8a724f78-2673-4ea1-b607-373626a15afb)            |
| key_name                             | -                                                        |
| metadata                             | {"mtag1": "vault_tek box"}                               |
| name                                 | vt1                                                      |
| os-extended-volumes:volumes_attached | []                                                       |
| private network                      | 10.0.0.11                                                |
| security_groups                      | default                                                  |
| status                               | REBOOT <---- This is what you are looking for!           |
| tenant_id                            | f5db9e5a50ef40b593b05e6e9b3f0db5                         |
| updated                              | 2016-01-12T21:08:01Z                                     |
| user_id                              | 2767b86c1dbe4e029c84af1d7b444aa0                         |
+--------------------------------------+----------------------------------------------------------+

You will only have a moment to issue the nova show $VAR_UUID command, or the above screen will continue to show the VM as ACTIVE / running (it reboots VERY quickly!) If you don't catch it, no big deal, just study the above screenshot.

6. Starting an instance with rescue

Sometimes a user/customer will lock themselves out of their machine, or perhaps they corrupt their file system. The result is that they are unable to access or start their instance. The solution, is to start the machine with nova rescue.

nova rescue will first gracefully shutdown the instance (after 60 seconds, it will perform a poweroff, to increase this value, edit nova.conf)
This command attaches a secondary bootdisk, so that the instance's volumes can be accessed through a Linux image (new login and password is expressed as Property and Value)
Think of this process as removing a HDD from a computer that doesn't work, jamming it in a rescue machine so that you can try to fix it (or maybe reset the password)

To put a instance in rescue mode, issue the following:

[root@controller ~(keystone_admin)]# nova rescue $VAR_UUID
```
+-----------+--------------+
| Property  | Value        |
+-----------+--------------+
| adminPass | BpZh5d475JZ6 |
+-----------+--------------+
```
When SSH-ing into the rescued image:
Property means login
Value is the password
Consider watching the instance in the dashboard and observe the change from normal to rescue behavior

Take note what is happening in the process of rescuing.

[root@controller ~(keystone_admin)]# nova show $VAR_UUID

+--------------------------------------+----------------------------------------------------------+
| Property                             | Value                                                    |
+--------------------------------------+----------------------------------------------------------+
| OS-DCF:diskConfig                    | MANUAL                                                   |
| OS-EXT-AZ:availability_zone          | nova                                                     |
| OS-EXT-SRV-ATTR:host                 | compute2.localdomain                                     |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | compute2.localdomain                                     |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000008                                        |
| OS-EXT-STS:power_state               | 1                                                        |
| OS-EXT-STS:task_state                | rescuing                                                 |
| OS-EXT-STS:vm_state                  | active                                                   |
| OS-SRV-USG:launched_at               | 2016-02-23T21:26:32.000000                               |
| OS-SRV-USG:terminated_at             | -                                                        |
| accessIPv4                           |                                                          |
| accessIPv6                           |                                                          |
| config_drive                         |                                                          |
| created                              | 2016-02-23T21:25:21Z                                     |
| flavor                               | custom.shrimpy (6)                                       |
| hostId                               | 8c0689029626b5eeb90390611d7e22d06c3e61d0503d0406ee961ee1 |
| id                                   | fc323db2-a9e7-4428-80ad-4de14c54de32                     |
| image                                | cirros (8a724f78-2673-4ea1-b607-373626a15afb)            |
| key_name                             | -                                                        |
| metadata                             | {"mtag1": "vault_tek box"}                               |
| name                                 | vt1                                                      |
| os-extended-volumes:volumes_attached | []                                                       |
| private network                      | 10.0.0.11                                                |
| progress                             | 0                                                        |
| security_groups                      | default                                                  |
| status                               | ACTIVE                                                   |
| tenant_id                            | 41e84bdcf9a2414da2d6b674667923ce                         |
| updated                              | 2016-02-23T21:47:07Z                                     |
| user_id                              | 6696939a9d344a4d88d6823c330d7fce                         |
+--------------------------------------+----------------------------------------------------------+

After at least 60 seconds, try this. Hopefully the VM will be rescued by now!

[root@controller ~(keystone_admin)]# nova show $VAR_UUID

+--------------------------------------+----------------------------------------------------------+
| Property                             | Value                                                    |
+--------------------------------------+----------------------------------------------------------+
| OS-DCF:diskConfig                    | MANUAL                                                   |
| OS-EXT-AZ:availability_zone          | nova                                                     |
| OS-EXT-SRV-ATTR:host                 | compute2.localdomain                                     |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | compute2.localdomain                                     |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000008                                        |
| OS-EXT-STS:power_state               | 1                                                        |
| OS-EXT-STS:task_state                | -                                                        |
| OS-EXT-STS:vm_state                  | rescued                                                  |
| OS-SRV-USG:launched_at               | 2016-02-23T21:49:13.000000                               |
| OS-SRV-USG:terminated_at             | -                                                        |
| accessIPv4                           |                                                          |
| accessIPv6                           |                                                          |
| config_drive                         |                                                          |
| created                              | 2016-02-23T21:25:21Z                                     |
| flavor                               | custom.shrimpy (6)                                       |
| hostId                               | 8c0689029626b5eeb90390611d7e22d06c3e61d0503d0406ee961ee1 |
| id                                   | fc323db2-a9e7-4428-80ad-4de14c54de32                     |
| image                                | cirros (8a724f78-2673-4ea1-b607-373626a15afb)            |
| key_name                             | -                                                        |
| metadata                             | {"mtag1": "vault_tek box"}                               |
| name                                 | vt1                                                      |
| os-extended-volumes:volumes_attached | []                                                       |
| private network                      | 10.0.0.11                                                |
| security_groups                      | default                                                  |
| status                               | RESCUE                                                   |
| tenant_id                            | 41e84bdcf9a2414da2d6b674667923ce                         |
| updated                              | 2016-02-23T21:49:13Z                                     |
| user_id                              | 6696939a9d344a4d88d6823c330d7fce                         |
+--------------------------------------+----------------------------------------------------------+

Before we can stop vt1, it must first be taken out of rescue mode. Issue the following command:

[root@controller ~(keystone_admin)]# nova unrescue $VAR_UUID
That is it for this lab. If this is the last lab you'll be completing today, issue the following command to shut down vt1.

[root@controller ~(keystone_admin)]# nova stop $VAR_UUID

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

07.md

07.md

Lab Duration: 25 minutes

Lab Objective

1. Getting at an instance with admin

2. Starting and Stopping instances with admin

3. Pausing and unpausing instances with admin

4. Suspending and resuming instances with admin

5. Restarting an instance with admin

6. Starting an instance with rescue

Files

07.md

Latest commit

History

07.md

File metadata and controls

Lab Duration: 25 minutes

Lab Objective

1. Getting at an instance with admin

2. Starting and Stopping instances with admin

3. Pausing and unpausing instances with admin

4. Suspending and resuming instances with admin

5. Restarting an instance with admin

6. Starting an instance with rescue