07.md

+++ date = "2015-09-30" draft = false weight = 07 title = "Lab 07 - Nova - CLI" +++

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

1. SSH to your controller as root, you might use:

• Your browser (https://sshproxy.alta3.training/)

  Once logged into the browser, type screen -x <last initial><first initial> to return to your previous session

• Alternative, you may use PuTTY (Windows), or Terminal (Apple)

2. Once logged into the controller, issue the following command:

   [root@controller ]# source keystonerc_admin

3. 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     | public=172.24.4.231; 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

4. Highlight the id for the instance vt1 (NOT the Tenant ID), then issue the following command to get a list of details about the instance. Throughout this lab, we'll continually reference this highlighted ID, so we could keep highlighting it, or set a shell variable that we can reference.

• 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=replace_with_the_id_for_vt1_you_highlighted

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

5. Answer the following questions about the output:

• What time was this instance created?

• What flavor is being utilized?

• Is the machine powered on, or powered off?

• Which compute node is hosting this instance?

• What is the IP address of this instance?

• 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

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

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

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

9. Look to see that your first metadata tag has been set.

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

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

11. Look to see that your second metadata tag has been set.

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

12. Now remove the second metadata tag.

    [root@controller ~(keystone_admin)]# nova meta $VAR_UUID delete mtag2

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

1. Stop the instance (vt1)

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

2. Check to see if the instance (vt1) is really stopped

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

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

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

1. Try pausing the instance.

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

2. Use the CLI to confirm that the instance is paused

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

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

4. Try unpausing the instance

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

5. Use the CLI to confirm that the instance is unpaused

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

6. Once again, use the Horizon OpenStack dashboard as chestercopperpot // fa5tpa55w0rd to confirm that the instance is unpaused.

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.

1. Try suspending the instance

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

2. Use the CLI to confirm that the instance is suspended

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

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

4. Try resuming the instance

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

5. Use the CLI to confirm that the instance is resumed.

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

6. Once again, use the Horizon OpenStack dashboard as chestercopperpot // fa5tpa55w0rd to confirm that the instance is resumed.

5. Restaring an instance with admin

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

1. Issue the following command to reboot the instance (this is a graceful shutdown, to perform a forceful shutdown, include --hard after the reboot command)

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

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

• Continue to issue the nova show command until the instance is shown to be in a ACTIVE / running once again

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 logon and password)
• 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)

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

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

   +-----------+--------------+
   | Property  | Value        |
   +-----------+--------------+
   | adminPass | BpZh5d475JZ6 |
   +-----------+--------------+
   

• Answer the following questions:
• What is the value Property?
• What is the value Value?

2. To put and instance out of rescue mode, issue the following (you can do this, or not, it is up to you):

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

Way to go! That's it for this lab. Hang tight until the other students are caught up.