Chapter 1. The Image service (glance)
Manage images and storage in Red Hat OpenStack Platform (RHOSP).
A virtual machine image is a file that contains a virtual disk with a bootable operating system installed. Virtual machine images are supported in different formats. The following formats are available in RHOSP:
-
RAW
- Unstructured disk image format. -
QCOW2
- Disk format supported by QEMU emulator. This format includes QCOW2v3 (sometimes referred to as QCOW3), which requires QEMU 1.1 or higher. -
ISO
- Sector-by-sector copy of the data on a disk, stored in a binary file. -
AKI
- Indicates an Amazon Kernel Image. -
AMI
- Indicates an Amazon Machine Image. -
ARI
- Indicates an Amazon RAMDisk Image. -
VDI
- Disk format supported by VirtualBox virtual machine monitor and the QEMU emulator. -
VHD
- Common disk format used by virtual machine monitors from VMware, VirtualBox, and others. -
PLOOP
- A disk format supported and used by Virtuozzo to run OS containers. -
OVA
- Indicates that what is stored in the Image service (glance) is an OVA tar archive file. -
DOCKER
- Indicates that what is stored in the Image service (glance) is a Docker tar archive of the container file system.
Although ISO
is not normally considered a virtual machine image format, because ISOs contain bootable file systems with an installed operating system, you use them in the same way as other virtual machine image files.
To download the official Red Hat Enterprise Linux cloud images, your account must have a valid Red Hat Enterprise Linux subscription:
If you are not logged in to the Customer Portal, a prompt opens where you must enter your Red Hat account credentials.
1.1. Understanding the Image service
Red Hat OpenStack Platform (RHOSP) Image service (glance) features.
1.1.1. Supported Image service back ends
The following Image service (glance) back-end scenarios are supported:
- RBD is the default back end when you use Ceph. For more information, see Configuring Ceph Storage in the Advanced Overcloud Customization guide.
- RBD multi-store. For more information, see Section 2.1, “Requirements of storage edge architecture”.
Object Storage (swift). For more information, see Using an external Object Storage cluster in the Advanced Overcloud Customization guide.
The Image service uses the Object Storage type and back end as the default.
- Block Storage (cinder). For more information, see Configuring cinder back end for the Image service in the Advanced Overcloud Customization guide.
NFS. For more information, see Configuring NFS storage in the Advanced Overcloud Customization guide.
- Important
Although NFS is a supported Image service deployment option, more robust options are available.
NFS is not native to the Image service. When you mount an NFS share on the Image service, the Image service does not manage the operation. The Image service writes data to the file system but is unaware that the back end is an NFS share.
In this type of deployment, the Image service cannot retry a request if the share fails. This means that when a failure occurs on the back end, the store might enter read-only mode, or it might continue to write data to the local file system, in which case you risk data loss. To recover from this situation, you must ensure that the share is mounted and in sync, and then restart the Image service. For these reasons, Red Hat does not recommend NFS as an Image service back end.
However, if you do choose to use NFS as an Image service back end, some of the following best practices can help to mitigate risks:
- Use a reliable production-grade NFS back end.
- Ensure that you have a strong and reliable connection between Controller nodes and the NFS back end: Layer 2 (L2) network connectivity is recommended.
- Include monitoring and alerts for the mounted share.
- Set underlying file system permissions. Write permissions must be present in the shared file system that you use as a store.
- Ensure that the user and the group that the glance-api process runs on do not have write permissions on the mount point at the local file system. This means that the process can detect possible mount failure and put the store into read-only mode during a write attempt.
1.1.2. Image signing and verification
Image signing and verification protects image integrity and authenticity by enabling deployers to sign images and save the signatures and public key certificates as image properties.
By taking advantage of this feature, you can do these tasks:
- Sign an image using your private key and upload the image, the signature, and a reference to your public key certificate (the verification metadata). The Image service then verifies that the signature is valid.
- Create an image in the Compute service, have the Compute service sign the image, and upload the image and its verification metadata. The Image service again verifies that the signature is valid.
- Request a signed image in the Compute service. The Image service provides the image and its verification metadata, allowing the Compute service to validate the image before booting it.
For information on image signing and verification, see Validating Image Service (glance) images in the Manage Secrets with OpenStack Key Manager guide.
1.1.3. Image conversion
Image conversion converts images by calling the task API while importing an image.
As part of the import workflow, a plugin provides the image conversion. This plugin can be activated or deactivated based on the deployer configuration. Therefore, the deployer needs to specify the preferred format of images for the deployment.
Internally, the Image service receives the bits of the image in a particular format. These bits are stored in a temporary location. The plugin is then triggered to convert the image to the target format and moved to a final destination. When the task is finished, the temporary location is deleted. As a result, the format uploaded initially is not retained by the Image service.
For more information about image conversion, see Section 1.2.8, “Enabling image conversion”
The conversion can be triggered only when importing an image. It does not run when uploading an image. For example:
$ glance image-create-via-import \ --disk-format qcow2 \ --container-format bare \ --name NAME \ --visibility public \ --import-method web-download \ --uri http://server/image.qcow2
1.1.4. Interoperable image import
The interoperable image import workflow enables you to import images in two ways:
-
Use the
web-download
(default) method to import images from a URI. -
Use the
glance-direct
method to import images from a local file system.
1.1.5. Improving scalability with Image service caching
Use the glance-api caching mechanism to store copies of images on Image service (glance) API servers and retrieve them automatically to improve scalability. With Image service caching, glance-api can run on multiple hosts. This means that it does not need to retrieve the same image from back end storage multiple times. Image service caching does not affect any Image service operations.
Configure Image service caching with the Red Hat OpenStack Platform director (tripleo) heat templates:
Procedure
In an environment file, set the value of the
GlanceCacheEnabled
parameter totrue
, which automatically sets theflavor
value tokeystone+cachemanagement
in theglance-api.conf
heat template:parameter_defaults: GlanceCacheEnabled: true
-
Include the environment file in the
openstack overcloud deploy
command when you redeploy the overcloud. Optional: Tune the
glance_cache_pruner
to an alternative frequency when you redeploy the overcloud. The following example shows a frequency of 5 minutes:parameter_defaults: ControllerExtraConfig: glance::cache::pruner::minute: '*/5'
Adjust the frequency according to your needs to avoid file system full scenarios. Include the following elements when you choose an alternative frequency:
- The size of the files that you want to cache in your environment.
- The amount of available file system space.
- The frequency at which the environment caches images.
1.1.6. Image pre-caching
Red Hat OpenStack Platform (RHOSP) director can pre-cache images as part of the glance-api
service.
1.1.6.1. Configuring the default interval for periodic image pre-caching
The default periodic interval for image pre-caching is 300 seconds. You can increase or decrease the default interval based on your requirements.
Procedure
Add a new interval with the
ExtraConfig
parameter in an environment file on the undercloud according to your requirements:parameter_defaults: ControllerExtraConfig: glance::config::glance_api_config: DEFAULT/cache_prefetcher_interval: value: '<300>'
Replace <300> with the number of seconds that you want as an interval to pre-cache images.
After you adjust the interval in the environment file in
/home/stack/templates/
, log in as thestack
user and deploy the configuration:$ openstack overcloud deploy --templates \ -e /home/stack/templates/<env_file>.yaml
Replace <env_file> with the name of the environment file that contains the
ExtraConfig
settings that you added.ImportantIf you passed any extra environment files when you created the overcloud, pass them again here by using the
-e
option to avoid making undesired changes to the overcloud.
For more information about the openstack overcloud deploy
command, see Deployment command in the Director Installation and Usage guide.
1.1.6.2. Using a periodic job to pre-cache an image
Prerequisites
To use a periodic job to pre-cache an image, you must use the glance-cache-manage
command connected directly to the node where the glance_api
service is running. Do not use a proxy, which hides the node that answers a service request. Because the undercloud might not have access to the network where the glance_api
service is running, run commands on the first overcloud node, which is called controller-0
by default.
Complete the following prerequisite procedure to ensure that you run commands from the correct host, have the necessary credentials, and are also running the glance-cache-manage
commands from inside the glance-api
container.
Procedure
Log in to the undercloud as the stack user and identify the provisioning IP address of
controller-0
:(undercloud) [stack@site-undercloud-0 ~]$ openstack server list -f value -c Name -c Networks | grep controller overcloud-controller-1 ctlplane=192.168.24.40 overcloud-controller-2 ctlplane=192.168.24.13 overcloud-controller-0 ctlplane=192.168.24.71 (undercloud) [stack@site-undercloud-0 ~]$
To authenticate to the overcloud, copy the credentials that are stored in
/home/stack/overcloudrc
, by default, tocontroller-0
:$ scp ~/overcloudrc heat-admin@192.168.24.71:/home/heat-admin/
Connect to
controller-0
:$ ssh heat-admin@192.168.24.71
On
controller-0
as theheat-admin
user, identify the IP address of theglance_api service
. In the following example, the IP address is172.25.1.105
:(overcloud) [root@controller-0 ~]# grep -A 10 '^listen glance_api' /var/lib/config-data/puppet-generated/haproxy/etc/haproxy/haproxy.cfg listen glance_api server central-controller0-0.internalapi.redhat.local 172.25.1.105:9292 check fall 5 inter 2000 rise 2
Because the
glance-cache-manage
command is only available in theglance_api
container, create a script to exec into that container where the environment variables to authenticate to the overcloud are already set. Create a script calledglance_pod.sh
in/home/heat-admin
oncontroller-0
with the following contents:sudo podman exec -ti \ -e NOVA_VERSION=$NOVA_VERSION \ -e COMPUTE_API_VERSION=$COMPUTE_API_VERSION \ -e OS_USERNAME=$OS_USERNAME \ -e OS_PROJECT_NAME=$OS_PROJECT_NAME \ -e OS_USER_DOMAIN_NAME=$OS_USER_DOMAIN_NAME \ -e OS_PROJECT_DOMAIN_NAME=$OS_PROJECT_DOMAIN_NAME \ -e OS_NO_CACHE=$OS_NO_CACHE \ -e OS_CLOUDNAME=$OS_CLOUDNAME \ -e no_proxy=$no_proxy \ -e OS_AUTH_TYPE=$OS_AUTH_TYPE \ -e OS_PASSWORD=$OS_PASSWORD \ -e OS_AUTH_URL=$OS_AUTH_URL \ -e OS_IDENTITY_API_VERSION=$OS_IDENTITY_API_VERSION \ -e OS_COMPUTE_API_VERSION=$OS_COMPUTE_API_VERSION \ -e OS_IMAGE_API_VERSION=$OS_IMAGE_API_VERSION \ -e OS_VOLUME_API_VERSION=$OS_VOLUME_API_VERSION \ -e OS_REGION_NAME=$OS_REGION_NAME \ glance_api /bin/bash
Source the
overcloudrc
file and run theglance_pod.sh
script to exec into theglance_api
container with the necessary environment variables to authenticate to the overcloud Controller node.[heat-admin@controller-0 ~]$ source overcloudrc (overcloudrc) [heat-admin@central-controller-0 ~]$ bash glance_pod.sh ()[glance@controller-0 /]$
Use a command such as
glance image-list
to verify that the container can run authenticated commands against the overcloud.()[glance@controller-0 /]$ glance image-list +--------------------------------------+----------------------------------+ | ID | Name | +--------------------------------------+----------------------------------+ | ad2f8daf-56f3-4e10-b5dc-d28d3a81f659 | cirros-0.4.0-x86_64-disk.img | +--------------------------------------+----------------------------------+ ()[glance@controller-0 /]$
Procedure
As the admin user, queue an image to cache:
$ glance-cache-manage --host=<host_ip> queue-image <image_id>
-
Replace <host_ip> with the IP address of the Controller node where the
glance-api
container is running. Replace <image_id> with the ID of the image that you want to queue.
When you have queued the images that you want to pre-cache, the
cache_images
periodic job prefetches all queued images concurrently.NoteBecause the image cache is local to each node, if your Red Hat OpenStack Platform is deployed with HA (with 3, 5, or 7 Controllers) then you must specify the host address with the
--host
option when you run theglance-cache-manage
command.
-
Replace <host_ip> with the IP address of the Controller node where the
Run the following command to view the images in the image cache:
$ glance-cache-manage --host=<host_ip> list-cached
Replace <host_ip> with the IP address of the host in your environment.
Related information
You can use additional glance-cache-manage
commands for the following purposes:
-
list-cached
to list all images that are currently cached. -
list-queued
to list all images that are currently queued for caching. -
queue-image
to queue an image for caching. -
delete-cached-image
to purge an image from the cache. -
delete-all-cached-images
to remove all images from the cache. -
delete-queued-image
to delete an image from the cache queue. -
delete-all-queued-images
to delete all images from the cache queue.
1.1.7. Using the Image service API to enable sparse image upload
With the Image service (glance) API, you can use sparse image upload to reduce network traffic and save storage space. This feature is particularly useful in distributed compute node (DCN) environments. With a sparse image file, the Image service does not write null byte sequences. The Image service writes data with a given offset. Storage back ends interpret these offsets as null bytes that do not actually consume storage space.
Limitations
- Sparse image upload is supported only with Ceph RBD.
- Sparse image upload is not supported for file systems.
- Sparseness is not maintained during the transfer between the client and the Image service API. The image is sparsed at the Image service API level.
Prerequisites
- Your Red Hat OpenStack Platform (RHOSP) deployment uses RBD for the Image service back end.
Procedure
-
Log in to the undercloud node as the
stack
user. Source the
stackrc
credentials file:$ source stackrc
Create an environment file with the following content:
parameter_defaults: GlanceSparseUploadEnabled: true
Add your new environment file to the stack with your other environment files and deploy the overcloud:
$ openstack overcloud deploy \ --templates \ … -e <existing_overcloud_environment_files> \ -e <new_environment_file>.yaml \ …
For more information about uploading images, see Section 1.2.2, “Upload an image”.
Verification
You can import an image and check its size to verify sparse image upload.
Download the image file locally:
$ wget <file_location>/<file_name>
Replace
<file_location>
with the location of the file. Replace<file_name>
with the name of the file.The following procedure uses example commands. Replace the values with those from your environment where appropriate.
$ wget https://cloud.centos.org/centos/6/images/CentOS-6-x86_64-GenericCloud-1508.qcow2
Check the disk size and the virtual size of the image that you want to upload:
qemu-img info <file_name>
The following procedure uses example commands. Replace the values with those from your environment where appropriate.
$ qemu-img info CentOS-6-x86_64-GenericCloud-1508.qcow2 image: CentOS-6-x86_64-GenericCloud-1508.qcow2 file format: qcow2 virtual size: 8 GiB (8589934592 bytes) disk size: 1.09 GiB cluster_size: 65536 Format specific information: compat: 0.10 refcount bits: 1
Import the image:
$ glance image-create-via-import --disk-format qcow2 --container-format bare --name centos_1 --file <file_name>
- Record the image ID. It is required in a subsequent step.
Verify that the image is imported and in an active state:
$ openstack image show <image_id>
From a Ceph Storage node, verify that the size of the image is less than the virtual size from the output of step 1:
$ sudo rbd -p images diff <image_id> | awk '{ SUM += $2 } END { print SUM/1024/1024/1024 " GB" }' 1.03906 GB
Optional: You can confirm that
rbd_thin_provisioning
is configured in the glance configuration file on the Controller nodes:Use SSH to access a Controller node:
$ ssh -A -t heat-admin@<controller_node_IP_address>
Confirm that
rbd_thin_provisioning
equalsTrue
on that Controller node:$ sudo podman exec -it glance_api sh -c 'grep ^rbd_thin_provisioning /etc/glance/glance-api.conf'
1.1.8. Secure metadef APIs
In Red Hat OpenStack Platform (RHOSP), users can define key value pairs and tag metadata with metadata definition (metadef) APIs. Currently, there is no limit on the number of metadef namespaces, objects, properties, resources, or tags that users can create.
Metadef APIs can leak information to unauthorized users. A malicious user can exploit the lack of restrictions and fill the Image service (glance) database with unlimited resources, which can create a Denial of Service (DoS) style attack.
Image service policies control metadef APIs. However, the default policy setting for metadef APIs allows all users to create or read the metadef information. Because metadef resources are not isolated to the owner, metadef resources with potentially sensitive names, such as internal infrastructure details or customer names, can expose that information to malicious users.
1.1.8.1. Configuring a policy to restrict metadef APIs
To make the Image service (glance) more secure, restrict metadef modification APIs to admin-only access by default in your Red Hat OpenStack Platform (RHOSP) deployments.
Procedure
As a cloud administrator, create a separate heat template environment file, such as
lock-down-glance-metadef-api.yaml
, to contain policy overrides for the Image service metadef API:... parameter_defaults: GlanceApiPolicies: { glance-metadef_default: { key: 'metadef_default', value: '' }, glance-metadef_admin: { key: 'metadef_admin', value: 'role:admin' }, glance-get_metadef_namespace: { key: 'get_metadef_namespace', value: 'rule:metadef_default' }, glance-get_metadef_namespaces: { key: 'get_metadef_namespaces', value: 'rule:metadef_default' }, glance-modify_metadef_namespace: { key: 'modify_metadef_namespace', value: 'rule:metadef_admin' }, glance-add_metadef_namespace: { key: 'add_metadef_namespace', value: 'rule:metadef_admin' }, glance-delete_metadef_namespace: { key: 'delete_metadef_namespace', value: 'rule:metadef_admin' }, glance-get_metadef_object: { key: 'get_metadef_object', value: 'rule:metadef_default' }, glance-get_metadef_objects: { key: 'get_metadef_objects', value: 'rule:metadef_default' }, glance-modify_metadef_object: { key: 'modify_metadef_object', value: 'rule:metadef_admin' }, glance-add_metadef_object: { key: 'add_metadef_object', value: 'rule:metadef_admin' }, glance-delete_metadef_object: { key: 'delete_metadef_object', value: 'rule:metadef_admin' }, glance-list_metadef_resource_types: { key: 'list_metadef_resource_types', value: 'rule:metadef_default' }, glance-get_metadef_resource_type: { key: 'get_metadef_resource_type', value: 'rule:metadef_default' }, glance-add_metadef_resource_type_association: { key: 'add_metadef_resource_type_association', value: 'rule:metadef_admin' }, glance-remove_metadef_resource_type_association: { key: 'remove_metadef_resource_type_association', value: 'rule:metadef_admin' }, glance-get_metadef_property: { key: 'get_metadef_property', value: 'rule:metadef_default' }, glance-get_metadef_properties: { key: 'get_metadef_properties', value: 'rule:metadef_default' }, glance-modify_metadef_property: { key: 'modify_metadef_property', value: 'rule:metadef_admin' }, glance-add_metadef_property: { key: 'add_metadef_property', value: 'rule:metadef_admin' }, glance-remove_metadef_property: { key: 'remove_metadef_property', value: 'rule:metadef_admin' }, glance-get_metadef_tag: { key: 'get_metadef_tag', value: 'rule:metadef_default' }, glance-get_metadef_tags: { key: 'get_metadef_tags', value: 'rule:metadef_default' }, glance-modify_metadef_tag: { key: 'modify_metadef_tag', value: 'rule:metadef_admin' }, glance-add_metadef_tag: { key: 'add_metadef_tag', value: 'rule:metadef_admin' }, glance-add_metadef_tags: { key: 'add_metadef_tags', value: 'rule:metadef_admin' }, glance-delete_metadef_tag: { key: 'delete_metadef_tag', value: 'rule:metadef_admin' }, glance-delete_metadef_tags: { key: 'delete_metadef_tags', value: 'rule:metadef_admin' } } …
For information about policies and policy syntax, see this Policies chapter.
Include the environment file that contains the policy overrides in the deployment command with the
-e
option when you deploy the overcloud:$ openstack overcloud deploy -e lock-down-glance-metadef-api.yaml
1.1.8.2. Enabling metadef APIs
If you previously restricted metadata definition (metadef) APIs or want to relax the new defaults, you can override metadef modification policies to allow users to update their respective resources.
Cloud administrators with users who depend on write access to the metadef APIs can make those APIs accessible to all users. In this type of configuration, however, there is the potential to unintentionally leak sensitive resource names, such as customer names and internal projects. Administrators must audit their systems to identify previously created resources that might be vulnerable even if only read access is enabled for all users.
Procedure
As a cloud administrator, log in to the undercloud and create a file for policy overrides. For example:
$ cat open-up-glance-api-metadef.yaml
Configure the policy override file to allow metadef API read-write access to all users:
GlanceApiPolicies: { glance-metadef_default: { key: 'metadef_default', value: '' }, glance-get_metadef_namespace: { key: 'get_metadef_namespace', value: 'rule:metadef_default' }, glance-get_metadef_namespaces: { key: 'get_metadef_namespaces', value: 'rule:metadef_default' }, glance-modify_metadef_namespace: { key: 'modify_metadef_namespace', value: 'rule:metadef_default' }, glance-add_metadef_namespace: { key: 'add_metadef_namespace', value: 'rule:metadef_default' }, glance-delete_metadef_namespace: { key: 'delete_metadef_namespace', value: 'rule:metadef_default' }, glance-get_metadef_object: { key: 'get_metadef_object', value: 'rule:metadef_default' }, glance-get_metadef_objects: { key: 'get_metadef_objects', value: 'rule:metadef_default' }, glance-modify_metadef_object: { key: 'modify_metadef_object', value: 'rule:metadef_default' }, glance-add_metadef_object: { key: 'add_metadef_object', value: 'rule:metadef_default' }, glance-delete_metadef_object: { key: 'delete_metadef_object', value: 'rule:metadef_default' }, glance-list_metadef_resource_types: { key: 'list_metadef_resource_types', value: 'rule:metadef_default' }, glance-get_metadef_resource_type: { key: 'get_metadef_resource_type', value: 'rule:metadef_default' }, glance-add_metadef_resource_type_association: { key: 'add_metadef_resource_type_association', value: 'rule:metadef_default' }, glance-remove_metadef_resource_type_association: { key: 'remove_metadef_resource_type_association', value: 'rule:metadef_default' }, glance-get_metadef_property: { key: 'get_metadef_property', value: 'rule:metadef_default' }, glance-get_metadef_properties: { key: 'get_metadef_properties', value: 'rule:metadef_default' }, glance-modify_metadef_property: { key: 'modify_metadef_property', value: 'rule:metadef_default' }, glance-add_metadef_property: { key: 'add_metadef_property', value: 'rule:metadef_default' }, glance-remove_metadef_property: { key: 'remove_metadef_property', value: 'rule:metadef_default' }, glance-get_metadef_tag: { key: 'get_metadef_tag', value: 'rule:metadef_default' }, glance-get_metadef_tags: { key: 'get_metadef_tags', value: 'rule:metadef_default' }, glance-modify_metadef_tag: { key: 'modify_metadef_tag', value: 'rule:metadef_default' }, glance-add_metadef_tag: { key: 'add_metadef_tag', value: 'rule:metadef_default' }, glance-add_metadef_tags: { key: 'add_metadef_tags', value: 'rule:metadef_default' }, glance-delete_metadef_tag: { key: 'delete_metadef_tag', value: 'rule:metadef_default' }, glance-delete_metadef_tags: { key: 'delete_metadef_tags', value: 'rule:metadef_default' } }
NoteYou must configure all metadef policies to use
rule:metadef_default
. For information about policies and policy syntax, see this Policies chapter.Include the new policy file in the deployment command with the
-e
option when you deploy the overcloud:$ openstack overcloud deploy -e open-up-glance-api-metadef.yaml
1.2. Manage images
The Image service (glance) provides discovery, registration, and delivery services for disk and server images. It provides the ability to copy or snapshot a server image, and immediately store it. You can use stored images as a template to commission new servers quickly and more consistently than installing a server operating system and individually configuring services.
1.2.1. Creating an image
Manually create Red Hat OpenStack Platform (RHOSP) compatible images in the QCOW2 format by using Red Hat Enterprise Linux 7 ISO files, Red Hat Enterprise Linux 6 ISO files, or Windows ISO files.
1.2.1.1. Use a KVM guest image with Red Hat OpenStack Platform
You can use a ready RHEL KVM guest QCOW2 image:
These images are configured with cloud-init
and must take advantage of ec2-compatible metadata services for provisioning SSH keys to function correctly.
Ready Windows KVM guest QCOW2 images are not available.
For the KVM guest images:
-
The
root
account in the image is disabled, butsudo
access is granted to a special user namedcloud-user
. -
There is no
root
password set for this image.
The root
password is locked in /etc/shadow
by placing !!
in the second field.
For a RHOSP instance, generate an ssh keypair from the RHOSP dashboard or command line and use that key combination to perform an SSH public authentication to the instance as root.
When the instance is launched, this public key is injected to it. You can then authenticate by using the private key that you download when you create the keypair.
If you want to create custom Red Hat Enterprise Linux or Windows images, see Create a Red Hat Enterprise Linux 7 Image, Create a Red Hat Enterprise Linux 6 Image, or Section 1.2.1.2.3, “Create a Windows image”.
1.2.1.2. Create custom Red Hat Enterprise Linux or Windows images
Prerequisites
- Linux host machine to create an image. This can be any machine on which you can install and run the Linux packages except for the undercloud or the overcloud.
The advanced-virt repository is enabled:
$ sudo subscription-manager repos --enable=advanced-virt-for-rhel-8-x86_64-rpms
libvirt, virt-manager to install all packages necessary to create a guest operating system:
$ sudo dnf module install -y virt
Libguestfs tools to install a set of tools to access and modify virtual machine images:
$ sudo dnf install -y libguestfs-tools-c
- A Red Hat Enterprise Linux 7 or 6 ISO file. For more information, see RHEL 7.2 Binary DVD or RHEL 6.8 Binary DVD or a Windows ISO file. If you do not have a Windows ISO file, see the Microsoft Evaluation Center to download an evaluation image.
-
Text editor, if you want to change the
kickstart
files (RHEL only).
If you install the libguestfs-tools
package on the undercloud, disable iscsid.socket
to avoid port conflicts with the tripleo_iscsid
service on the undercloud:
$ sudo systemctl disable --now iscsid.socket
1.2.1.2.1. Create a Red Hat Enterprise Linux 7 Image
Manually create a Red Hat OpenStack Platform (RHOSP) compatible image in the QCOW2 format by using a Red Hat Enterprise Linux 7 ISO file.
You must run all commands with the [root@host]#
on your host machine.
Start the installation by using
virt-install
:[root@host]# qemu-img create -f qcow2 rhel7.qcow2 8G [root@host]# virt-install --virt-type kvm --name rhel7 --ram 2048 \ --cdrom /tmp/rhel-server-7.2-x86_64-dvd.iso \ --disk rhel7.qcow2,format=qcow2 \ --network=bridge:virbr0 --graphics vnc,listen=0.0.0.0 \ --noautoconsole --os-type=linux --os-variant=rhel7
This launches an instance and starts the installation process.
NoteIf the instance does not launch automatically, run the
virt-viewer
command to view the console:[root@host]# virt-viewer rhel7
Configure the instance:
- At the initial Installer boot menu, select Install Red Hat Enterprise Linux 7.
- Choose the appropriate Language and Keyboard options.
- When prompted about which type of devices your installation uses, select Auto-detected installation media.
- When prompted about which type of installation destination, select Local Standard Disks. For other storage options, select Automatically configure partitioning.
- For software selection, select Minimal Install.
- For network and host name, select eth0 for network and choose a host name for your device. The default host name is localhost.localdomain.
Enter a password in the Root Password field and enter the same password again in the Confirm field.
- Result
- The installation process completes and the Complete! screen is displayed.
- After the installation is complete, reboot the instance and log in as the root user.
Update the
/etc/sysconfig/network-scripts/ifcfg-eth0
file so that it contains only the following values:TYPE=Ethernet DEVICE=eth0 ONBOOT=yes BOOTPROTO=dhcp NM_CONTROLLED=no
- Reboot the machine.
Register the machine with the Content Delivery Network.
# sudo subscription-manager register # sudo subscription-manager attach --pool=Valid-Pool-Number-123456 # sudo subscription-manager repos --enable=rhel-7-server-rpms
Update the system:
# dnf -y update
Install the
cloud-init
packages:# dnf install -y cloud-utils-growpart cloud-init
Edit the
/etc/cloud/cloud.cfg
configuration file and undercloud_init_modules
add:- resolv-conf
The
resolv-conf
option automatically configures theresolv.conf
when an instance boots for the first time. This file contains information related to the instance such asnameservers
,domain
and other options.Add the following line to
/etc/sysconfig/network
to avoid problems accessing the EC2 metadata service:NOZEROCONF=yes
To ensure that the console messages appear in the Log tab on the dashboard and the
nova console-log
output, add the following boot option to the/etc/default/grub
file:GRUB_CMDLINE_LINUX_DEFAULT="console=tty0 console=ttyS0,115200n8"
Run the
grub2-mkconfig
command:# grub2-mkconfig -o /boot/grub2/grub.cfg
The output is as follows:
Generating grub configuration file ... Found linux image: /boot/vmlinuz-3.10.0-229.7.2.el7.x86_64 Found initrd image: /boot/initramfs-3.10.0-229.7.2.el7.x86_64.img Found linux image: /boot/vmlinuz-3.10.0-121.el7.x86_64 Found initrd image: /boot/initramfs-3.10.0-121.el7.x86_64.img Found linux image: /boot/vmlinuz-0-rescue-b82a3044fb384a3f9aeacf883474428b Found initrd image: /boot/initramfs-0-rescue-b82a3044fb384a3f9aeacf883474428b.img done
Deregister the instance so that the resulting image does not contain the subscription details for this instance:
# subscription-manager repos --disable=* # subscription-manager unregister # dnf clean all
Power off the instance:
# poweroff
Reset and clean the image by using the
virt-sysprep
command so that it can be used to create instances without issues:[root@host]# virt-sysprep -d rhel7
Reduce the image size by converting any free space within the disk image back to free space within the host:
[root@host]# virt-sparsify --compress /tmp/rhel7.qcow2 rhel7-cloud.qcow2
This creates a new
rhel7-cloud.qcow2
file in the location from where the command is run.
The rhel7-cloud.qcow2
image file is ready to be uploaded to the Image service. For more information about uploading this image to your RHOSP deployment by using the dashboard, see Section 1.2.2, “Upload an image”.
1.2.1.2.2. Create a Red Hat Enterprise Linux 6 Image
Manually create a Red Hat OpenStack Platform (RHOSP) compatible image in the QCOW2 format by using a Red Hat Enterprise Linux 6 ISO file.
You must run all commands with the [root@host]#
on your host machine.
Start the installation by using
virt-install
:[root@host]# qemu-img create -f qcow2 rhel6.qcow2 4G [root@host]# virt-install --connect=qemu:///system --network=bridge:virbr0 \ --name=rhel6 --os-type linux --os-variant rhel6 \ --disk path=rhel6.qcow2,format=qcow2,size=10,cache=none \ --ram 4096 --vcpus=2 --check-cpu --accelerate \ --hvm --cdrom=rhel-server-6.8-x86_64-dvd.iso
This launches an instance and starts the installation process.
NoteIf the instance does not launch automatically, run the
virt-viewer
command to view the console:[root@host]# virt-viewer rhel6
Configure the instances:
At the initial Installer boot menu, select Install or upgrade an existing system and follow the installation prompts. Accept the defaults.
The disk installer provides an option to test your installation media before installation. Select OK to run the test or Skip to proceed without testing.
- Choose the appropriate Language and Keyboard options.
- When prompted about which type of devices your installation uses, select Basic Storage Devices.
-
Choose a host name for your device. The default host name is
localhost.localdomain
. -
Set the timezone and
root
password. - Based on the space on the disk, choose the type of installation you want from the options in the Which type of installation would you like? window.
- Choose the Basic Server install, which installs an SSH server.
- The installation process completes and the Congratulations, your Red Hat Enterprise Linux installation is complete screen is displayed.
-
Reboot the instance and log in as the
root
user. Update the
/etc/sysconfig/network-scripts/ifcfg-eth0
file so that it contains only the following values:TYPE=Ethernet DEVICE=eth0 ONBOOT=yes BOOTPROTO=dhcp NM_CONTROLLED=no
- Reboot the machine.
Register the machine with the Content Delivery Network:
# sudo subscription-manager register # sudo subscription-manager attach --pool=Valid-Pool-Number-123456 # sudo subscription-manager repos --enable=rhel-6-server-rpms
Update the system:
# dnf -y update
Install the
cloud-init
packages:# dnf install -y cloud-utils-growpart cloud-init
Edit the
/etc/cloud/cloud.cfg
configuration file and add the following content undercloud_init_modules
.- resolv-conf
The
resolv-conf
option automatically configures theresolv.conf
configuration file when an instance boots for the first time. This file contains information related to the instance such asnameservers
,domain
, and other options.To prevent network issues, create
/etc/udev/rules.d/75-persistent-net-generator.rules
:# echo "#" > /etc/udev/rules.d/75-persistent-net-generator.rules
This prevents
/etc/udev/rules.d/70-persistent-net.rules
file from being created. If/etc/udev/rules.d/70-persistent-net.rules
is created, networking might not function correctly when you boot from snapshots, the network interface is created aseth1
rather thaneth0
and the IP address is not assigned.Add the following line to
/etc/sysconfig/network
to avoid problems accessing the EC2 metadata service:NOZEROCONF=yes
To ensure that the console messages appear in the Log tab on the dashboard and the
nova console-log
output, add the following boot option to the/etc/grub.conf
file:console=tty0 console=ttyS0,115200n8
Deregister the virtual machine so that the resulting image does not contain the same subscription details for this instance:
# subscription-manager repos --disable=* # subscription-manager unregister # dnf clean all
Power off the instance:
# poweroff
Reset and clean the image by using the
virt-sysprep
command so that it can be used to create instances without issues:[root@host]# virt-sysprep -d rhel6
Reduce image size by using the
virt-sparsify
command. This command converts any free space within the disk image back to free space within the host:[root@host]# virt-sparsify --compress rhel6.qcow2 rhel6-cloud.qcow2
This creates a new
rhel6-cloud.qcow2
file in the location from where the command is run.NoteYou must manually resize the partitions of instances based on the image in accordance with the disk space in the flavor that is applied to the instance.
The rhel6-cloud.qcow2
image file is ready to be uploaded to the Image service. For more information about uploading this image to your RHOSP deployment by using the dashboard, see Section 1.2.2, “Upload an image”.
1.2.1.2.3. Create a Windows image
Manually create a Red Hat OpenStack Platform (RHOSP) compatible image in the QCOW2 format by using a Windows ISO file.
You must run all commands with the [root@host]#
on your host machine.
Procedure
Start the installation by using
virt-install
:[root@host]# virt-install --name=<name> \ --disk size=<size> \ --cdrom=<path> \ --os-type=windows \ --network=bridge:virbr0 \ --graphics spice \ --ram=<ram>
Replace the following values of the
virt-install
parameters:- <name> — the name that the Windows instance has.
- <size> — disk size in GB.
- <path> — the path to the Windows installation ISO file.
<RAM> — the requested amount of RAM in MB.
NoteThe
--os-type=windows
parameter ensures that the clock is configured correctly for the Windows guest, and enables its Hyper-V enlightenment features. You must also setos_type=windows
in the image metadata before uploading the image to the Image service.
virt-install
saves the guest image as/var/lib/libvirt/images/
<name>
.qcow2
by default. If you want to keep the guest image elsewhere, change the parameter of the--disk
option:--disk path=<filename>,size=<size>
Replace <filename> with the name of the file that stores the instance image, and optionally its path. For example,
path=win8.qcow2,size=8
creates an 8 GB file namedwin8.qcow2
in the current working directory.TipIf the guest does not launch automatically, run the
virt-viewer
command to view the console:[root@host]# virt-viewer <name>
For more information about how to install Windows, see the relevant Microsoft documentation.
-
To allow the newly installed Windows system to use the virtualized hardware, you might need to install VirtIO drivers. To so do, first install the image, which you must attach as a CD-ROM drive to the Windows instance. To install the
virtio-win
package you must add the VirtIO ISO image to the instance, and install the VirtIO drivers. For more information, see Installing KVM paravirtualized drivers for Windows virtual machines in the Configuring and managing virtualization guide. To complete the configuration, download and execute Cloudbase-Init on the Windows system. At the end of the installation of Cloudbase-Init, select the Run Sysprep and Shutdown checkboxes. The
Sysprep
tool makes the guest unique by generating an OS ID, which is used by certain Microsoft services.ImportantRed Hat does not provide technical support for Cloudbase-Init. If you encounter an issue, see Contact Cloudbase Solutions.
When the Windows system shuts down, the <name>.qcow2
image file is ready to be uploaded to the Image service. For more information about uploading this image to your RHOSP deployment by using the dashboard or the command line, see Section 1.2.2, “Upload an image”.
libosinfo data
The Compute Service has deprecated support for using libosinfo data to set default device models. Instead, use the following image metadata properties to configure the optimal virtual hardware for an instance:
-
os_distro
-
os_version
-
hw_cdrom_bus
-
hw_disk_bus
-
hw_scsi_model
-
hw_vif_model
-
hw_video_model
-
hypervisor_type
For more information about these metadata properties, see Image configuration parameters.
1.2.2. Upload an image
- In the dashboard, select Project > Compute > Images.
- Click Create Image.
- Fill out the values, and click Create Image.
Field | Notes |
---|---|
Name | Name for the image. The name must be unique within the project. |
Description | Brief description to identify the image. |
Image Source | Image source: Image Location or Image File. Based on your selection, the next field is displayed. |
Image Location or Image File |
|
Format | Image format (for example, qcow2). |
Architecture | Image architecture. For example, use i686 for a 32-bit architecture or x86_64 for a 64-bit architecture. |
Minimum Disk (GB) | Minimum disk size required to boot the image. If this field is not specified, the default value is 0 (no minimum). |
Minimum RAM (MB) | Minimum memory size required to boot the image. If this field is not specified, the default value is 0 (no minimum). |
Public | If selected, makes the image public to all users with access to the project. |
Protected | If selected, ensures only users with specific permissions can delete this image. |
When the image has been successfully uploaded, its status is active
, which indicates that the image is available for use. Note that the Image service can handle even large images that take a long time to upload — longer than the lifetime of the Identity service token which was used when the upload was initiated. This is due to the fact that the Image service first creates a trust with the Identity service so that a new token can be obtained and used when the upload is complete and the status of the image is to be updated.
You can also use the glance image-create
command with the property
option to upload an image. More values are available on the command line. For a complete listing, see Appendix A, Image configuration parameters.
1.2.3. Update an image
- In the dashboard, select Project > Compute > Images.
Click Edit Image from the list.
NoteThe Edit Image option is available only when you log in as an
admin
user. When you log in as ademo
user, you have the option to Launch an instance or Create Volume.- Update the fields and click Update Image . You can update the following values - name, description, kernel ID, ramdisk ID, architecture, format, minimum disk, minimum RAM, public, protected.
- Click the drop-down menu and select Update Metadata option.
- Specify metadata by adding items from the left column to the right one. In the left column, there are metadata definitions from the Image Service Metadata Catalog. Select Other to add metadata with the key of your choice and click Save when finished.
You can also use the glance image-update
command with the property
option to update an image. More values are available on the command line; for a complete listing, see Appendix A, Image configuration parameters.
1.2.4. Importing an image
You can import images to the Image service (glance) by using one of the following two methods:
-
Use
web-download
to import an image from a URI. -
Use
glance-direct
to import an image from a local file system.
The web-download
method is enabled by default. The cloud administrator configures import methods. You can run the glance import-info
command to list available import options.
1.2.4.1. Import an image from a remote URI
You can use the web-download
method to copy an image from a remote URI.
Create an image and specify the URI of the image to import:
$ glance image-create-via-import \ --container-format <CONTAINER FORMAT> \ --disk-format <DISK-FORMAT> \ --name <NAME> \ --import-method web-download \ --uri <URI>
-
Replace
<CONTAINER FORMAT>
with the container format that you are setting set for your image (None, ami, ari, aki, bare, ovf, ova, docker). -
Replace
<DISK-FORMAT>
with the disk format that you are setting set for your image (None, ami, ari, aki, vhd, vhdx, vmdk, raw, qcow2, vdi, iso, ploop). -
Replace
<NAME>
with a descriptive name for your image. -
Replace
<URI>
with the URI of your image.
-
Replace
You can check the availability of the image by using the
glance image-show <IMAGE_ID>
command.-
Replace
<IMAGE_ID>
with the ID you provided during image creation.
-
Replace
The Image service web download
method uses a two-stage process to perform the import:
-
The
web download
method creates an image record. -
The
web download
method retrieves the image from the specified URI.
The URI is subject to optional denylist and allowlist filtering.
The Image Property Injection plugin may inject metadata properties to the image. These injected properties determine which compute nodes the image instances are launched on.
1.2.4.2. Import an image from a local volume
The glance-direct
method creates an image record, which generates an image ID. After the image is uploaded to the Image service from a local volume, it is stored in a staging area and is made active after it passes any configured checks. The glance-direct
method requires a shared staging area when used in a highly available (HA) configuration.
Image uploads that use the glance-direct
method can fail in a HA environment if a common staging area is not present. In a HA active-active environment, API calls are distributed to the Image service controllers. The download API call can be sent to a different controller than the API call to upload the image.
The glance-direct method uses three different calls to import an image:
-
glance image-create
-
glance image-stage
-
glance image-import
You can use the glance image-create-via-import
command to perform all three of these calls in one command:
$ glance image-create-via-import --container-format <CONTAINER FORMAT> --disk-format <DISK-FORMAT> --name <NAME> --file </PATH/TO/IMAGE>
-
Replace
<CONTAINER FORMAT>
,<DISK-FORMAT>
,<NAME>
, and</PATH/TO/IMAGE>
with the relevant values for your image.
After the image moves from the staging area to the back-end location, the image is listed. However, it might take some time for the image to become active.
You can check the availability of the image by using the glance image-show <IMAGE_ID>
command.
-
Replace
<IMAGE_ID
with the ID you provided during image creation.
1.2.5. Delete an image
- In the dashboard, select Project > Compute > Images.
- Select the image you want to delete and click Delete Images.
1.2.6. Hide or unhide an image
You can hide public images from normal listings presented to users. For instance, you can hide obsolete CentOS 7 images and show only the latest version to simplify the user experience. Users can discover and use hidden images.
To hide an image:
glance image-update <image_id> --hidden 'true'
To create a hidden image, add the --hidden
argument to the glance image-create
command.
To unhide an image:
glance image-update <image_id> --hidden 'false'
1.2.8. Enabling image conversion
With the GlanceImageImportPlugins
parameter enabled, you can upload a QCOW2 image, and the Image service can convert it to RAW.
Image conversion is automatically enabled when you use Red Hat Ceph Storage RBD to store images and boot Nova instances.
To enable image conversion, create an environment file that contains the following parameter value and include the new environment file with the -e
option in the openstack overcloud deploy
command:
+
parameter_defaults: GlanceImageImportPlugins:'image_conversion'
1.2.9. Converting an image to RAW format
Red Hat Ceph Storage can store, but does not support using, QCOW2 images to host virtual machine (VM) disks.
When you upload a QCOW2 image and create a VM from it, the compute node downloads the image, converts the image to RAW, and uploads it back into Ceph, which can then use it. This process affects the time it takes to create VMs, especially during parallel VM creation.
For example, when you create multiple VMs simultaneously, uploading the converted image to the Ceph cluster might impact already running workloads. The upload process can starve those workloads of IOPS and impede storage responsiveness.
To boot VMs in Ceph more efficiently (ephemeral back end or boot from volume), the glance image format must be RAW.
Procedure
Converting an image to RAW might yield an image that is larger in size than the original QCOW2 image file. Run the following command before the conversion to determine the final RAW image size:
qemu-img info <image>.qcow2
Convert an image from QCOW2 to RAW format:
qemu-img convert -p -f qcow2 -O raw <original qcow2 image>.qcow2 <new raw image>.raw
1.2.9.1. Configuring disk formats in the Image service (glance)
You can the configure the Image service (glance) to enable or reject disk formats by using the GlanceDiskFormats
parameter.
Procedure
-
Log in to the undercloud host as the
stack
user. Source the undercloud credentials file:
$ source ~/stackrc
Include the
GlanceDiskFormats
parameter in an environment file, for example,glance_disk_formats.yaml
:parameter_defaults: GlanceDiskFormats: - <disk_format>
For example, use the following configuration to enable only RAW and ISO disk formats:
parameter_defaults: GlanceDiskFormats: - raw - iso
Use the following example configuration to reject QCOW2 disk images:
parameter_defaults: GlanceDiskFormats: - raw - iso - aki - ari - ami
Include the environment file that contains your new configuration in the
openstack overcloud deploy
command with any other environment files that are relevant to your environment:$ openstack overcloud deploy --templates \ -e <overcloud_environment_files> \ -e <new_environment_file> \ …
-
Replace
<overcloud_environment_files>
with the list of environment files that are part of your deployment. -
Replace
<new_environment_file>
with the environment file that contains your new configuration.
-
Replace
For more information about the disk formats available in RHOSP, see Chapter 1, The Image service (glance).
1.2.10. Storing an image in RAW format
With the GlanceImageImportPlugins
parameter enabled, run the following command to store a previously created image in RAW format:
$ glance image-create-via-import \ --disk-format qcow2 \ --container-format bare \ --name NAME \ --visibility public \ --import-method web-download \ --uri http://server/image.qcow2
-
For
--name
, replaceNAME
with the name of the image; this is the name that will appear inglance image-list
. -
For
--uri
, replacehttp://server/image.qcow2
with the location and file name of the QCOW2 image.
This command example creates the image record and imports it by using the web-download
method. The glance-api downloads the image from the --uri
location during the import process. If web-download
is not available, glanceclient
cannot automatically download the image data. Run the glance import-info
command to list the available image import methods.