Appendix C. Whole Disk Images

The main overcloud image is a flat partition image that contains no partitioning information or bootloader on the images itself. The director uses a separate kernel and ramdisk when booting nodes and creates a basic partitioning layout when writing the overcloud image to disk. However, you can create a whole disk image, which includes a partitioning layout, bootloader, and hardened security.


The following process uses the director’s image building feature. Red Hat only supports images built using the guidelines contained in this section. Custom images built outside of these specifications are not supported.

A security hardened image includes extra security measures necessary for Red Hat OpenStack Platform deployments where security is an important feature. Consider the following list of recommendations when you create a security hardened image:

  • The /tmp directory is mounted on a separate volume or partition and has the rw, nosuid, nodev, noexec, and relatime flags
  • The /var, /var/log and the /var/log/audit directories are mounted on separate volumes or partitions, with the rw and relatime flags
  • The /home directory is mounted on a separate partition or volume and has the rw, nodev, and relatime flags
  • Include the following changes to the GRUB_CMDLINE_LINUX setting:

    • To enable auditing, add the audit=1 kernel boot flag.
    • To disable the kernel support for USB using boot loader configuration, add nousb.
    • To remove the insecure boot flags, set crashkernel=auto
  • Blacklist insecure modules (usb-storage, cramfs, freevxfs, jffs2, hfs, hfsplus, squashfs, udf, vfat) and prevent these modules from loading.
  • Remove any insecure packages (kdump installed by kexec-tools and telnet) from the image as they are installed by default
  • Add the new screen package necessary for security

To build a security hardened image, complete the following steps:

  1. Download a base Red Hat Enterprise Linux 7 image
  2. Set the environment variables specific to registration
  3. Customize the image by modifying the partition schema and the size
  4. Create the image
  5. Upload the image to director

The following sections contain procedures to achieve these tasks.

C.1. Downloading the Base Cloud Image

Before building a whole disk image, you must download an existing cloud image of Red Hat Enterprise Linux to use as a basis. Navigate to the Red Hat Customer Portal and select the KVM Guest Image to download. For example, the KVM Guest Image for the latest Red Hat Enterprise Linux is available on the following page:

C.2. Disk Image Environment Variables

As a part of the disk image building process, the director requires a base image and registration details to obtain packages for the new overcloud image. Define these attributes with the following Linux environment variables.


The image building process temporarily registers the image with a Red Hat subscription and unregisters the system once the image building process completes.

To build a disk image, set Linux environment variables that suit your environment and requirements:

Sets the local image that you want to use as the basis for your whole disk image.
Use an activation key instead of login details as part of the registration process.
Defines whether to attach the most compatible subscription automatically.
The base URL of the content delivery server containing packages for the image. The default Customer Portal Subscription Management process uses If you use a Red Hat Satellite 6 server, set this parameter to the base URL of your Satellite server.
Registers to an environment within an organization.
Sets the method of registration. Use portal to register a system to the Red Hat Customer Portal. Use satellite to register a system with Red Hat Satellite 6.
The organization where you want to register the images.
The pool ID of the product subscription information.
Gives the password for the user account that registers the image.

A comma-separated string of repository names. Each repository in this string is enabled through subscription-manager.

Use the following repositories for a security hardened whole disk image:

  • rhel-7-server-rpms
  • rhel-7-server-extras-rpms
  • rhel-ha-for-rhel-7-server-rpms
  • rhel-7-server-optional-rpms
  • rhel-7-server-openstack-14-rpms
The base URL of the Satellite server to register Overcloud nodes. Use the Satellite’s HTTP URL and not the HTTPS URL for this parameter. For example, use and not
Gives the hostname of the subscription service to use. The default is for the Red Hat Customer Portal at If using a Red Hat Satellite 6 server, set this parameter to the hostname of your Satellite server.
Gives the user name for the account that registers the image.

Use the following set of example commands to export a set of environment variables and temporarily register a local QCOW2 image to the Red Hat Customer Portal:

$ export DIB_LOCAL_IMAGE=./rhel-server-7.5-x86_64-kvm.qcow2
$ export REG_METHOD=portal
$ export REG_USER="[your username]"
$ export REG_PASSWORD="[your password]"
$ export REG_REPOS="rhel-7-server-rpms \
    rhel-7-server-extras-rpms \
    rhel-ha-for-rhel-7-server-rpms \
    rhel-7-server-optional-rpms \

C.3. Customizing the Disk Layout

The default security hardened image size is 20G and uses predefined partitioning sizes. However, you must modify the partitioning layout to accommodate overcloud container images. Complete the steps in the following sections to increase the image size to 40G. You can modify the partitioning layout and disk size to further suit your needs.

To modify the partitioning layout and disk size, perform the following steps:

  • Modify the partitioning schema using the DIB_BLOCK_DEVICE_CONFIG environment variable.
  • Modify the global size of the image by updating the DIB_IMAGE_SIZE environment variable.

C.3.1. Modifying the Partitioning Schema

You can modify the partitioning schema to alter the partitioning size, create new partitions, or remove existing ones. You can define a new partitioning schema with the following environment variable:

$ export DIB_BLOCK_DEVICE_CONFIG='<yaml_schema_with_partitions>'

The following YAML structure represents the modified logical volume partitioning layout to accommodate enough space to pull overcloud container images:

- local_loop:
    name: image0
- partitioning:
    base: image0
    label: mbr
      - name: root
        flags: [ boot,primary ]
        size: 40G
- lvm:
    name: lvm
    base: [ root ]
        - name: pv
          base: root
          options: [ "--force" ]
        - name: vg
          base: [ "pv" ]
          options: [ "--force" ]
        - name: lv_root
          base: vg
          extents: 23%VG
        - name: lv_tmp
          base: vg
          extents: 4%VG
        - name: lv_var
          base: vg
          extents: 45%VG
        - name: lv_log
          base: vg
          extents: 23%VG
        - name: lv_audit
          base: vg
          extents: 4%VG
        - name: lv_home
          base: vg
          extents: 1%VG
- mkfs:
    name: fs_root
    base: lv_root
    type: xfs
    label: "img-rootfs"
        mount_point: /
            options: "rw,relatime"
            fsck-passno: 1
- mkfs:
    name: fs_tmp
    base: lv_tmp
    type: xfs
        mount_point: /tmp
            options: "rw,nosuid,nodev,noexec,relatime"
            fsck-passno: 2
- mkfs:
    name: fs_var
    base: lv_var
    type: xfs
        mount_point: /var
            options: "rw,relatime"
            fsck-passno: 2
- mkfs:
    name: fs_log
    base: lv_log
    type: xfs
        mount_point: /var/log
            options: "rw,relatime"
            fsck-passno: 3
- mkfs:
    name: fs_audit
    base: lv_audit
    type: xfs
        mount_point: /var/log/audit
            options: "rw,relatime"
            fsck-passno: 4
- mkfs:
    name: fs_home
    base: lv_home
    type: xfs
        mount_point: /home
            options: "rw,nodev,relatime"
            fsck-passno: 2

Use this sample YAML content as a basis for your image’s partition schema. Modify the partition sizes and layout to suit your needs.


You must define the correct partition sizes for the image as you cannot resize them after the deployment.

C.3.2. Modifying the Image Size

The global sum of the modified partitioning schema might exceed the default disk size (20G). In this situation, you might need to modify the image size. To modify the image size, edit the configuration files that create the image.

Create a copy of the /usr/share/openstack-tripleo-common/image-yaml/overcloud-hardened-images.yaml:

# cp /usr/share/openstack-tripleo-common/image-yaml/overcloud-hardened-images.yaml \

Edit the DIB_IMAGE_SIZE in the configuration file and adjust the values as necessary:


DIB_MODPROBE_BLACKLIST: 'usb-storage cramfs freevxfs jffs2 hfs hfsplus squashfs udf vfat bluetooth'
DIB_BOOTLOADER_DEFAULT_CMDLINE: 'nofb nomodeset vga=normal console=tty0 console=ttyS0,115200 audit=1 nousb'
Adjust this value to the new total disk size.

Save this file.


When you deploy the overcloud, the director creates a RAW version of the overcloud image. This means your undercloud must have enough free space to accommodate the RAW image. For example, if you increase the security hardened image size to 40G, you must have 40G of space available on the undercloud’s hard disk.


When the director writes the image to the physical disk, the director creates a 64MB configuration drive primary partition at the end of the disk. When you create your whole disk image, ensure the size of the physical disk accommodates this extra partition.

C.4. Creating a Security Hardened Whole Disk Image

After you have set the environment variables and customized the image, create the image using the openstack overcloud image build command:

# openstack overcloud image build \
--image-name overcloud-hardened-full \
--config-file /home/stack/overcloud-hardened-images-custom.yaml \ 1
--config-file /usr/share/openstack-tripleo-common/image-yaml/overcloud-hardened-images-rhel7.yaml
This is the custom configuration file containing the new disk size from Section C.3.2, “Modifying the Image Size”. If you are not using a different custom disk size, use the original /usr/share/openstack-tripleo-common/image-yaml/overcloud-hardened-images.yaml file instead.

This command creates an image called overcloud-hardened-full.qcow2, which contains all the necessary security features.

C.5. Uploading a Security Hardened Whole Disk Image

Upload the image to the OpenStack Image (glance) service and start using it from the Red Hat OpenStack Platform director. To upload a security hardened image, complete the following steps:

  1. Rename the newly generated image and move the image to your images directory:

    # mv overcloud-hardened-full.qcow2 ~/images/overcloud-full.qcow2
  2. Remove all the old overcloud images:

    # openstack image delete overcloud-full
    # openstack image delete overcloud-full-initrd
    # openstack image delete overcloud-full-vmlinuz
  3. Upload the new overcloud image:

    # openstack overcloud image upload --image-path /home/stack/images --whole-disk

If you want to replace an existing image with the security hardened image, use the --update-existing flag. This flag overwrites the original overcloud-full image with a new security hardened image.