Red Hat Training

A Red Hat training course is available for Red Hat OpenStack Platform

Chapter 1. Image service

You can 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.
  • VMDK - Disk format supported by many common virtual machine monitors.
  • 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.

Because ISO files contain bootable file systems with an installed operating system, you can use ISO files in the same way that you use 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 and optimizing the Image service

You can use the following Red Hat OpenStack Platform (RHOSP) Image service (glance) features to manage and optimize images and storage in your RHOSP deployment.

1.1.1. Supported Image service (glance) 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.
  • Object Storage (swift). For more information, see Using an External Object Storage Cluster in the Advanced Overcloud Customization guide.

  • Block Storage (cinder). For more information, see Configuring cinder back end for the Image service in the Advanced Overcloud Customization guide.

    Note
    The Image service uses the Block Storage type and back end as the default.

  • 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 production-grade NFS back end.
    • Ensure that a Layer 2 connection is established between Controller nodes and the NFS back end.
    • Include monitoring and alerts for the mounted share.

    • Set underlying FS permissions.

      • 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.
      • The write permissions must be present in the shared file system that you use as a store.

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:

  • 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, refer to the Validate Glance Images chapter of 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 move it 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 Enabling image conversion.

Note

You can trigger the conversion only when you import an image. Conversion does not run when you upload 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. Image introspection

Every image format comes with a set of metadata embedded inside the image itself. For example, a stream optimized vmdk would contain the following parameters: 

$ head -20 so-disk.vmdk

# Disk DescriptorFile
version=1
CID=d5a0bce5
parentCID=ffffffff
createType="streamOptimized"

# Extent description
RDONLY 209714 SPARSE "generated-stream.vmdk"

# The Disk Data Base
#DDB

ddb.adapterType = "buslogic"
ddb.geometry.cylinders = "102"
ddb.geometry.heads = "64"
ddb.geometry.sectors = "32"
ddb.virtualHWVersion = "4"

By introspecting this vmdk, you can know that the disk_type is streamOptimized, and the adapter_type is buslogic. These metadata parameters are useful for the consumer of the image. In Compute, the workflow to instantiate a streamOptimized disk is different from the one to instantiate a flat disk. This new feature allows metadata extraction. You can achieve image introspection by calling the task API while you import the image. An administrator can override metadata settings.

1.1.5. Interoperable image import

The OpenStack Image service (glance) provides two methods to import images by using the interoperable image import workflow:

  • web-download (default) for importing images from a URI
  • glance-direct for importing from a local file system

1.2. Managing images

The OpenStack 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 get new servers up and running 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. Using 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 properly.

Ready Windows KVM guest QCOW2 images are not available.

Note

For the KVM guest images:

  • The root account in the image is disabled, but sudo access is granted to a special user named cloud-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, it is recommended that you 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 use the private key you downloaded while you created the keypair to authenticate.

If you do not want to use keypairs, you can use the admin password that you can set in the procedure to inject an admin password, see Injecting an admin password into an instance.

If you want to create custom Red Hat Enterprise Linux or Windows images, see:

1.2.1.2. Creating 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.
  • libvirt, virt-manager (run command yum groupinstall -y @virtualization). This installs all packages necessary to create a guest operating system.
  • Libguestfs tools (run command yum install -y libguestfs-tools-c). This installs a set of tools to access and modify virtual machine images.
  • A Red Hat Enterprise Linux 7 or 6 ISO file (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, visit the Microsoft TechNet Evaluation Center and download an evaluation image.
  • A text editor if you want to change the kickstart files (RHEL only).
Important

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
Note

In the following procedures, you must run all commands with the [root@host]# prompt on your host machine.

1.2.1.2.1. Creating 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.

Procedure

  1. Start the installation 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.

    Note

    If the instance does not launch automatically, run the virt-viewer command to view the console: 

    [root@host]# virt-viewer rhel7

  2. Configure the virtual machine as follows:

    1. At the initial Installer boot menu, choose the Install Red Hat Enterprise Linux 7.X option.
    2. Choose the appropriate Language and Keyboard options.
    3. When prompted about which type of devices your installation uses, choose Auto-detected installation media.
    4. When prompted about which type of installation destination, choose Local Standard Disks. For other storage options, choose Automatically configure partitioning.
    5. For software selection, choose Minimal Install.
    6. For network and host name, choose eth0 for network and choose a hostname for your device. The default host name is localhost.localdomain.
    7. Choose the root password. The installation process completes and the Complete! screen appears.
  3. After the installation is complete, reboot the instance and log in as the root user.

  4. 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
  5. Reboot the machine.

  6. 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

  7. Update the system: 

    # yum -y update

  8. Install the cloud-init packages: 

    # yum install -y cloud-utils-growpart cloud-init

  9. Edit the /etc/cloud/cloud.cfg configuration file and under cloud_init_modules add: 

    - resolv-conf

    The resolv-conf option automatically configures the resolv.conf when an instance boots for the first time. This file contains information related to the instance such as nameservers, domain and other options.

  10. Add the following line to /etc/sysconfig/network to avoid problems accessing the EC2 metadata service: 

    NOZEROCONF=yes

  11. To ensure 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

  12. Un-register the virtual machine so that the resulting image does not contain the same subscription details for every instance cloned based on it: 

    # subscription-manager repos --disable=*
# subscription-manager unregister
# yum clean all

  13. Power off the instance: 

    # poweroff

  14. Use the virt-sysprep command to reset and clean the image so that it can be used to create instances without issues: 

    [root@host]# virt-sysprep -d rhel7

  15. 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 /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 using the dashboard to upload this image to your RHOSP deployment, see Upload an Image.

1.2.1.2.2. Creating 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.

Procedure

  1. Use virt-install to start the installation: 

    [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.

    Note

    If the instance does not launch automatically, run the virt-viewer command to view the console: 

    [root@host]# virt-viewer rhel6

  2. Configure the virtual machines as follows:

    1. At the initial Installer boot menu, choose the Install or upgrade an existing system option. Follow the installation prompts. Accept the defaults.

      The installer checks for the disc and lets you decide whether you want to test your installation media before installation. Select OK to run the test or Skip to proceed without testing.

    2. Choose the appropriate Language and Keyboard options.
    3. When prompted about which type of devices your installation uses, choose Basic Storage Devices.
    4. Choose a hostname for your device. The default host name is localhost.localdomain.
    5. Set timezone and root password.
    6. Based on the space on the disk, choose the type of installation.
    7. Choose the Basic Server install, which installs an SSH server.
    8. The installation process completes and Congratulations, your Red Hat Enterprise Linux installation is complete screen appears.
  3. Reboot the instance and log in as the root user.

  4. Update the /etc/sysconfig/network-scripts/ifcfg-eth0 file so it only contains the following values: 

    TYPE=Ethernet
DEVICE=eth0
ONBOOT=yes
BOOTPROTO=dhcp
NM_CONTROLLED=no
  5. Reboot the machine.

  6. 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

  7. Update the system: 

    # yum -y update

  8. Install the cloud-init packages: 

    # yum install -y cloud-utils-growpart cloud-init

  9. Edit the /etc/cloud/cloud.cfg configuration file and under cloud_init_modules add: 

    - resolv-conf

    The resolv-conf option automatically configures the resolv.conf configuration file when an instance boots for the first time. This file contains information related to the instance such as nameservers, domain, and other options.

  10. To prevent network issues, create the /etc/udev/rules.d/75-persistent-net-generator.rules file as follows: 

    # 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 booting from snapshots (the network interface is created as eth1 rather than eth0 and IP address is not assigned).

  11. Add the following line to /etc/sysconfig/network to avoid problems accessing the EC2 metadata service: 

    NOZEROCONF=yes

  12. To ensure 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: 

    console=tty0 console=ttyS0,115200n8

  13. Un-register the virtual machine so that the resulting image does not contain the same subscription details for every instance cloned based on it: 

    # subscription-manager repos --disable=*
# subscription-manager unregister
# yum clean all

  14. Power off the instance: 

    # poweroff

  15. Use the virt-sysprep command to reset and clean the image so that it can be used to create instances without issues: 

    [root@host]# virt-sysprep -d rhel6

  16. 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.

    Note

    You 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 upload to the Image service. For more information about using the dashboard to upload this image to your RHOSP deployment, see Upload an Image

1.2.1.2.3. Creating a Windows image

Manually create a Red Hat OpenStack Platform (RHOSP) compatible image in the QCOW2 format by using a Windows ISO file.

Procedure

  1. Use virt-install to start the installation: 

    [root@host]# virt-install --name=<name> \
--disk size=<size> \
--cdrom=<path>` \
--os-type=windows \
--network=bridge:virbr0 \
--graphics spice \
--ram=<RAM>

    Replace the values of the virt-install parameters as follows:

    • <name> — the name of the Windows guest.
    • <size> — disk size in GB.
    • <path> — the path to the Windows installation ISO file.

    • <RAM> — the requested amount of RAM in MB.

      Note

      The --os-type=windows parameter ensures that the clock is configured correctly for the Windows guest, and enables its Hyper-V enlightenment features.

      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 as follows: 

      --disk path=<filename>,size=<size>

      Replace <filename> with the name of the file that stores the guest image, and optionally its path, for example, path=win8.qcow2,size=8 creates an 8 GB file named win8.qcow2 in the current working directory.

      Tip

      If the guest does not launch automatically, run the virt-viewer command to view the console: 

      [root@host]# virt-viewer <name>
  2. Installation of Windows systems is beyond the scope of this document. For instructions about how to install Windows, see the relevant Microsoft documentation.
  3. To allow the newly installed Windows system to use the virtualized hardware, you might need to install virtio drivers in it. To so do, first install the virtio-win package on the host system. This package contains the virtio ISO image, which you must attach as a CD-ROM drive to the Windows guest. See Chapter 8. KVM Para-virtualized (virtio) Drivers in the Virtualization Deployment and Administration Guide for detailed instructions on how to install the virtio-win package, add the virtio ISO image to the guest, and install the virtio drivers.

  4. 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 check boxes. The Sysprep tool makes the guest unique by generating an OS ID, which certain Microsoft services use.

    Important

    Red Hat does not provide technical support for Cloudbase-Init. If you encounter an issue, contact Cloudbase Solutions.

When the Windows system shuts down, the <name>_.qcow2 image file is ready to upload to the Image service. For more information about using the dashboard or the command line to upload this image to your RHOSP deployment, see Uploading an Image.

Note

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 Appendix A, Image configuration parameters.

1.2.2. Uploading an image

Procedure

  1. In the dashboard, select Project > Compute > Images.
  2. Click Create Image.
  3. Complete the values, and click Create Image when finished.

Table 1.1. Image options

FieldNotes

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

  • Select Image Location option to specify the image location URL.
  • Select Image File option to upload an image from the local disk.

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 changed to active, which indicates that the image is available for use. 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 to initiate the upload. 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.

Note

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 list of available metadata properties, see Image Configuration Parameters.

1.2.3. Updating an image

Procedure

  1. In the dashboard, select Project > Compute > Images.

  2. Click Edit Image from the list.

    Note

    The Edit Image option is available only when you log in as an admin user. When you log in as a demo user, you have the option to Launch an instance or Create Volume.

  3. Update the fields and click Update Image when finished. You can update the following values - name, description, kernel ID, ramdisk ID, architecture, format, minimum disk, minimum RAM, public, protected.
  4. Click the menu and select Update Metadata option.
  5. 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.
Note

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 list of available metadata properties, see Image Configuration Parameters.

1.2.4. Importing an image

You can import images into the Image service (glance) by using web-download to import an image from a URI and glance-direct to import an image from a local file system. The web-download option is enabled by default.

Import methods are configured by the cloud administrator. Run the glance import-info command to list available import options.

1.2.4.1. Importing from a remote URI

You can use the web-download method to copy an image from a remote URI by using a two-stage process. First, an image record is created and then the image is retrieved from a URI. This method provides a more secure way to import images than the deprecated copy-from method used in Image API v1.

Procedure

  1. Create an image and specify the URI of the image to import. 

    $ glance image-create --uri <URI>

  2. You can monitor the availability of the image: 

    $ openstack image show <image_id> command.

    Replace the ID with the one provided during image creation.

1.2.4.2. Importing from a local volume

The glance-direct method creates an image record, which generates an image ID. After the image is uploaded to the 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.

Note

Image uploads that use the glance-direct method fail in an HA environment if a common staging area is not present. In an 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. For more information about configuring the staging area, see Storage Configuration in the Advanced Overcloud Customization Guide.

The glance-direct method uses the following calls to import an image:

  • glance image-create
  • glance image-stage
  • glance image-import

Procedure

  1. 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 <format> --disk-format <disk_format> --name <name> --file <path_to_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.

  2. You can monitor the availability of the image: 

    $ openstack image show <image_id> command.

    Replace the ID with the one provided during image creation.

1.2.5. Deleting an image

Procedure

  1. In the dashboard, select Project > Compute > Images.
  2. Select the image you want to delete and click Delete Images.

1.2.6. Enabling image conversion

With the GlanceImageImportPlugins parameter enabled, you can upload a QCOW2 image, and the Image service converts it to RAW.

Procedure

  • To enable image conversion, create an environment file that contains the following parameter value and include the new environment file with any other environment files that are relevant to your deployment by using the -e option in the openstack overcloud deploy command: 

    parameter_defaults:
  GlanceImageImportPlugins:'image_conversion'

1.2.7. Converting an image to RAW format

Red Hat Ceph 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 Image service image format must be RAW.

Procedure

  1. 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

  2. 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.7.1. Configuring the Image service to accept only RAW and ISO

You can configure the Image service to accept only RAW and ISO image formats.

Procedure

  1. Add an additional environment file that contains the following content in the openstack overcloud deploy command with your other environment files: 

    parameter_defaults:
  ExtraConfig:
    glance::config::api_config:
      image_format/disk_formats:
        value: "raw,iso"

1.2.8. Storing an image in RAW format

Procedure

  • With the GlanceImageImportPlugins parameter enabled, run the following command to upload a QCOW2 image and automatically convert it to 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>
  • Replace <name> with the name of the image; this is the name that appears in openstack image list.
  • For --uri, replace <http://server/image.qcow2> with the location and file name of the QCOW2 image.
Note

This example command 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.