In this classroom environment, your primary system for hands-on activities is workstation.
The workstation virtual machine (VM) is the only one with a graphical desktop, which is required for using a browser to use remote dashboard and GUI tools.
You should always log in directly to workstation first.
From workstation, use SSH for command-line access to all other VMs.
Use a web browser from workstation to access the Red Hat OpenStack Platform (RHOSP), Dashboard web interface and other graphical UI tools.
As seen in SectionFigure 0.1: Classroom environment, all VMs share an external network, 172.25.250.0/24, with a gateway of 172.25.250.254 (workstation).
External network DNS services are also provided by workstation.
The overcloud virtual machines share an internal network containing multiple VLANs, using various 172.24.X.0/24 addresses.
Additional student VMs used for hands-on exercises include utility and power in the lab.example.com DNS domain, and controller0, compute0, compute1, computehci0, and ceph0 in the overcloud.example.com DNS domain.
The overcloud VMs share the provisioning network, 172.25.249.0/24, with the director and power nodes.
The undercloud uses the isolated and dedicated provisioning network to deploy the overcloud nodes.
The environment uses the classroom server as a NAT router to the outside network, and as a file server using the URLs content.example.com and materials.example.com, serving course content for certain exercises.
The workstation VM is also a router to the classroom network, and must remain running for proper operation of all other VMs.
The director virtual machine is not used for exercises in this course and should be left powered off to avoid having it affect classroom performance.
Table 1. Classroom Virtual Machines
| Machine name | IP addresses | Role |
|---|---|---|
workstation.lab.example.com
| 172.25.250.254 172.25.252.N | Graphical student workstation |
director.lab.example.com
| 172.25.250.200 172.25.249.200 | Standalone undercloud node as director |
power.lab.example.com
| 172.25.250.100 172.25.249.100 172.25.249.101 172.25.249.102 172.25.249.112 172.25.249.103 172.25.249.106 | Handles overcloud nodes IPMI power management |
utility.lab.example.com
| 172.25.250.220 172.24.250.220 | Identity management server and VLANs for provider networks |
controller0.overcloud.example.com
| 172.25.250.1 172.25.249.P 172.24.X.1 | A standalone overcloud controller node |
compute0.overcloud.example.com
| 172.25.250.2 172.25.249.R 172.24.X.2 | An overcloud compute node |
compute1.overcloud.example.com
| 172.25.250.12 172.25.249.S 172.24.X.12 | Another overcloud compute node |
computehci0.overcloud.example.com
| 172.25.250.6 172.25.249.T 172.24.X.6 | An overcloud compute node with integrated storage |
ceph0.overcloud.example.com
| 172.25.250.3 172.25.249.U 172.24.X.3 | The overcloud block and object storage server node |
classroom.example.com
| 172.25.254.254 | The classroom materials and content server |
The workstation VM uses a student user with the password student.
The director VM uses the default stack user with the password redhat.
The root password on most VMs is redhat.
The overcloud nodes are preconfigured with a heat-admin account, used by the deployment service to configure these nodes.
Access to overcloud nodes is by key-based passwordless SSH access from workstation or director.
Table 2. System Credentials
| System Credentials | Username | Password |
|---|---|---|
| Unprivileged shell login (as directed) |
student
|
student
|
| Privileged shell login (as directed) |
root
|
redhat
|
| Undercloud node unprivileged access |
stack
|
redhat
|
| Undercloud node privileged access |
root
|
redhat
|
| Overcloud node unprivileged access |
heat-admin
| passwordless SSH |
| Overcloud node privileged access |
root
| Use sudo -i
|
Table 3. Application Credentials
| Application Credentials | Username | Password |
|---|---|---|
| Red Hat Identity Manager admin |
admin
|
RedHat123^
|
| Red Hat OpenStack Platform overcloud admin |
admin
|
redhat
|
| Red Hat OpenStack Platform overcloud user | as directed |
redhat
|
| Red Hat OpenStack Platform undercloud admin |
admin
|
redhat
|
Procedures for managing RHOSP classrooms are different than for production environments. Typically, OpenStack overclouds require resilient, low latency communication between all undercloud and overcloud nodes. Nodes can be taken offline or rebooted for maintenance, with no loss of functionality, due to redundant service configuration. In production, the full environment is rarely, if ever, shut down completely.
Always refer to current RHOSP documentation for the supported overcloud start and stop procedures for production environments. Classroom procedures discussed here might include shortcuts or exclude recommended procedures that are acceptable only for this custom classroom environment.
The major difference in a classroom environment is that it is built smaller than recommended for production use. This course uses virtual machines either deployed online or on a single physical system. Most training locations, both online and physical, automatically shut down student systems after timed use or after hours. Although automated shutdowns are not graceful, current RHOSP versions are resilient enough that classrooms restart and operate without difficulty.
SectionFigure 0.2: CL110-RHOSP16 classroom network topology shows the classroom environment node and network topology. This course refers to the nodes and network elements from this diagram regularly. It is recommended to copy this diagram for easy reference, by printing it or saving the image or page to your desktop.
This classroom configuration is prebuilt for your course using a default RHOSP Director-based deployment using customized TripleO templates.
The templates used for this build are located in the stack user's home directory on director, in the templates subdirectory.
Resetting your classroom environment is the procedure to set some or all of your classroom nodes back to their beginning state when the course was first created. Resetting allows you to clean your virtual machines, and start exercises over again. It is also a simple method for clearing a classroom issue which is blocking your progress and is not easily solved.
This RHOSP classroom has some specific constraints when you wish to reset part or all of your environment. In most Red Hat Training courses, individual systems can be reset separately as needed. However, in a course that uses an infrastructure cluster, such as the RHOSP overcloud, cluster nodes cannot be reset unless the whole cluster of nodes is reset together.
You may be instructed to reset a specific, named node, which always means a single virtual machine. However, if you are asked to reset the overcloud, then it is intended that you reset all OpenStack cluster nodes together. The commands for resetting individual nodes are discussed in the upcoming Sectionthe section called “Controlling Your Systems” section.
An OpenStack overcloud cluster consists of multiple nodes of various role types, working together as a single deployment environment. Along with the undercloud node that manages the overcloud, they all have a stateful relationship with each other, such as knowledge of activity status, required access keys, and pending responses. Resetting only a single cluster node could have that node lose necessary information and fail to communicate with other nodes after restarting. Resetting only a single cluster node could result in that node losing necessary information and fail to communicate with other nodes after restarting.
Some classroom nodes are not modified during exercises, and never need to be reset unless you are solving a technical problem.
For example, the workstation node would only need to be reset if it became unstable or out of communication, and could be reset by itself.
This table lists the nodes never intended to be reset and those intended to be reset as a group:
Table 4. Which nodes are normally reset or not reset together?
| Typically do not need to be reset | If required, then reset these only as a group |
|---|---|
|
|
[kiosk@foundation ~]$rht-vmctl reset undercloud[kiosk@foundation ~]$rht-vmctl reset overcloud
Click → for only``director and the undercloud nodes controller0, compute0, compute1, and ceph0.
Never reset the power node in the online environment.
If the power node is accidentally reset, then it will lose the credentials required to power manage the nodes.
The only recovery is to destroy and recreate the full classroom.
[kiosk@foundation ~]$ rht-vmctl reset allYou can also reset the classroom environment by recreating the original course build. Recreating the course is quick, typically only a few minutes, and results in a clean, working environment. In the online environment, click the button, wait, then click the button.
Repositories suitable for RPM package installation are available locally in your environment at http://content.example.com/rhosp16.0/x86_64/dvd/.
Software documentation is available at http://materials.example.com/docs/, which contains subdirectories for files in PDF and single page HTML format.
You are assigned remote computers in a Red Hat Online Learning classroom Self-paced courses are accessed through a web application hosted at If your course is an instructor-led virtual training, you will be provided with your course location URL Log in to this site using your Red Hat Customer Portal user credentials.
Controlling the Virtual Machines
The virtual machines in your classroom environment are controlled through web page interface controls The state of each classroom virtual machine is displayed on the Lab Environment tab.
Table 5. Machine States
| Virtual Machine State | Description |
|---|---|
| building | The virtual machine is being created. |
| active | The virtual machine is running and available. If just started, it can still be starting services. |
| stopped | The virtual machine is completely shut down. Upon starting, the virtual machine boots into the same state as it was before it was shut down. The disk state is preserved. |
Table 6. Classroom Actions
| Button or Action | Description |
|---|---|
| CREATE | Create the ROLE classroom. Creates and starts all of the virtual machines needed for this classroom. |
| CREATING | The ROLE classroom virtual machines are being created. Creates and starts all of the virtual machines needed for this classroom. Creation can take several minutes to complete. |
| DELETE | Delete the ROLE classroom. Destroys all virtual machines in the classroom. All work saved on that system's disks is lost. |
| START | Start all virtual machines in the classroom. |
| STARTING | All virtual machines in the classroom are starting. |
| STOP | Stop all virtual machines in the classroom. |
Table 7. Machine Actions
| Button or Action | Description |
|---|---|
Connect to the system console of the virtual machine in a new browser tab.
You can log in directly to the virtual machine and run commands, when required.
Normally, log in to the workstation virtual machine only, and from there, use ssh to connect to the other virtual machines. | |
| → | Start (power on) the virtual machine. |
| → | Gracefully shut down the virtual machine, preserving disk contents. |
| → | Forcefully shut down the virtual machine, while still preserving disk contents. This is equivalent to removing the power from a physical machine. |
| → | Forcefully shut down the virtual machine and reset the disk to its initial state. All work saved on that system's disks is lost. |
At the start of an exercise, if instructed to reset a single virtual machine node, click → for only the specific virtual machine.
At the start of an exercise, if instructed to reset all virtual machines, click → on every virtual machine in the list.
If you want to return the classroom environment to its original state at the start of the course, then click DELETE to remove the entire classroom environment After the lab has been deleted, click CREATE to provision a new set of classroom systems.
The DELETE operation cannot be undone All work you have completed in the classroom environment will be lost.
The Auto-stop and Auto-destroy Timers
The Red Hat Online Learning enrollment entitles you to a set allotment of computer time To help conserve your allotted time, the ROLE classroom uses timers, which shut down or delete the classroom when the appropriate timer expires.
To adjust the timers, locate the two + buttons at the bottom of the course management page Click the auto-stop + button to add another hour to the auto-stop timer Click the auto-destroy + button to add another day to the auto-destroy timer There is a maximum for auto-stop at 11 hours, and a maximum auto-destroy at 14 days Be careful to keep the timers set while you are working, so as to not have your environment unexpectedly shut down Be careful not to set the timers unnecessarily high, which could waste your subscription time allotment.