Horizon

OpenStack Horizon Dashboard

Learn how to use the OpenStack Horizon web dashboard to manage projects, instances, images, networks, storage, identity, quotas, and administrator functions.

OpenStack Horizon is the web-based dashboard for working with OpenStack cloud services. It provides graphical pages for common tasks such as launching virtual machines, creating networks, attaching volumes, managing images, and reviewing project quotas.

Horizon is an interface, not the cloud itself. Behind each page are OpenStack services and APIs, including Compute (Nova), Networking (Neutron), Block Storage (Cinder), Image (Glance), Identity (Keystone), and Object Storage (Swift). A dashboard action sends a request to one or more of these services. The exact pages and actions depend on the deployment, enabled services, policy rules, and your role.

What Horizon users can do

A project is an isolated OpenStack resource and access boundary. It was historically also called a tenant. Typical users include:

• Project members: Use resources permitted by their assigned roles, such as instances, networks, and volumes.
• Project administrators: Manage more of a project's resources, memberships, quotas, or configuration when policy permits.
• Cloud administrators: Perform cloud-wide tasks, inspect hosts and services, manage users and projects, and adjust policy-controlled settings.

OpenStack uses RBAC, or role-based access control, to decide which operations are allowed. A missing menu item does not necessarily indicate a dashboard error; it may mean that the current role, project, region, or deployment policy does not expose it.

Access and authentication

Open the Horizon URL supplied by the cloud operator. The login form commonly requests:

• Domain: An identity-management grouping for users, groups, and projects.
• Project or tenant: The project whose resources you will manage.
• User name and password: Credentials validated by the OpenStack Identity service.
• Region: A deployment-defined service location or endpoint grouping, when multiple regions are available.

Some deployments use federation, single sign-on, or customized login fields instead. Select the intended project and region carefully after authentication. Resources created in one project or region may not appear in another.

Sessions can expire because of an inactivity timeout, token expiration, browser settings, or an identity-service policy. Save important work before leaving a form, and use the user menu to log out when finished, especially on a shared computer. Logging out ends the dashboard session; it does not stop instances or remove other resources.

When login or access fails

• Recheck the domain, user name, password, project, and region.
• Retry after an expired session by signing in again.
• Check whether browser cookies or federation settings are interfering.
• Ask the cloud administrator to investigate identity-service, clock, or deployment configuration problems.

Dashboard layout and navigation

Although themes differ, a Horizon deployment commonly includes these elements:

• Project selector: Changes the project scope of project resources.
• Region selector: Changes the service location or endpoint grouping.
• Navigation menu: Opens project, identity, and administration panels that are available to the user.
• Overview pages: Summarize resources, usage, and quotas.
• Panels and tables: Display resources such as instances, networks, volumes, or users.
• Filters and pagination: Narrow a table or move through multiple pages of results.
• Action menus: Provide resource-specific operations such as edit, attach, resize, or delete.
• User menu: Provides account information, preferences, help, or logout controls.

Project panels contain resources belonging to the selected project. Identity panels manage domains, users, groups, projects, and roles when enabled. Administrative panels expose cloud-wide views to authorized administrators. Panel names and locations vary across Horizon versions and deployment customizations.

Project overview and quotas

The project overview summarizes consumption and limits for the selected project. A quota is a limit on how much of a resource a project may consume. Common quota categories include:

Quota displays may include instances, vCPUs, RAM, volumes, snapshots, floating IP addresses, networks, routers, and security groups. Quota usage can include resources that are not currently visible because of filters or a different page of results. If a limit is exhausted, delete unused resources or request an authorized administrator to review the quota.

Compute management

An instance is a virtual machine managed by the Compute service. The Instances table commonly shows status, IP addresses, flavor, image, availability zone, and power state. Open the instance details page for additional information such as attached ports, volumes, task state, and metadata.

How an instance is assembled

A launch combines several independent resources:

• An image supplies a bootable operating system or application template.
• A flavor supplies a predefined compute size, such as vCPUs, memory, and disk allocation.
• A network supplies connectivity, usually through a project-private network.
• A security group supplies virtual firewall rules for instance ports.
• A key pair supplies a public-key credential for SSH access to compatible images.
• Optional floating IP and router resources provide externally routable connectivity.

Launching an instance

1. Select the intended project and region.
2. Open the instance panel and choose the launch action.
3. Choose a source, such as an image, existing instance snapshot, or volume, depending on the deployment.
4. Select a flavor that fits the workload and available quota.
5. Select one or more networks. For a typical tenant workload, this is a private project network.
6. Select security groups. Choose rules that allow only required traffic.
7. Select a key pair for SSH access if the image and access method support it.
8. Choose an availability zone, instance count, configuration, metadata, and user-data where those fields are available.
9. Review the summary and submit the launch.
10. Wait for the instance to reach an appropriate state, commonly ACTIVE, before issuing another lifecycle operation.

Instance lifecycle actions

Depending on policy and deployment support, an action menu may provide start, stop, reboot, pause, suspend, resize, rebuild, rescue, snapshot, console access, and delete. These operations have different effects:

• Stop: Powers off the virtual machine while preserving its definition.
• Start: Powers on a stopped instance.
• Reboot: Restarts the guest, with hard or soft variants where exposed.
• Pause or suspend: Temporarily changes execution state; the exact behavior depends on the hypervisor and operation.
• Resize: Changes the flavor and therefore the allocated compute capacity, subject to quota and host capacity.
• Rebuild: Replaces the instance's boot contents using a selected image; review data-loss implications first.
• Rescue: Boots through a recovery workflow when enabled and appropriate for troubleshooting.
• Snapshot: Creates a point-in-time image-like copy through the supported workflow.
• Console: Opens graphical or serial access when configured, useful when network access is unavailable.
• Delete: Removes the instance. Confirm what attached or dependent resources will remain.

Images and flavors

An image is a bootable operating system or application template. Common image properties include name, status, visibility, format, minimum disk, minimum RAM, architecture, and protected or shared status. Visibility may be private to a project, shared with selected projects, or public according to cloud policy.

A flavor is a predefined compute sizing profile. It commonly specifies virtual CPUs, memory, root disk size, ephemeral disk, and swap. A small flavor may be suitable for testing, while a larger flavor may be required for a production workload. The image's minimum requirements and the project's quota must both be satisfied.

Image upload, image publication, flavor creation, and flavor modification are often restricted to administrators. A project user may be able to select approved images and flavors without being allowed to manage them.

Networking in Horizon

OpenStack networking is built from related objects:

• Network: A virtual Layer 2 network available to a project.
• Subnet: An IP address range and configuration inside a network.
• Port: A virtual network interface with an address, status, and security-group configuration.
• Router: A virtual routing service connecting networks and possibly an external gateway.
• Floating IP: An externally routable address associated with a project resource, commonly an instance port.
• Security group: A set of virtual firewall rules applied to instance network ports.

An instance must be attached to a network through a port. A private network can connect instances within the project. A router interface connects a private subnet to the router, and an external gateway connects the router to an external network. A floating IP can then provide a reachable address if the deployment's routing and security rules allow it.

Network creation, router management, external gateways, port settings, and topology views depend on Neutron policy and deployment configuration. Do not assume that a project can create or modify every network object.

Security group rules

Rules normally specify direction, protocol, port or port range, and a remote CIDR or another security group. For example, an inbound SSH rule might allow TCP port 22 only from a trusted administrative CIDR. Add HTTP or HTTPS rules only when the workload requires them. Avoid opening administrative ports to all addresses unless there is a documented reason.

Storage management

A volume is persistent block storage that can be attached to an instance. Horizon may also expose volume types, snapshots, backups, transfers, and attachment details.

1. Create a volume with the required size and volume type.
2. Wait until its status is AVAILABLE.
3. Attach it to the selected instance.
4. Verify the attachment in Horizon and then configure the device inside the guest operating system.
5. When finished, unmount the filesystem in the guest before detaching the volume.
6. Delete the volume only after confirming that its data is no longer needed.

Extending a volume may be supported by the backend and policy. Increasing the block device size does not automatically expand a partition or filesystem inside the guest. A snapshot is a point-in-time copy of a volume or, in some workflows, an instance image. Backups are managed copies intended for recovery and may have separate lifecycle and retention rules.

When Swift is enabled, the Object Storage panel may provide containers and objects. Containers organize objects, while objects contain data and metadata. Swift access and sharing behavior are governed by deployment policy.

Identity, projects, and access

Identity management describes who can access OpenStack and what they can do:

• User: An identity that can authenticate.
• Group: A collection of users that simplifies assignment management.
• Project: A resource and authorization boundary.
• Domain: A grouping for identity objects such as users, groups, and projects.
• Role: A permission assignment controlling actions within a scope.
• Role assignment: The association of a role with a user or group in a project, domain, or other supported scope.

Project membership and roles determine which resources a user can see and which operations are permitted. A user may belong to several projects and must select the intended project at login or through the project selector. User, project, group, and role management should be performed only by appropriately authorized administrators.

Administrative dashboard functions

Authorized administrators may see panels for instances, hosts, hypervisors, images, flavors, networks, volumes, users, projects, quotas, and service health. These views help identify capacity, placement, failures, policy issues, and cloud-wide resource usage.

Administrative scope is different from project scope. An administrator viewing all instances is not the same as a project member viewing instances in one selected project. Quota adjustment, flavor administration, image publication, user management, and service operations may require separate policies even for an administrator role.

Practical workflows

Launch a Linux web server

1. Select the intended project and region.
2. Choose an approved Linux image and an appropriately sized flavor.
3. Select a private project network.
4. Create or select a security group allowing SSH and HTTP or HTTPS only as required.
5. Prefer a trusted source CIDR for SSH rather than allowing all addresses.
6. Select a key pair that is available to the project and keep the private key secure.
7. Launch the instance and wait for its active state.
8. Verify its port and addresses. Associate a floating IP if external connectivity is required and the project is permitted to use one.

Attach persistent storage

1. Create a volume with the required size and volume type.
2. Wait for the volume to become available.
3. Attach it to the chosen instance.
4. Verify the attachment in Horizon.
5. Inside the guest operating system, identify the device, partition and format it if appropriate, and mount it. Horizon performs the cloud-side attachment; it does not automatically configure the guest filesystem.

Allow secure remote administration

1. Create or select a security group.
2. Add a narrowly scoped inbound SSH rule with direction, TCP protocol, port 22, and a trusted remote CIDR.
3. Apply the security group to the instance port.
4. Check that the instance has a reachable address and that the guest SSH service and firewall are configured.
5. Test connectivity without widening the rule unnecessarily.

Prepare a project for a team member

1. Create or identify the user and project within the appropriate domain.
2. Assign the least-privileged suitable project role.
3. Have the user sign in and confirm the expected project is selected.
4. Verify that the user sees only the expected resources and actions.

Safe operations and dependency awareness

Before an operation, review the selected project, region, resource name, and dependencies. Read destructive-action confirmations instead of accepting them automatically. Check status and task progress before issuing another operation; repeated requests can create conflicting operations or hide the original failure.

Deletion order matters. Detach volumes before deleting them, remove router interfaces before deleting a router or subnet where required, and release floating IPs when they are no longer needed. Delete instances before dependent ports or volumes when policy or resource state requires it. Confirm whether snapshots, backups, images, or volumes should be retained before deleting their source resource.

Troubleshooting Horizon operations

A panel or action is missing

Confirm the selected project and region, then check role assignments, enabled services, Horizon panel configuration, policy rules, and service availability. The resource may be outside the current scope.

An instance cannot be launched

Review the launch form, quotas, and status of the selected image, flavor, network, key pair, security group, and availability zone. Common causes include exhausted vCPU or RAM quota, unavailable capacity, a missing required selection, or insufficient permission. Read any task or error message shown by Horizon.

An instance is running but unreachable

Check whether it has a floating IP for external access, whether its port has the correct security groups, and whether a router interface and external gateway provide a path from the private network. Also check the guest operating system's firewall, route table, and service configuration.

A volume cannot be deleted

Inspect its status and attachments. Detach it safely first, and check for snapshots, backups, transfers, migrations, or other operations in progress. A policy restriction may also prevent deletion.

A resource is not where expected

Verify the project and region first. Then clear filters, check pagination, and inspect resource details. A resource created in another scope will not appear in the current table.

Login fails or sessions repeatedly expire

Recheck credentials, domain, project, and region. Retry after signing in again. If the problem persists, investigate browser cookies and escalate possible identity-service, federation, clock, or deployment issues to the cloud administrator.

Exam-relevant notes

• Horizon is a web interface; OpenStack services and APIs perform the underlying work.
• A project is both a resource boundary and an important authorization scope.
• Images provide boot sources, flavors define compute sizing, networks provide connectivity, security groups filter traffic, key pairs support SSH, and floating IPs provide external addressing when configured.
• A subnet belongs to a network, a port connects an instance to a network, and a router connects networks.
• Persistent volumes are separate block-storage resources; ephemeral disks generally follow the instance lifecycle.
• RBAC and deployment policy control visible panels and allowed actions.
• Quota exhaustion can prevent creation even when a form is filled correctly.
• Always verify project, region, resource status, dependencies, and destructive-action confirmations before changing or deleting resources.

For the dashboard entry point configured by your cloud operator, use OpenStack Horizon Dashboard.