2 Managing Images #
In the SUSE OpenStack Cloud 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 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. Image upload and management may be restricted to cloud administrators or cloud operators only.
Managing images for SUSE OpenStack Cloud requires the following basic steps:
Building Images with SUSE Studio.
For general and hypervisor-specific requirements, refer to Section 2.1, “Image Requirements”.
Uploading Disk Images to SUSE OpenStack Cloud.
Images can either be uploaded to SUSE OpenStack Cloud with the unified
python-openstackclient
from command line or with the SUSE OpenStack Cloud Dashboard. As the Dashboard has some limitations regarding image upload and modification of properties, it is recommended to use the unifiedpython-openstackclient
for comprehensive image management.Specifying Image Properties. You can do so during image upload (using
openstack image create
) or withopenstack image set
after the image has already been uploaded. Refer to Procedure 2.2, “Uploading Disk Images to SUSE OpenStack Cloud” and Procedure 2.3, “Modifying Image Properties”.Important: Properties for Architecture, Hypervisor and VM ModeOpenStack 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 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: .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 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/15-SP1/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/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/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: Image ConversionSparse 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 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/...
), butUUID=...
orLABEL=root
entries. For the latter, add the labelroot
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 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 the following steps are essential:
In SUSE Studio or SUSE Studio Onsite, switch to the
› tab.Enable the
check box.On the Section 2.1.2, “Image Requirements Depending on Hypervisor”.
tab, choose the respective appliance format. It mainly depends on the hypervisor on which you want to use the image—see
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/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”.
Make sure the
virt-utils
package is installed on the machine used for conversion.Download the image from SUSE Studio.
To convert
qcow2
tovhd
images, use the following command:qemu-img convert -O vpc CURRENT_IMAGE_FILE FINAL_IMAGE_FILE.vhd
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”.
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.
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: Value ofvm_mode
For Xen PV image import, use
vm_mode=xen
, for Xen HVM image import usevm_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: Value ofvmware_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: Docker Images Need to Run a Long-Living ProcessDocker 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 theDocker
.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.
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).
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.
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
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: Value ofvm_mode
For Xen PV image import, use
vm_mode=xen
, for Xen HVM image import usevm_mode=hvm
.For VMware:
openstack image update IMAGE_ID_OR_NAME \ --property vmware_adaptertype="lsiLogic" \ --property vmware_disktype="preallocated" \ --property hypervisor_type=vmware
Note: Value ofvmware_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 9. 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”.
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.
Install the
grub2-xen
package. It provides thegrub.xen
file required to boot para-virtualized VMs that use the Btrfs file system:root #
zypper in grub2-x86_64-xenCreate 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
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
Update the image named
img-btrfs
by adding akernel_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 namedimg-btrfs
and72ad3069-6003-4653-86f2-b5914ce33f66
is the ID of the image namedimg-grub-xen-x64
Boot the image to start the instance:
openstack server create --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
openstack image add project [--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
openstack image remove project IMAGE_ID_OR_NAME PROJECT_ID_OR_NAME
Revokes the access of the specified member to the specified private image.