Red Hat Training

A Red Hat training course is available for Red Hat CloudForms

Chapter 2. Planning

This guide provides some general guidelines to planning a deployment on Red Hat CloudForms. This includes creating multiple regions containing Red Hat CloudForms appliances, CPU sizing recommendations, database sizing recommendations, and database configuration.

2.1. Regions

Regions are used for centralizing data which is collected from public and private virtualization environments. A region is ultimately represented as a single database for the VMDB. Regions are particularly useful when multiple geographical locations need to be managed, as they enable all the data collection to happen at each particular location and avoid data collection traffic across slow links between networks.

When multiple regions are being used, each with their own unique ID, a master region can be created to centralize the data of all the children regions into a single master database. To do this, configure each child region to replicate its data to the master region database (Red Hat recommends use of region 99, though any number up to three digits will work). This parent and child region is a one-to-many relationship.

Regions can contain multiple zones, which in turn contain appliances. Zones are used for further segregating network traffic along with enabling failover configurations. Each appliance has the capability to be configured for a number of specialized server roles. These roles are limited to the zone containing the appliance they run on.

Only one failover type of each server role can run in a zone. If multiple appliances have the same failover role, the extras are used as backups that activate only if the primary appliance fails. Non-failover server roles can run on multiple appliances simultaneously in a zone, so resources can be adjusted according to the workload those roles are responsible for.

The following diagram demonstrates an example of the multiple regions working together in a Red Hat CloudForms environment.


The master appliance is located in Chicago and contains a master region and a subregion that manages the worker appliances. The Mahwah technology center contains a single subregion that manages two zones. Likewise, the San Diego technology center contains a single subregion managing a single zone.

  • Replicating a parent region to a higher-level parent is not supported.
  • Parent regions can be configured after the child regions are online.

The following diagram provides a closer look at a region:


In this region, we have several Red Hat CloudForms appliances acting as UI nodes and worker nodes. These worker nodes execute tasks on the providers in your environment. The region also uses a region database that reports to a master database on the main Red Hat CloudForms appliance. All appliances can connect to the authentication services (Active Directory, LDAP, Identity Management), outgoing mail (SMTP), and network services (SNMP).


CloudForms can be configured in a highly available setup. In this case, all PostgreSQL instances must be running on a server that is deployed from the CloudForms appliance. High availability is achieved by database replication between two or more database servers. For more information, see the High Availability Guide.

2.2. Roles

Server roles define what a server can do. Assigning different server roles to appliances can allow them to focus on specific functions. When planning a deployment, consider which roles to assign to each appliance. Some server roles are enabled by default in CloudForms. Many server roles start worker processes.

Some roles are also dependent on other roles. For example, because the CloudForms user interface relies on the API for access, the Web Services role must be enabled with the User Interface role for users to log in to the appliance. See Server Roles in General Configuration for details on each server role and its function.

2.2.1. Appliance Types

Depending on the needs of your environment, you may choose to separate worker and database tasks between appliances. One example of this is to implement a highly available configuration so that certain appliances are running the PostgreSQL database and providing failover. For more details about configuring high availability, see the High Availability Guide.

The following provides a summary of types of appliances:

Table 2.1. Appliance types

Appliance TypeDatabaseWorkersDescription

VMDB appliance



Worker processes are running, and it also hosts its own database that other appliances can connect to.

Non-database appliance



Worker processes are running on the appliance, but it does not host a database. The appliance is connected to an external database.

Dedicated-database appliance



This appliance contains no worker processes, only a database for other appliances to connect to.

Non-CloudForms VM with database



This appliance contains no worker processes, only a database. As this is not a CloudForms appliance, you cannot run any CloudForms rake tasks on it. This appliance must be migrated using a non-database appliance that is pointed at it, using it as a database.

2.3. Centralized Administration

Red Hat CloudForms includes centralized administration capabilities, where certain operations can be initiated from the global region and processed and executed on remote regions.

The following life cycle management operations can be initiated from the global region using centralized administration:

  • Virtual machine provisioning
  • Virtual machine power operations
  • Virtual machine retirement
  • Virtual machine reconfiguration
  • Service provisioning
  • Service retirement

From the global region, you can also access the user interfaces of virtual machines residing in remote regions.


CloudForms life cycle operations other than those listed above are not supported. Centralized administration capabilities are not supported from the Self Service user interface.

With centralized administration, the remote_queue_put leverages a new system-to-system REST API request to forward the original request to the remote region. This request is put in the local queue in the remote region, which is then delivered by a worker in the remote region as if it was queued there all along. As a result, a CloudForms operator in the global region can be seen as provisioning on behalf of a remote region.

Centralized Administration Diagram


The operations initiated from the global region are subject to the role-based access control (RBAC) rules on the remote region. The user in the remote region which matches the logged-in user’s user ID will be used to enforce RBAC in the target region. The operation will fail on the remote system if the user does not have the required permissions.

In CloudForms 4.5 and above, configuring database replication automatically enables centralized administration, eliminating the need for further configuration. To configure database replication, see Configuring Database Replication and Centralized Administration in the General Configuration guide.

2.4. Tenancy

Red Hat CloudForms supports multitenancy. Tenants can be totally separate or they can be in a parent-child or peer relationship. Tenants in a relationship can share or inherit a certain configuration. You can subdivide and create child tenants and they, in turn, can have child tenants, and so on. The ability to have multi-level (nested) tenants in a hierarchy enables those at the bottom to inherit permissions from those above. This configuration allows for granular user permissions to be set on specific tenants.

A tenant can also contain a self-contained child tenant known as a project. A project cannot have a child tenant, but is useful for allocating resources to a small group or team within a larger organization.


If you do not add any additional tenants, all resources and user accounts are contained in a single base tenant which is your CloudForms appliance itself. In CloudForms, is sometimes referred as tenant zero.

Tenancy Account Roles

In CloudForms, the following two account roles are associated with tenancy:

  • Tenant administrator
  • Tenant quota administrator

See Account Roles and Descriptions in the General Configuration guide for more information about these roles.


Tenant administrator and tenant quota administrator roles are like administrator and super administrator. These roles are not limited to the tenant upon which they are acting and act across all tenants, and therefore should be considered privileged users. These are not roles inside a tenant.

Tenancy Models

The following two approaches exist for tenancy planning:

  • Tenantless - You can create a single large tenant, sometimes referred as tenant zero, and perform all your operations in there without any subdivision of resources or user accounts.
  • Enterprise model - A common scenario is to create a single tenant, and then subdivide it based on the structures or departments within your organization. Those departments are then able to further subdivide their resources into distinct projects. With this model, you have a single URL for user access, while still having the ability to divide resources into nested hierarchical tenants.

Tenancy Configuration

You can create and configure tenancy using the CloudForms user interface in the same place you set up users, groups and roles by selecting Configuration from the settings menu, and then clicking on the Access Control accordion. See the section on Access Control in the General Configuration guide for procedures on how to create tenants and projects, users, and groups.

Tenancy in Automation

One of the features of tenancy is that each tenant can have its own automate domain. Tenant-based domains can help in several use cases, such as if you have:

  • groups that need their own naming routines
  • varying types of approval needs
  • departments that use different end ticketing systems
  • a customer who is a holding company or centralized IT organization for managing different business units

Just like standard domains are nested, you can also add automate domains that are nested at the tenant level. For the procedure on how to create a new automate domain, see Scripting Actions in CloudForms.

Tenancy Quota and Reporting

You can allocate and enforce quotas for the following attributes:

  • Virtual CPUs
  • Memory in GB
  • Storage in GB
  • Number of virtual machines
  • Number of templates

See the section on Managing Tenant and Project Quotas in the General Configuration guide for procedures on how to create and manage quotas.

You can generate or schedule a report for Tenant Quotas similar to other reports. See Reports in the Monitoring, Alerts, and Reporting guide for procedures on how to view or schedule a report.


Currently, in tenant quota reports you will see all of the tenants but there is no nesting information available by parent and child tenants.


In the following example of a tenant quota report, DevOps Teams is a parent tenant and Team Alpha and Team Bravo are child tenants.

tenant quotas report

  • Total Quota: Total quota enforced per attribute for a tenant
  • In Use: Amount of quota currently in use by tenants
  • Allocated: Amount of quota given to all child tenants
  • Available: Total Quota minus (-) In Use minus (-) Allocated

Tenancy Chargeback

You have the ability to do tenancy in chargeback where you are able to assign rates and have a different rate for each tenant. You can make use of the default rate or create your own set of rates depending on the tenant. As well, there is an ability to create chargeback reports by tenant.

See Chargeback in the Monitoring Alerts, and Reporting guide for information on how to create and assign default or custom chargeback rates, and how CloudForms calculates chargeback costs.

Tenancy Service Catalogs

Similar to automate domains, you can have service catalogs at each level of tenancy. Once you add a service catalog at a particular level of tenancy, it is visible to that tenant and its children (unless you use tagging to exclude).

Tenancy Providers

Providers can be added at any level of tenancy. Once added, a provider is visible to any child or lower tenants, making it possible to easily separate resources that are owned or accessed by one group, and should not be available to other tenants.

2.5. Using a Load Balancer

Deploying multiple user interface worker appliances and placing them behind a third-party load balancer allows for redundancy and improved performance. This requires extra configuration in both the load balancer and in the CloudForms user interface worker appliances.

2.5.1. Configuring the Load Balancer

  • Configure the load balancer to use sticky sessions. This ensures that when a session is started, all requests for that session are sent to the same worker appliance.
  • Configure the load balancer to test for connectivity using the CloudForms ping response page: https://appliance_name/ping. The expected reply from the appliance is the text string pong. Using this URL is preferable to the appliance login URL as it does not establish a connection to the database.

2.5.2. Configuring Worker Appliances for Load Balancing

When using a load balancer, configure appliances that have the User Interface role enabled to store session data in the database. As a result, the user does not need to re-login if the load balancer redirects them to an alternative server in the case the original user interface worker is unresponsive.

On each appliance, configure the session data storage location using the session_store parameter within the advanced settings page in the CloudForms user interface:

  1. From the settings menu, select Configuration.
  2. Click the Advanced tab.
  3. Change the session_store parameter to sql in the following line (the default parameter is cache):

     :session_store: sql
  4. Click Save.

Configure the session_store parameter to point to sql on each user interface appliance behind the load balancer.

See Advanced Settings in General Configuration for more information on editing configuration files from the appliance user interface.

Also see Load Balancers in the Deploying CloudForms at Scale reference architecture for further information.

For information on configuring database failover in VMDB appliances, see the High Availability Guide.

2.6. Database Configuration

This section describes the Red Hat CloudForms PostgreSQL database configuration. The below table provides information on each file: its location, primary function, and notes regarding behavior or recommendations.

Table 2.2. Database files



Data Directory

Default server configuration

Adds directive to include /etc/manageiq/postgresql.conf.d directory

Data Directory

Contains configuration set by the ALTER SYSTEM command

Do not edit manually



Contains CloudForms default overrides

Overwritten on upgrades

<other files>


Contains user overrides

Takes precedence if alphabetically after 01_miq_overrides.conf

2.6.1. User Overrides

Store custom configurations, or user overrides, in /etc/manageiq/postgresql.conf.d. Name the user override file so that it follows 01_miq_overrides.conf alphabetically. This ensures custom configurations are not overwritten on CloudForms upgrades.

The following file name example follows 01_miq_overrides.conf alphabetically in the /etc/manageiq/postgresql.conf.d directory:



2.6.2. Reading Configuration Settings

Query the CloudForms PostgreSQL database directly to read configuration settings. See the PostgreSQL Documentation for more information.

The following example queries the CloudForms for current value set for max_wal_senders:


`psql -d vmdb_production -c 'show max_wal_senders'