第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.
重要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.
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-directfor importing from a local file system
