Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
Applies to SUSE OpenStack Cloud Crowbar 8

2 Managing Images

In the SUSE OpenStack Cloud Crowbar context, images are virtual disk images that represent the contents and structure of a storage medium or device, such as a hard disk, in a single file. Images are used as a template from which a virtual machine can be started. For starting a virtual machine, SUSE OpenStack Cloud Crowbar always uses a copy of the image.

Images have both content and metadata. The latter are also called image properties.

Permissions to manage images are defined by the cloud operator during setup of SUSE OpenStack Cloud Crowbar. Image upload and management may be restricted to cloud administrators or cloud operators only.

Managing images for SUSE OpenStack Cloud Crowbar requires the following basic steps:

  1. Building Images with SUSE Studio.

    For general and hypervisor-specific requirements, refer to Section 2.1, “Image Requirements”.

  2. Uploading Disk Images to SUSE OpenStack Cloud Crowbar.

    Images can either be uploaded to SUSE OpenStack Cloud Crowbar with the unified python-openstackclient from command line or with the SUSE OpenStack Cloud Crowbar Dashboard. As the Dashboard has some limitations regarding image upload and modification of properties, it is recommended to use the unified python-openstackclient for comprehensive image management.

  3. Specifying Image Properties. You can do so during image upload (using openstack image create) or with openstack image set after the image has already been uploaded. Refer to Procedure 2.2, “Uploading Disk Images to SUSE OpenStack Cloud Crowbar and Procedure 2.3, “Modifying Image Properties”.

    Important
    Important: Properties for Architecture, Hypervisor and VM Mode

    OpenStack Image does not check nor automatically detect any image properties. Therefore you need to specify the image's properties manually.

    This is especially important when using mixed virtualization environments to make sure that an image is only launched on appropriate hypervisors. The properties can specify a certain architecture, hypervisor type, or application binary interface (ABI) that the image requires.

2.1 Image Requirements

To build the images to use within the cloud, use SUSE Studio or SUSE Studio Onsite as they provide automatic insertion of management scripts and agents. Make sure any images that you build for SUSE OpenStack Cloud Crowbar fulfill the following requirements.

2.1.1 General Image Requirements

  • The network is set to DHCP.

  • The image does not include YaST2 Firstboot.

  • The image does not include any end-user license agreement (EULA) dialogs.

  • The image contains the cloud-init package. The package will be automatically added to the image if the following check box in SUSE Studio or SUSE Studio Onsite is enabled: Integrate with SUSE OpenStack Cloud Crowbar/OpenStack.

    The cloud-init package contains tools used for communication with the instance metadata API, which is provided by Compute. The metadata API is only accessible from inside the VM. The package is needed to pull keypairs into the virtual machine that will run the image.

If you intend to manage the image by the Orchestration module, you also need to include the following package: openstack-heat-cfntools (part of the SUSE OpenStack Cloud Crowbar ISO).

2.1.2 Image Requirements Depending on Hypervisor

For a list of supported VM guests, refer to the SUSE® Linux Enterprise Server Virtualization Guide, section Supported VM Guests. It is available at https://documentation.suse.com/sles/12-SP5/single-html/SLES-virtualization/#virt-support-guests.

Depending on the virtualization platform on which you want to use the image, make sure the image also fulfills the following requirements.

KVM

Appliance format: If you are using SUSE Studio or SUSE Studio Onsite 1.3 to build images, use the SUSE OpenStack Cloud Crowbar/OpenStack/KVM (.qcow2) format.

Xen

Appliance format: If you are using SUSE Studio or SUSE Studio Onsite 1.3 to build images, use the SUSE OpenStack Cloud Crowbar/OpenStack/KVM (.qcow2) format.

VMware

Appliance format: If you are using SUSE Studio or SUSE Studio Onsite 1.3 to build images, use the VMware/VirtualBox/KVM (.vmdk) format.

If you are using SUSE Studio or SUSE Studio Onsite to build images, the resulting image will be a monolithic sparse file.

Note
Note: Image Conversion

Sparse images can be uploaded to OpenStack Image. However, it is recommended to convert sparse images into a different format before uploading them to OpenStack Image (because starting VMs from sparse images may take longer).

For a list of supported image types, refer to https://docs.openstack.org/nova/pike/admin/configuration/hypervisor-vmware.html, section Supported image types.

For details on how to convert a sparse image into different formats, refer to https://docs.openstack.org/nova/pike/admin/configuration/hypervisor-vmware.html, section Optimize images.

2.1.3 Images for Use With Multiple Hypervisors

If you build the images for SUSE OpenStack Cloud Crowbar in SUSE Studio or SUSE Studio Onsite, they are compatible with multiple hypervisors by default—even if you may need to convert the resulting image formats before uploading them to OpenStack Image. See Procedure 2.1, “Converting Disk Images to Different Formats” for details.

If your image is not made in SUSE Studio or SUSE Studio Onsite, configure the image as follows to create an image that can be booted on KVM and Xen, for example:

/etc/sysconfig/kernel
INITRD_MODULES="virtio_blk virtio_pci ata_piix ata_generic hv_storvsc"
/boot/grub/menu.lst

To name the partition that should be booted, use:

root=UUID=...

To find the respective UUID value to use, execute the following command:

tune2fs -l /dev/sda2|grep UUID
/etc/fstab

Do not use device names (/dev/...), but UUID=... or LABEL=root entries. For the latter, add the label root to the root file system of your image (in this case, /dev/sda2):

tune2fs -L root /dev/sda2
Disk Format

Use *.qcow2 as disk format for your image.

Image Properties in OpenStack Image

To upload the image to SUSE OpenStack Cloud Crowbar only once and to use the same image for KVM and Xen, specify the following image options during or after upload:

--public --container-format bare \
--property architecture=x86_64 \
--property vm_mode=hvm \
--disk-format qcow2

2.2 Building Images with SUSE Studio

When creating an appliance for SUSE OpenStack Cloud Crowbar the following steps are essential:

  1. In SUSE Studio or SUSE Studio Onsite, switch to the Configuration › Appliance tab.

  2. Enable the Integrate with SUSE OpenStack Cloud Crowbar/OpenStack check box.

  3. On the Build tab, choose the respective appliance format. It mainly depends on the hypervisor on which you want to use the image—see Section 2.1.2, “Image Requirements Depending on Hypervisor”.

2.3 Image Properties

Images have both contents and metadata. The latter are also called properties. The following properties can be attached to an image in SUSE OpenStack Cloud. Set them from the command line when uploading or modifying images. For a list of image properties, see http://docs.openstack.org/developer/python-openstackclient/command-objects/image.html.

2.4 Uploading Images

If you have created an image for SUSE OpenStack Cloud Crowbar/OpenStack/KVM with SUSE Studio or with SUSE Studio Onsite 1.3, you can upload the image directly as described in Procedure 2.2, “Uploading Disk Images to SUSE OpenStack Cloud Crowbar.

Procedure 2.1: Converting Disk Images to Different Formats
  1. Make sure the virt-utils package is installed on the machine used for conversion.

  2. Download the image from SUSE Studio.

  3. To convert qcow2 to vhd images, use the following command:

    qemu-img convert -O vpc CURRENT_IMAGE_FILE FINAL_IMAGE_FILE.vhd
Procedure 2.2: Uploading Disk Images to SUSE OpenStack Cloud Crowbar

Upload a disk image using the python-openstackclient client.

Images are owned by projects and can be private (accessible to members of the particular project only) or public (accessible to members of all projects). Private images can also be explicitly shared with other projects, so that members of those projects can access the images, too. Any image uploaded to OpenStack Image will get an owner attribute. By default, ownership is set to the primary project of the user that uploads the image.

Set or modify hypervisor-specific properties with the --property key=value option. This can be done directly during image upload (as shown in the examples below). To change the properties after image upload, refer to Procedure 2.3, “Modifying Image Properties”.

  1. In a shell, source the OpenStack RC file for the project that you want to upload an image to. For details, refer to http://docs.openstack.org/user-guide/common/cli_set_environment_variables_using_openstack_rc.html.

  2. Upload the image using openstack image create. Find some example commands for different hypervisors below:

    • For KVM:

      openstack image create IMAGE_NAME \
        --public --container-format bare \
        --property architecture=x86_64 \
        --property hypervisor_type=kvm \
        --disk-format qcow2 \
        --file PATH_TO_IMAGE_FILE.qcow2
    • For Xen:

      openstack image create IMAGE_NAME \
        --public --container-format bare \
        --property architecture=x86_64 \
        --property hypervisor_type=xen \
        --property vm_mode=xen \
        --disk-format qcow2 \
        --file PATH_TO_IMAGE_FILE.qcow2
      Note
      Note: Value of vm_mode

      For Xen PV image import, use vm_mode=xen, for Xen HVM image import use vm_mode=hvm.

    • For VMware:

      openstack image create IMAGE_NAME \
        --public --container-format bare \
        --property vmware_adaptertype="lsiLogic" \
        --property vmware_disktype="preallocated" \
        --property hypervisor_type=vmware \
        --disk-format vmdk --file PATH_TO_IMAGE_FILE.vmdk
      Note
      Note: Value of vmware_disktype

      Depending on which disk type you use, adjust the value of vmware_disktype accordingly. For an overview of which values to use, refer to https://docs.openstack.org/nova/pike/admin/configuration/hypervisor-vmware.html, section OpenStack Image Service disk type settings.

    • For Docker:

      Find an image in the Docker registry you want to use and save it locally with docker pull IMAGE_NAME, where IMAGE_NAME is the name of the image in the Docker registry. The same name needs to be used when uploading the image with the following command:

      docker save IMAGE_NAME | openstack image create \
      --public --property hypervisor_type=docker \
      --container-format=docker --disk-format=raw IMAGE_NAME
      Important
      Important: Docker Images Need to Run a Long-Living Process

      Docker instances will only be able to spawn successfully, when running a long-living process, for example sshd. Such a process can be configured with CMD or ENTRYPOINT in the Docker.

      Alternatively, such a process can be specified on the command line with the image property os_command_line.

      openstack image set --property os_command_line='/usr/sbin/sshd -D' \
             IMAGE_ID

    If the image upload has been successful, a message appears, displaying the ID that has been assigned to the image.

Note
Note: Updating Images

After having uploaded an image to SUSE OpenStack Cloud, the image contents cannot be modified—only the image's metadata, see Procedure 2.3. To update image contents, you need to delete the current image and upload a modified version of the image. You can also launch an instance from the respective image, change it, create a snapshot of the instance and use the snapshot as a new image.

2.5 Modifying Image Properties

Set or modify hypervisor-specific properties with the --property key=value option. This can be done directly during image upload (see Procedure 2.2) or after the image has been uploaded (as described below).

Procedure 2.3: Modifying Image Properties
  1. In a shell, source the OpenStack RC file for the project that you want to upload an image to. For details, refer to http://docs.openstack.org/user-guide/common/cli_set_environment_variables_using_openstack_rc.html.

  2. If you do not know the ID or the exact name of the image whose properties you want to modify, look it up with:

    openstack image list
  3. Use the openstack image set command to set the properties for architecture, hypervisor type, and virtual machine mode. In the following, find some examples with properties for different hypervisors:

    • For KVM:

      openstacke image set IMAGE_ID_OR_NAME \
        --property architecture=x86_64 \
        --property hypervisor_type=kvm
    • For Xen:

      openstack image set IMAGE_ID_OR_NAME \
        --property architecture=x86_64 \
        --property hypervisor_type=xen \
        --property vm_mode=xen
      Note
      Note: Value of vm_mode

      For Xen PV image import, use vm_mode=xen, for Xen HVM image import use vm_mode=hvm.

    • For VMware:

      openstack image update IMAGE_ID_OR_NAME \
        --property vmware_adaptertype="lsiLogic" \
        --property vmware_disktype="preallocated" \
        --property hypervisor_type=vmware
      Note
      Note: Value of vmware_disktype

      Depending on which disk type you use, adjust the value of vmware_disktype accordingly. For an overview of which values to use, refer to https://docs.openstack.org/glance/latest/admin/useful-image-properties.html, section OpenStack Image Service disk type settings.

For more information about the architecture, hypervisor_type, and vm_mode properties, refer toq https://docs.openstack.org/glance/latest/admin/useful-image-properties.html.

2.6 Using a Custom Kernel to Boot Btrfs Images Under Xen

On Xen hosts, starting instances from an image that uses Btrfs as root file system may fail with SUSE OpenStack Cloud Crowbar 8. As a work-around, boot the Btrfs image with a custom kernel to start the instances. Prepare the Btrfs image as described in Procedure 2.4, “Booting Btrfs Images with a Custom Kernel”.

Procedure 2.4: Booting Btrfs Images with a Custom Kernel
Requirements
  • The python-openstackclient is installed. After you have sourced an OpenStack RC file, use the command line client to upload images from a machine outside of the cloud.

  • To run the python-openstackclient: An OpenStack RC file containing the credentials for the OpenStack project to which you want to upload the images.

  1. Install the grub2-xen package. It provides the grub.xen file required to boot para-virtualized VMs that use the Btrfs file system:

    root # zypper in grub2-x86_64-xen
  2. Create a Glance image with the kernel from this package. For example:

    openstack image create img-grub-xen-x64 \
     --file /usr/lib/grub2/x86_64-xen/grub.xen --public \
     --container-format bare --disk-format raw
  3. Create a second image which uses Btrfs as root file system. For example:

    openstack image create img-btrfs \
      --file openSUSE-Leap-42.1-JeOS-for-XEN.x86_64.qcow2 \
      --container-format bare --disk-format qcow2
  4. Update the image named img-btrfs by adding a kernel_id property to it:

    openstack image set 376c245d-24fe-41e2-8abd-655d4ed8da95 \
    --property kernel_id=72ad3069-6003-4653-86f2-b5914ce33f66

    where 376c245d-24fe-41e2-8abd-655d4ed8da95 is the ID of the image named img-btrfs and 72ad3069-6003-4653-86f2-b5914ce33f66 is the ID of the image named img-grub-xen-x64

  5. Boot the image to start the instance:

    nova boot --flavor FLAVOR --image 376c245d-24fe-41e2-8abd-655d4ed8da95

    This results in a domain XML which contains the kernel you need:

    <domain type='xen' id="2">
     <name>instance-00000003</name>
     <uuid>12b2ce2b-ba1d-4c14-847f-9476dbae7199</uuid>
     <memory unit='KiB'>524288</memory>
     <currentMemory unit='KiB'>524288</currentMemory>
     <vcpu placement='static'>1</vcpu>
     <bootloader></bootloader>
     <os>
       <type>linux</type>
       <kernel>/var/lib/nova/instances/12b2ce2b-ba1d-4c14-847f-9476dbae7199/kernel</kernel>
       <cmdline>ro root=/dev/xvda</cmdline>
     </os>

2.7 Viewing Images and Image Properties, Deleting Images

In the following, find some examples on how to view images or image properties or how to remove images from OpenStack Image.

Listing Images
openstack image list

Lists ID, name, and status for all images in Image that the current user can access.

Showing Metadata for a Particular Image
openstack image show IMAGE_ID_OR_NAME

Shows metadata of the specified image.

Removing Image Properties
openstack image unset --property PROPERTY IMAGE_ID_OR_NAME
Deleting an Image
openstack image delete IMAGE_ID_OR_NAME

Removes the specified image from OpenStack Image.

2.8 Viewing and Modifying Membership of Private Images

In the following, find some examples on how to view or modify membership of private images:

Listing Members a Private Image is Shared With
glance member-list --image-id IMAGE_ID

Lists the IDs of the projects whose members have access to the private image.

Listing Private Images Shared With a Member
glance member-list --tenant-id PROJECT_ID

Lists the IDs of private images that members of the specified project can access.

Granting Members Access to a Private Image
glance member-create [--can-share] IMAGE_ID_OR_NAME PROJECT_ID_OR_NAME

Grants the specified member access to the specified private image.

By adding the --can-share option, you can allow the members to further share the image.

Revoking Member Access to a Private Image
glance member-delete IMAGE_ID_OR_NAME PROJECT_ID_OR_NAME

Revokes the access of the specified member to the specified private image.