After completing this section, you should be able to define the resources that control the function, size, and capacity of a running instance.

A domain operator understands the relationship between an image and a flavor, including properly setting minimum sizing constraints, and the use cases for specifying the choice of raw versus QCOW, and how Ceph influences that choice. They can advise cloud users about methods and considerations for deploying instances using images as boot volumes, and can demonstrate correct instance sizing and disk configuration for a given application use case. They can advise why there are fixed flavor configurations for specific application use cases, as opposed to arbitrary sizing for each application when deployed.

In Red Hat OpenStack Platform, an image is a file containing a virtual disk installed with a bootable operating system. Images are managed by the Image Service (Glance). An image is one of the fundamental requirements for deploying instances.

Red Hat provides a guest image preconfigured with cloud-init. Cloud-init performs instance customization such as injecting SSH keys, and requires access to an EC2-compatible metadata service.

Any user can upload images. The following image formats are currently supported on Red Hat OpenStack Platform 16:

You can upload and use any image format when the instance is deployed on an appropriate platform, such as using an AMI image on OpenStack deployed on the Amazon public cloud. Red Hat only supports RAW, QCOW2, and VMDK when running on an RHOSP private cloud, because the only supported hypervisor technology is KVM/QEMU, even on IBM Power and Z series.

When Ceph is not used, administrators can use the glance command (not the openstack command) to import images, which allows the format to be converted during the import. This is designed to convert to Red Hat-supported formats only, not in any other direction.

With Ceph as the Image service storage back end, image conversion is automatically enabled. Because the Image service is configured to use Ceph RADOS Block Devices (RBD), and the Ceph RBD image store expects raw images, the image files are converted to raw format when they are first loaded using the openstack image create command.

Images are managed using either the OpenStack Dashboard or the openstack CLI command. Use the openstack image command to manage images. The OpenStack Dashboard image management tasks are found under Project → Compute → Images.

Each instance requires an image to create its virtual disk. An image contains the minimum required software, including a bootable OS. The image is stored in the Ceph images pool, and is served by the Image service, which manages the catalog of images. Depending on configurable attributes, images are available to some or all users, to create and deploy new instances in the Red Hat OpenStack Platform environment.

...output omitted...
    <disk type='network' device='disk'>
      <driver name='qemu' type='raw' cache='writeback' discard='unmap'/>
      <auth username='openstack'>
        <secret type='ceph' uuid='63e5c992-81fb-11ea-bc11-52540001fac8'/>
      </auth>
      <source protocol='rbd' name='vms/4b6bd953-2e8d-4734-821e-32653a476e9b_disk'>
        <host name='172.24.3.1' port='6789'/>
      </source>
      <target dev='vda' bus='virtio'/>
      <alias name='virtio-disk0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </disk>
...output omitted...

Each image has metadata associated with it. These attributes can be used by other OpenStack services to verify the image requirements and settings.

Image visibility is a commonly used setting. By default, during an image's creation, its visibility is set to shared, meaning that the owner and other users within the same project can access the image. Other image visibility settings include private, community, and public. Private visibility limits image access to the owner and public visibility allows access to all users. Community visibility allows all users access to the image but only lists the image in the default image list of certain users. An image can be configured as protected so it cannot be removed unintentionally. You must first set the image to be unprotected before you can remove it.

The libosinfo database provides a generic way to match virtual guest supported hardware to the virtual hardware provided by a hypervisor. This allows virtual guests to be configured with the optimal virtual hardware for your environment.

The Image service can utilize libosinfo data to configure the virtual hardware for an image. Set the os_name property for an image to a valid libosinfo value to enable this behavior. As an example, for a Windows Server 2019 image, set the os_name property to win2k19.

You can install the libosinfo package, then use the osinfo-query os command to view the valid OS names. You can find links to more information on libosinfo in the references section.

Manage images from either the command line or the Dashboard.

[user@demo ~]$ source user-project-rc

[user@demo ~(user)]$ openstack image create \
> --min-disk 10 --min-ram 256 \
> --file ~/downloads/rhel8.qcow2 rhel8-custom1

[user@demo ~(admin)]$ openstack image create \
> --file ~/downloads/rhel8.qcow2 --public rhel8-base

[user@demo ~(admin)]$ openstack image create \
> --min-disk 10 --min-ram 512 \
> --file ~/downloads/rhel8.qcow2 --project project --private rhel8-custom2

[user@demo ~(admin)]$ openstack image set \
> --min-disk 10 --min-ram 256 rhel8-base

Flavors are hardware specification profiles for deploying instances. These specifications include the disk and memory size and the number of cores to be used for each instance deployed. Flavors can also specify sizes for additional ephemeral storage or a swap disk, plus metadata to restrict usage or to provide special project access.

You must specify a flavor to deploy an instance. The Compute service schedules the deployment by checking the compute nodes for sufficient available resources, as requested by the flavor. If no host (compute node) can be found with sufficient resources, the instance deployment fails. Any compute node with sufficient resources and an acceptable current load can be selected for this deployment. The scheduling algorithms in the Compute service define all the criteria used to prioritize compute nodes for the selected deployment.

Flavors are managed with the Dashboard or with the OpenStack CLI. Use the openstack flavor command to manage flavors. The OpenStack Dashboard flavor management tasks are found under Admin → System → Flavors. Creating and managing flavors is restricted to users assigned with the admin role to the admin project in the Default domain.

Flavors can be customized so that hardware requirements meet user needs. In addition to system disk and memory size, and the number of VCPUs, other parameters can be defined, such as adding a swap disk or additional ephemeral disk.

Creating new flavors is restricted to users with an admin role, because the flavor creation process must interface with host-level (libvirt) configuration and attributes to determine appropriate settings, extra-specs, and compute-node limitations. Only a user with the system-scope admin role can manage host-based attributes.

Furthermore, only site-wide administrators know how to balance the competing requirements of multiple customer applications, resource conservation, and high performance. Deciding flavor sizing must take into account the application adoption rates, workload demand types and load variance, expected overcommit use, quality of service constraints, number of tenants and related transactions. It must also take in account the segregation methods such as host aggregates, availability zones, and regions, and the number of physical systems that will spread the total workloads. However, this topic is covered in later courses in the Red Hat OpenStack Platform learning path.

Flavors can be restricted for the exclusive requirements and use of a specific project by creating the flavor as private. For example, flavors with large resource parameters could be restricted to only projects requiring large sizes. If a flavor with 256 GB of memory was made public, all projects have access to that flavor, and misuse of that flavor could quickly consume the cloud environment's resource capacity.

Flavors define the virtual storage to be made available to an instance. There can be several storage resources associated with an instance, including the root disk, an ephemeral disk, and a swap disk. Ephemeral devices are created and stored in the Ceph pool named vms, and are deleted when the instance is deleted. The type of back-end storage does not determine whether a device is ephemeral, but only whether the device is always discarded when the instance is deleted.

An instance uses both an image as the template for its virtual system disk, and a flavor that defines the hardware resources used to deploy that instance. If an image includes minimum requirements for disk and memory size, those requirements must be met by the flavor settings, otherwise the deployment request is rejected. If an image does not include minimum requirement settings, you can deploy it using almost any flavor, but if the flavor sizing is insufficient for the image to successfully boot, the deployment fails.

To avoid issues with instance deployment, images should always be set with correct minimum sizes for proper operation. Similarly, the flavor used must specify disk and memory sizes that are equal to or larger than specified by the image. If minimum requirements are not matched by the flavor, the CLI issues an error message. In the Dashboard, while deploying an instance using the wizard, flavors that do not meet the disk and memory requirements for the selected imaged are disabled. If no flavors qualify to deploy this image, an error message is displayed.

Red Hat OpenStack Platform administrators customize flavors for specific environments and use cases. For example, in an environment with suboptimal networking, flavors can implement instance bandwidth restrictions. When systems are limited to a maximum number of sockets, flavors can configure limits and preferences for sockets, cores, and threads. You can set disk quotas to limit the maximum write rate per second for a user. Flavor customizations are implemented by the extra_specs element.

[user@demo ~(admin)]$ openstack flavor set m2.small \
> --property quota:disk_write_bytes_sec=10485760

[user@demo ~(admin)]$ openstack flavor set m2.small \
> --property quota:disk_read_bytes_sec=10485760

[user@demo ~(admin)]$ openstack flavor show -c name -c properties -f json m2.small
{
  "name": "m2.small",
  "properties": "quota:disk_read_bytes_sec='10485760', quota:disk_write_bytes_sec='10485760'"
}

[user@demo ~(user)]$ openstack flavor create \
> --ram 4096 --disk 20 --vcpus 2 example-flavor

[user@demo ~(user)]$ openstack flavor show example-flavor
...output omitted...

[user@demo ~(user)]$ openstack flavor delete example-flavor

Cloud images are commonly accessed using SSH keys, which can be injected into the instance during deployment. Password-based access is vulnerable to brute-force password attacks, especially on public-facing instances. If you do require password-based access for a cloud instance, several methods are available.

Configure the passwords for root and any other users by passing a user-data file to be processed by cloud-init. When setting passwords for users other than the default cloud-user account, you must remove the password: directive and replace it with the chpasswd: directive as follows:

#cloud-config
...output omitted...
chpasswd:
  list: |
     root:redhat
     cloud-user:super_secret_password
  expire: False

All users who require that passwords be set must be included in this chpasswd section.

Passwords can also be configured by editing an image before uploading it to the Image service, however this method is not a good practice as it could result in unauthorized access if the password becomes common knowledge.

Privately deployed instances (such as the lower tiers of multitier applications) are launched without public access, meaning that they cannot be accessed using the SSH key method. These instances can only be accessed using the VNC console. In this scenario, an account and password is required to access and log in to the instance. This scenario and prerelease application development scenarios are the use case for this password-setting method.