Skip to content

Latest commit

 

History

History
343 lines (212 loc) · 14.4 KB

12.md

File metadata and controls

343 lines (212 loc) · 14.4 KB
Raw
date draft weight title
2016-05-09
false
12
Lab 12 - Cinder
Mon Mon Mon Mon Tue Tue Tue Tue Wed Wed Wed Thur Thur Thur Thur
00 01 02 03 04 05 06 07 08 09 10 11 alt text 13 14

Lab Duration: 60 minutes

Lab Objective

The objective of this lab is to create a block storage volume with Cinder and then attach it to a VM instance. This is the virtual equivalent of plugging a new drive into a computer. Just like a physical drive, volumes can be attached, detached, reattached, and moved between VM instances.

1. Creating a block storage volume with Horizon

  1. Make sure that the cinder volumes are present!

    [root@controller ~]# pvdisplay

      --- Physical volume ---
  PV Name               /dev/loop1
  VG Name               cinder-volumes  <------ THIS NEEDS TO BE HERE!!!
  PV Size               20.60 GiB / not usable 2.00 MiB
  Allocatable           yes
  PE Size               4.00 MiB
  Total PE              5273
  Free PE               4249
  Allocated PE          1024
  PV UUID               AyQO5d-3MMa-xmzQ-EuMb-HLVt-DzvM-hdyEDz

    It is critical that you see VG Name = cinder-volumes
    If you do, then you are good, move on to the next step
    OTHERWISE, please let your instructor know!
    The Logical Volume Group must be reinstalled as follows:
    vgcreate cinder-volumes /dev/loop1
    systemctl restart openstack-cinder-volume.service

  2. Log into Horizon as chestercopperpot // fa5tpa55w0rd

  3. Navigate to Project > Compute > Volumes

  4. Click on the button +Create Volume (Look in the upper right corner)

  5. Fill out the pop-up window as follows:

    Name: cargo-bay
Description: new volume for vt2
Volume Source: No source, empty volume
Type: iscsi
Size (GB): 1
Availability Zone: Any Availability Zone
    • Click the Create Volume button

  6. Let's attach this volume to our VM instance (vt2)

  7. Under Actions click the drop down menu, and then select Manage Attachments

  8. In the pop-up window, select (vt2) from the drop down menu

  9. Click the Attach Volume button

    The volume will now be attached and mounted by our instance (vt2). It will take 20 to 30 seconds to attach.

    • Answer the following questions:

    • Is the volume being actively used by the instance (is it in-use)?

    • Where is the volume attached on vt2?

    • Is this a bootable volume?

    • Could you detach this volume from instance vt2, and attach it to a different instance? Why might you want to do this?

  10. Before we finish in Horizon, make sure vt2 is active and running (powered on). Navigate to Project > Compute > Instance, and then click the Start Instace beside vt2 if it is currently listed as Shutoff and Shut down (powered off). If vt2 is not powered off, but instead suspended, then you will need to select Resume Instance from the Actions dropdown menu.

2. Create a Cinder block storage volume using the CLI

  1. We'll replicate the same steps at the CLI that we just performed in Horizon. If you get the idea, and not particularly strong at the CLI, it is alright to skip this section.

  2. Issue the following commands

    [root@controller ~]# source keystonerc_chestercopperpot

    [root@controller ~(keystone_chestercopperpot)]# cinder create --display_name NASferatu 1

    • The above command says, "Cinder, I want you to create a volume named NASferatu that is 1 GB in size"

  3. Based on the output, answer the following questions:

    • Is this a bootable volume?

    • Is this volume encrypted?

    • What is the status?

  4. Issue the following command to retrieve a list of cinder volumes available to the current users chestercopperpot:

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

    • Note the ID of the volume for NASferatu

    • Has the status changed? What is it now?

  5. Issue the following command to retrive a list of the instances currently in operation

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

    • Note the ID of the instance vt2

  6. Issue the following command to attach the new volume (NASferatu) to a VM instance (vt2)

    [root@controller ~(keystone_chestercopperpot)]# nova volume-attach <replace_with_ID_of_instance_vt2> <replace_with_ID_of_volume_NASferatu> auto

    • The above commands says attached NASferatu to the instance vt2, and auto assign it (alternatively you could specify /dev/vdb, /dev/vdc/, etc.)

    • The output should look similar to the following:

    +----------+--------------------------------------+                                                                                                                                                                
| Property | Value                                |                                                                                                                                                                
+----------+--------------------------------------+                                                                                                                                                                
| device   | /dev/vdc                             |                                                                                                                                                                
| id       | d43ff424-684e-4aa4-953d-eb119e0c6a0d |                                                                                                                                                                
| serverId | 5eb02b66-0e74-429a-a4d1-6c70fe18d178 |                                                                                                                                                                
| volumeId | d43ff424-684e-4aa4-953d-eb119e0c6a0d |                                                                                                                                                                
+----------+--------------------------------------+

  7. Check on the status of the volume (NASferatu)

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

    • What is the status of NASferatu?

  8. Issue the following command to detach the volume from vt2

    [root@controller ~(keystone_chestercopperpot)]# nova volume-detach <replace_with_ID_of_instance_vt2> <replace_with_ID_of_volume_NASferatu>

  9. Check on the status of the volume (NASferatu)

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

    • What is the status of NASferatu?

  10. Now that the volume is detached, let's remove it

    [root@controller ~(keystone_chestercopperpot)]# cinder delete NASferatu

  11. Confirm that the volume has been deleted.

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

    • What is the state of NASferatu?

    • If it hasn't yet deleted, continue to issue the command until it is removed.

  12. In the next section, you will SSH into vt2. You should have started it in Horizon, but take a moment and make sure vt2 is powered on (and not shutoff). You can see which VMs are powered up, or down, by using the nova list command. If needed, vt2 can be started with the nova start vt2 command.

3. Moving volumes (and data) between instances

  1. Discover the IP address of vt2, later referenced as <IP_ADDRESS_of_vt2>

    nova show vt2 | grep network

    | vault-tek-network network            | 10.10.0.4

  2. Discover the router ID which will be needed to discover network namespace ID prefixed with "qrouter-"

    neutron router-list | cut -c -59

    +--------------------------------------+------------------+
| id                                   | name             |
+--------------------------------------+------------------+
| 5fddef2e-5cf4-4bb9-8617-57c2b9be8489 | vault-tek-router |
+--------------------------------------+------------------+

  3. SSH to neutron

    ssh root@neutron

    [root@neutron ~]#

  4. List the namespaces and find the "qrouter-" entry whose sufix matches the vault-tek-router's ID

    ip netns list

    qdhcp-20ca30a2-e3fb-4e62-bd78-08dc471e93ed
qdhcp-d5d84797-f546-4c41-8f63-7c44954fcb8b
qdhcp-854e1cb3-9234-43ce-b467-47d5bfdf3539
qrouter-fe2f3cd2-9099-41d8-b231-c567b5cb4802
qrouter-5fddef2e-5cf4-4bb9-8617-57c2b9be8489

  5. SSH into vt2 via the namespace you discovered in previous step

    ip netns exec <NAMESPACE> ssh cirros@<IP_ADDRESS_of_vt2>

    [root@neutron ~]# ip netns exec qrouter-5fddef2e-5cf4-4bb9-8617-57c2b9be8489 ssh [email protected]
[email protected]'s password:

    If you receive a 'no route to host' error, it is most likely because vt2 is powered off. To resolve, hop into Horizon as chestercopperpot, click on Project > Compute > Instances and then select Start Instance beside vt2.

  6. Here is the password

    cubswin:)

  7. Install a filesystem (assuming the drive is /dev/vdb)

    sudo mkfs.ext4 /dev/vdb

  8. Create a directory to serve as the mount point

    sudo mkdir -p /mnt/cargobay

  9. Mount the new directory

    sudo mount /dev/vdb /mnt/cargobay

  10. Who are you?

    whoami

  11. change the owner of cargo bay so you can easily add files as user = whoami

    sudo chown -R cirros /mnt/cargobay/

  12. Change directory into the newly mounted volume

    cd /mnt/cargobay

  13. Add a test message to /mnt/cargobay (your present location) with the following command.

    echo "This is a test message written to my cargo bay volume!" > test.txt

  14. Confirm that your file is there

    ls -l

  15. Unmount the volume in preperation for moving it to a new instance. (VERY IMPORANT)

    cd <-- be sure to issue this command first, otherwise you cannot unmount (can't saw off a limb you're standing on!)

    sudo umount /mnt/cargobay

  16. Exit your SSH session to vt2

    exit

  17. exit back to controller

    exit

  18. Discover the vault-tek-network ID

    neutron net-list | grep vault

    |       ID of vault-tek-network        | Name              | subnet-ID
------------------------------------------------------------------------------------------------------------------
| 854e1cb3-9234-43ce-b467-47d5bfdf3539 | vault-tek-network | 36ac8b4a-296f-4992-8248-dfccf2125da0 10.10.0.0/24    |

  19. Start a new instance (vt3... whatever you want). Use the same security-group (http-ssh) and network as vt2. Here is a sample if you want to try booting the new instance from the command line. Be sure the edit the net-id below because this one is just an example.

    nova boot --flavor m1.tiny --image cirros --nic net-id=<ID of vault-tek-network in the previous step> --security-groups http-ssh vt3

  20. Want to do a little practice? Delete the above VM and start it again on your own, both from the dashboard and also from the command line. WARNING, ONLY two machines will run and one time!!!

  21. Discover instance IDs

    nova list

    +--------------------------------------+------+---------+------------+-------------+-----------------------------+
| ID                                   | Name | Status  | Task State | Power State | Networks                    |
+--------------------------------------+------+---------+------------+-------------+-----------------------------+
| fd70c522-28da-4607-9610-af766440ac1a | vt2  | SHUTOFF | -          | Shutdown    | vault-tek-network=10.10.0.4 |
| 1accbf8d-0d0c-43be-b314-4f8d45672929 | vt3  | ACTIVE  | -          | Running     | vault-tek-network=10.10.0.5 |
+--------------------------------------+------+---------+------------+-------------+-----------------------------+

  22. Discover cinder volumes

    cinder list

    +--------------------------------------+--------+--------------+------+-------------+----------+--------------------------------------+
|                  ID                  | Status | Display Name | Size | Volume Type | Bootable |             Attached to              |
+--------------------------------------+--------+--------------+------+-------------+----------+--------------------------------------+
| b9f00354-0df1-4d5f-bc23-6423478cf334 | in-use |  cargo-bay   |  1   |    iscsi    |  false   | fd70c522-28da-4607-9610-af766440ac1a |
+--------------------------------------+--------+--------------+------+-------------+----------+--------------------------------------+

  23. Here is a nice way to discover where this volume is connected in your instance!

    cinder show cargo-bay | grep /dev/

    Most likely the volume will be connected to: /dev/vdb

  24. Detach cargo-bay

    nova volume-detach <vt2-ID> <cargo-bay_ID>

  25. Confirm detachment (Wait until status changes from "detaching" to "Available"

    cinder list

    +--------------------------------------+-----------+--------------+------+-------------+----------+--------------------------------------+
|                  ID                  |   Status  | Display Name | Size | Volume Type | Bootable |             Attached to              |
+--------------------------------------+-----------+--------------+------+-------------+----------+--------------------------------------+
| b9f00354-0df1-4d5f-bc23-6423478cf334 | detaching |  cargo-bay   |  1   |    iscsi    |  false   | fd70c522-28da-4607-9610-af766440ac1a |
+--------------------------------------+-----------+--------------+------+-------------+----------+--------------------------------------+

  26. The above status says 'detaching'; status needs to read 'available' before you can continue to attach the volume cargo-bay to the new instance vt3.

    nova volume-attach <vt3-ID> <cargo-bay-ID> auto

  27. SSH into vt3 (reference steps 1 to 6 for help)

  28. Mount cargo bay (reference steps 8 to 12 for help) <-- IMPORTANT !!!DO NOT REPERFORM STEP 7 OR YOU WILL DELETE YOUR TEXT FILE!!!

  29. Look at the new volume on vt3 and confirm it contains the test file that you created.