Skip to content

Latest commit

 

History

History
328 lines (238 loc) · 20.9 KB

06.md

File metadata and controls

328 lines (238 loc) · 20.9 KB
Raw
date draft weight title
2016-05-09
false
6
Lab 06 - Nova - Flavors & Instances
Mon Mon Mon Mon Tue Tue Tue Tue Wed Wed Wed Thur Thur Thur Thur
00 01 02 03 04 05 alt text 07 08 09 10 11 12 13 14

Lab Duration: 60 minutes

Lab Objective

The objective of this lab is to launch an instance from the CLI (utilizing the Nova service). When an instance is launched, it is assigned a flavor, which is a set of resources. Flavors can be of the type public, or private, so we'll study both.

1. Creating new (public) flavors at the CLI

  1. SSH to your controller as root

  2. Run help on the nova service, and review the nova usage. For now, pay special attention to the flavor commands. You can run help by typing the following:

    [root@controller ~]# source keystonerc_admin

    [root@controller ~(keystone_admin)]# nova help | less

    For students who do not have much experience using the less command:

    • Press q to quit - Exit Less utility and return to the CLI
    • Press CTRL + F - Forward one window
    • Press CTRL + B - Back one window
    • Less utility cheat sheet (http://sheet.shiar.nl/less)

  3. Use nova flavor-list to see what default flavors are installed with OpenStack. When you see these, the concept of 'resources' should become more clear.

    [root@controller ~(keystone_admin)] nova flavor-list

    +----+-----------+-----------+------+-----------+------+-------+-------------+-----------+
| ID | Name      | Memory_MB | Disk | Ephemeral | Swap | VCPUs | RXTX_Factor | Is_Public |
+----+-----------+-----------+------+-----------+------+-------+-------------+-----------+
| 1  | m1.tiny   | 512       | 1    | 0         |      | 1     | 1.0         | True      |
| 2  | m1.small  | 2048      | 20   | 0         |      | 1     | 1.0         | True      |
| 3  | m1.medium | 4096      | 40   | 0         |      | 2     | 1.0         | True      |
| 4  | m1.large  | 8192      | 80   | 0         |      | 4     | 1.0         | True      |
| 5  | m1.xlarge | 16384     | 160  | 0         |      | 8     | 1.0         | True      |
+----+-----------+-----------+------+-----------+------+-------+-------------+-----------+

    RXTX Factor - Aggregate outbound bandwidth, in megabits per second, across all attached network interfaces (PublicNet, ServiceNet, and Cloud Networks). Outbound public Internet bandwidth can be up to 40% of the aggregate limit. Host networking is redundant, and bandwidth is delivered over two separate bonded interfaces, each able to carry 50% of the aggregate limit. We recommend using multiple Layer 4 connections to maximize throughput. Inbound traffic is not limited.
    Picking an example: In the first row (m1.tiny), RXTX factor of 1.0. This is one half of the information needed to determine how a perticular VM will be throttled. You must first determine the rxtx_base (configured in Nova). Multiplying RXTX_Factor along with rxtx_base will determine the bitrate for any perticular VM.

  4. Answer the following questions:

    • Q1: How many more VCPUs does m1.xlarge have over m1.tiny?
      • A1: 7! m1.xlarge has 8, m1.tiny only has 1
    • Q2: How much more memory does m1.xlarge have over m1.tiny?
      • A2: 15872 more, or about 15.5 GB more RAM
    • Q3: What do you think Is_Public means?
      • A3: It is possible a specific tenant might require access to a 'custom' flavor that we don't want other users to see. Such a flavor could be created with specific ACL permissions inplace, so that only certain tenants might see it. Such a protected flavor would have a Is_Public value of False.

  5. Maybe all of our customers want access to a specific flavor; one with 512 Mb of RAM, 2 volumes, 1 VCPU, named "custom.shrimpy". We can do that with the following command:

    [root@controller ~(keystone_admin)]# nova flavor-create custom.shrimpy 6 512 2 1

  • Question: Look at the command you just copy & pasted. The values 512 (Mb of RAM), and 2 (volumes), and 1 (VCPU) should be clear. So why was the value of 6 included?
  • Hint: Run the command "nova flavor-list", and examine the table once more. 1... 2... 3... 4... 5...
  • If the command is still unclear, run 'nova help flavor-create'

  1. Look for custom.shrimpy on the flavor list as multiple users. What we are illustrating, is that this is a publicly available flavor.

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

    +----+----------------+-----------+------+-----------+------+-------+-------------+-----------+
| ID | Name           | Memory_MB | Disk | Ephemeral | Swap | VCPUs | RXTX_Factor | Is_Public |
+----+----------------+-----------+------+-----------+------+-------+-------------+-----------+
| 1  | m1.tiny        | 512       | 1    | 0         |      | 1     | 1.0         | True      |
| 2  | m1.small       | 2048      | 20   | 0         |      | 1     | 1.0         | True      |
| 3  | m1.medium      | 4096      | 40   | 0         |      | 2     | 1.0         | True      |
| 4  | m1.large       | 8192      | 80   | 0         |      | 4     | 1.0         | True      |
| 5  | m1.xlarge      | 16384     | 160  | 0         |      | 8     | 1.0         | True      |
| 6  | custom.shrimpy | 512       | 2    | 0         |     	| 1     | 1.0         | True      |  <---- !!!
+----+----------------+-----------+------+-----------+------+-------+-------------+-----------+

  2. Switch to the user Alice Anderson, and confirm she can see the flavor. Type the following:

    [root@controller ~(keystone_admin)]# source keystonerc_aliceanderson

    [root@controller ~(keystone_aliceanderson)# nova flavor-list

  3. Switch to the user Chester Copperpot, and confirm he can see the flavor. Type the following:

    [root@controller ~(keystone_alicenaderson)]# source keystonerc_chestercopperpot

    [root@controller ~(keystone_chestercopperpot)]# nova flavor-list

2. Creating new (private) flavors at the CLI

Alice Anderson and her team from tenant acme_inc might need a custom flavor that is uniquely tuned for a project she is working on. For example, Alice's team needs to occasionally render video on a 'monster' instance with 125 GB of memory. We want Alice and her team to have access to this instance, but not our other customers. If we create a new flavor as described above, the user would have access to the custom flavor, but so would all other tenants in the cloud. Giving everyone access to a 'monster' flavor might not be desirable. Customers not requiring (or paying) for the 'monster' flavor might drive our cloud into full capacity rather quickly. To prevent this, lets restrict access to the custom flavor.

  1. If you haven't done so before, issue the nova help flavor-create command.

    [root@controller ~(keystone_chestercopperpot)]# nova help flavor-create

  • Review the output, then answer the following questions:
  • Is RAM described in GB or MB?
  • Is Disk size described GB or MB?
  • What is the default value for --is-public?

  1. Notice that a flavor may have an optional argument --is-public to be set as true or false, where the default is true. Let's toggle it to false and see what happens.

    [root@controller ~(keystone_chestercopperpot)]# source keystonerc_admin

    [root@controller ~(keystone_admin)]# nova flavor-create --is-public false secret.monster 8 125000 200 8

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

  • Why is the number 8 included after secret.monster?
  • Hint: If you've forgotten, scroll up a little bit and look at the output from the nova help flavor-create command
  • Do you see the new secret.monster flavor listed? Think for a moment. Why or why not?
  • Hint: Did we say which tenants have access to this secret flavor yet?

  1. Let us make sure that secret.monster was actually created. Type the following command to see both the public AND private flavor.

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

    +----+----------------+-----------+------+-----------+------+-------+-------------+-----------+
| ID | Name           | Memory_MB | Disk | Ephemeral | Swap | VCPUs | RXTX_Factor | Is_Public |
+----+----------------+-----------+------+-----------+------+-------+-------------+-----------+
| 1  | m1.tiny        | 512       | 1    | 0         |      | 1     | 1.0         | True      |
| 2  | m1.small       | 2048      | 20   | 0         |      | 1     | 1.0         | True      |
| 3  | m1.medium      | 4096      | 40   | 0         |      | 2     | 1.0         | True      |
| 4  | m1.large       | 8192      | 80   | 0         |      | 4     | 1.0         | True      |
| 5  | m1.xlarge      | 16384     | 160  | 0         |      | 8     | 1.0         | True      |
| 6  | custom.shrimpy | 512       | 2    | 0         |     	| 1     | 1.0         | True      |
| 8  | secret.monster | 125000    | 200  | 0         |     	| 8     | 1.0         | False     |  <---- !!!    
+----+----------------+-----------+------+-----------+------+-------+-------------+-----------+

  2. We need to tell OpenStack who should gain access to this project. Let's choose admin to start. Type the following to review the nova commands assocaited with flavor:

    [root@controller ~(keystone_admin)]# nova help | grep flavor

    flavor-access-add           Add flavor access for the given tenant.      
flavor-access-list          Print access information about the given flavor.   
flavor-access-remove        Remove flavor access for the given tenant.  
flavor-create               Create a new flavor  
flavor-delete               Delete a specific flavor 
flavor-key                  Set or unset extra_spec for a flavor. 
flavor-list                 Print a list of available 'flavors' (size of vm)
flavor-show                 Show details about the given flavor.

    [root@controller ~(keystone_admin)]# nova help flavor-access-add

    Add flavor access for the given tenant.

Positional arguments:
<flavor>     Flavor name or ID to add access for the given tenant.
<tenant_id>  Tenant ID to add flavor access for.

  3. Discover the admin's username id (id) and tenant ID (teantId)

    [root@controller ~(keystone_admin)]# keystone user-get admin

    +----------+----------------------------------+
| Property |              Value               |
+----------+----------------------------------+
|  email   |          root@localhost          |
| enabled  |               True               |
|    id    | e9483918caa940a48fe882ba092c7e0b | <-- admin username ID
|   name   |              admin               |
| tenantId | 300b2cc45c3846939e589310ae714e46 | <-- admin tenant ID (aaaa below)
| username |              admin               |
+----------+----------------------------------+

  4. Copy the admin tenantId

    [root@controller ~(keystone_admin)]# nova flavor-access-add 8 aaaa <-- replace aaaa with the tenantId from above [root@controller ~(keystone_admin)]# nova flavor-list

    You have just allowed the tenant admin access to flavor #8, secret-monster. This is why admin can now see the flavor

  5. In the next several steps, we'll give aliceanderson's tenant access to the secret.monster flavor as well.
    The commands you will use are all here, hold the control key and click: https://alta3.com/labs/openstack/keystone-commands/

  6. Discover aliceanderson's username id and tenantId [root@controller ~(keystone_admin)]# keystone user-get aliceanderson <-- Discover aliceanderson's tenantId

    +----------+----------------------------------+  
| Property |              Value               |  
+----------+----------------------------------+  
|  email   |                                  |  
| enabled  |               True               |  
|    id    | 070c514afa1a463882008c36a269ff87 | <--Alice's username ID
|   name   |          aliceanderson           |  
| tenantId | 37d530d789ca43ddae4ad18b395218ae | <- Alice's tenant ID (xxxx below)
| username |          aliceanderson           |  Example ONLY, please use your tenantId
+----------+----------------------------------+

    We now know aliceanderson's tenantId is a really big number, (37d530d789ca43ddae4ad18b395218ae), but unless we have a mind that can remember every customerID in our database, we probably do not remember that 37d530d789ca43ddae4ad18b395218ae is "acme_inc". Interestingly, since working on OpenStack, I constantly tell my wife that her new name is "070c514afa1a463882008c36a269ff87", but she NEVER responds. All she would have to do is a keystone user-get 070c514afa1a463882008c36a269ff87 and she would clearly see the association, but she refuses! I cannot figure out why...

  7. Just an FYI. If you wanted to correlate this realy big number (these big numbers are called UUIDs) to the associated label, you could perform the following step (this step is not critical to continuing the lab, this is strictly a teaching step).

    [root@controller ~(keystone_admin)]# keystone tenant-get xxxx <-- Replace xxxx with alice's tenantId from above

    +-------------+---------------------------------------------------------------+
|   Property  |                             Value                             |
+-------------+---------------------------------------------------------------+
| description | Acme Inc. is the world's leader in the production of widgets  |
|   enabled   |                              True                             |
|      id     |                37d530d789ca43ddae4ad18b395218ae               | <-- acme_inc's tenant (zzzz below)
|     name    |                            acme_inc                           |
+-------------+---------------------------------------------------------------+

  8. Give acme_inc access to flavor secret.monster

    [root@controller ~(keystone_admin)]# nova flavor-access-add 8 zzzz where zzzz = the tenant id from above

  9. Check out if you were successfull!

    [root@controller ~(keystone_admin)]# source keystonerc_aliceanderson

    [root@controller ~(keystone_aliceanderson)]# nova flavor-list

    Alice Anderson should see the presence of secret.monster displayed, as the tenant acme_inc was given access to the project

  10. Find out if Chester Copperpot (a tenant of VaultTek) can see the project.

    [root@controller ~(keystone_aliceanderson)]# source keystonerc_chestercopperpot

    [root@controller ~(keystone_chestercopperpot)]# nova flavor-list

    Failed? Good! The user chestercopperpot is a member of VaultTek and VaultTek cannot see the flavor secret.monster because VaultTek has not been given access to the flavor secret.monster.

3. Launching instances from the CLI

  1. Let's try launching some instances from the CLI. SSH to your controller and log in as root, source yourself as the keystonerc_chestercopperpot user permission set.

  2. See what flavor, images, and networks are available for use. Type the following commands:

    [root@controller ~(keystone_chestercopperpot)]# nova flavor-list

    [root@controller ~(keystone_chestercopperpot)]# glance image-list

    [root@controller ~(keystone_chestercopperpot)]# neutron net-list

    net-id

  3. There are a few things we have not studied yet that we are working with here. We have not studied networking yet. Normally, we would first create a network for a tenant, and then launch that instance within that tenant's private network. We can study that later, for now, copy the UUID assocaited with the of the private network (it was revealed with the command neutron net-list).

  4. Boot an instance called vt1 with the flavor custom.shrimpy, from the image cirros, and place it on the private network (more on networking is coming up)

    NOTE: Instances typically will be placed on their own tenant network, and include a 'security group' (a set of IP rules); things we haven't yet studied (we'll get there in subsequent labs). Launching an instance without defining a security group, will result in using the 'default' security group, which denies all incoming traffic.

    [root@controller ~(keystone_chestercopperpot)]# nova boot --flavor custom.shrimpy --image cirros --nic net-id=<xxxxxxxxxxxx> vt1

    where <xxxxxxxxx> = the internal private_network_id that you cut and paste from the above command neutron net-list

    +--------------------------------------+-----------------------------------------------+
| Property                             | Value                                         |
+--------------------------------------+-----------------------------------------------+
| OS-DCF:diskConfig                    | MANUAL                                        |
| OS-EXT-AZ:availability_zone          | nova                                          |
| OS-EXT-STS:power_state               | 0                                             |
| OS-EXT-STS:task_state                | scheduling                                    |
| OS-EXT-STS:vm_state                  | building                                      |
| OS-SRV-USG:launched_at               | -                                             |
| OS-SRV-USG:terminated_at             | -                                             |
| accessIPv4                           |                                               |
| accessIPv6                           |                                               |
| adminPass                            | 7XbbjiX9Pbcn                                  |
| config_drive                         |                                               |
| created                              | 2015-10-04T22:18:35Z                          |
| flavor                               | custom.shrimpy (7)                            |
| hostId                               |                                               |
| id                                   | bee8e2d9-ac2e-4190-a251-139216bb0a8b          |
| image                                | cirros (8a724f78-2673-4ea1-b607-373626a15afb) |
| key_name                             | -                                             |
| metadata                             | {}                                            |
| name                                 | vt1                                           |
| os-extended-volumes:volumes_attached | []                                            |
| progress                             | 0                                             |
| security_groups                      | default                                       |
| status                               | BUILD                                         |
| tenant_id                            | ad1d9eeaf2884c7e8eac33ec0f3ef6e5              |
| updated                              | 2015-10-04T22:18:36Z                          |
| user_id                              | 85787ab96a6f442a8ab51bac131175b4              |
+--------------------------------------+-----------------------------------------------+
  • Of course your output will be unique from what is listed above. Use your output to answer the following questions:
  • What is the task state?
  • What ID was this instance assigned?
  • What tenant does this instance belong to?
  • What name was this instance given?
  • What image was used to boot this instance?

  1. Display a list of the running instances within the current tenant

    [root@controller ~(keystone_chestercopperpot)]# nova list

  • What is the status?
  • What is the power state?
  • Hint: Issue the command again in a few minutes if they do not say "ACTIVE" and "Running" respectively.

  1. Display information only about the running instance vt1 that was just created:

    [root@controller ~(keystone_chestercopperpot)]# nova show vt1

  2. Log into the Horizon dashboard interface as chestercopperpot // fa5tpa55w0rd then navigate to:

  • Navigate to: Project > Compute > Instances
  • You've had some experience clicking around in Horizon instances before. Do it again! If nothing else, check out the log and console tabs for the instance.
  • This found by clicking on the instance name (vt1), then clicking on the log tab (or console tab).
  1. That's it for this lab! We'll continue to explore manipulating instances, but feel free to exploring launching instances from the CLI or Horizon, or checking out other Nova commands while you wait.