Images & Snapshots screen

If you’re familiar with virtualization technologies such as XenServer, KVM, VMware, or Hyper-V, your idea of VM creation might be to start with creating the virtual hardware and then loading the software. But as was previously explained, OpenStack is on a higher level of abstraction than a traditional hypervisor. The VM (Instance) screen doesn’t provide a way to attach virtual media, and based on the expected usage of OpenStack, it shouldn’t. Users are expected to either import VM images pre-made for OpenStack (such as Ubuntu at https://cloud-images.ubuntu.com/ and CentOS at http://cloud.centos.org/centos/) or select an existing image. OpenStack images can be thought of as bundles of data that OpenStack applies to virtual hardware to provide a VM.

CLOUD IMAGES OpenStack can support any OS your underlying hypervisor supports. However, images typically used with OpenStack, as well as public cloud providers like Amazon EC2, contain additional tools used in the provi- sioning and operation of the underlying VM environment. One of these tools is cloud-init (https://help.ubuntu.com/community/CloudInit), which allows cloud frameworks to provide the operating system information related to resource assignments (host name, IP address, and so on).

This isn’t to say that there’s no way to boot a VM from an installation ISO (Interna- tional Standards Organization 9660/13346) image and create a new image based on that installation. In fact, OpenStack has made specific provisions, like booting from ISO, to accommodate the use of commercial license–restricted operating systems, like Microsoft Windows. Many image formats, including RAW, VHD, VMDK, VDI, ISO,

If you compare IP addresses to telephone numbers, it’s easy to draw the distinction between public and private addresses. Two companies can’t have the same tele- phone number, just as they can’t share the same public IP address space. But two companies can use the exact same private address space, just as two companies could use the exact same internal numbering scheme for phone extensions. In both cases, you can’t remotely reach a private address or extension without first routing to a public address or phone number. In the private space, you might have thousands of private addresses or extensions behind a single public address.

In 1998, RFC 2460 (Internet Protocol Version 6 (IPv6)) was developed, and it speci- fied the direct addressability of a mind-boggling 3.4 × 101038 _{objects. There are far}

more IPv6 addresses than grains of sand on Earth (10 × 1024_{), so it should have the}

“Internet of Things” covered. Most devices and operating systems now support IPv6, but its native deployment is still limited due in part to the use of private address ranges.

QCOW, AKI, ARI, and AMI, are natively supported by OpenStack. But although many images are supported, there are several OpenStack-specific image requirements for full functionality, so it’s recommended you start with pre-built images.

The name of the Images & Snapshots management screen would suggest that images and snapshots are technically different things, but there’s very little technical difference between the two. It’s common to think of images as “VMs waiting to hap- pen,” void of user data. You can think of snapshots as pictures or “snapshots in time” of existing VMs and their related data. You can also think of snapshots as backups, but given that we also create VMs (instances) from snapshots, the distinctions between images and snapshots are blurred.

There’s a transitive relationship between images and snapshots: image => VM, VM => snapshot, so image => snapshot. Thus, in OpenStack, images = snapshots + metadata. Fig- ure 2.7 illustrates how an image becomes a VM, a VM a snapshot, and a snapshot aVM.

On the Images & Snapshots management screen shown in figure 2.8 you have the ability to do the following:

 Create images—You can import an image by uploading a file or specifying a loca- tion on the web. You must specify an image format supported by OpenStack.  Create volumes—You can create a volume (a bootable disk) from either an image

or a snapshot. This action prepares the storage component for the VM (instance) creation process (it acquires resources, clones data, and consumes block storage), but it doesn’t actually create the instance.

OpenStack image formats

When dealing with image files, you might notice various file extensions, related to file formats. The following list describes image formats supported by OpenStack:

 RAW—An unstructured format. The extension could be “raw” or you could simply have an image with no extension.

 VHD (Virtual Hard Disk)—Originally a Microsoft virtual disk format, but the image specification has been licensed to other vendors.

 VMDK (Virtual Machine Disk)—Originally a VMware format, but it has since been placed in the public domain. This is a very common disk format.  VDI (Virtual Disk Image or VirtualBox Disk Image)—An Oracle VirtualBox-

specific image container.

 ISO—An archival format for optical images. It’s mostly used in the creation of VMs from install disks.

 QCOW (QEMU Copy On Write)— A machine image format used by the hosted virtual machine monitor QEMU.

 AKI— An Amazon kernel image.  ARI—An Amazon ramdisk image.  AMI—An Amazon machine image.

There are also specifications for container formats for images, but OpenStack doesn’t currently support containers.

Image VM 0 Launch instance Create snapshot New VM New VM

Disk image has data to create new VMs

Snapshot has data to create new VMs VM 1 VM 0 VM 0 Snapshot of VM 0 Snapshot of VM 0 Launch instance

Figure 2.7 Image-snapshot relationships

Take another look at figure 2.8. The Images & Snapshots screen has two sections:  Images—Operating system configurations and data for creating new VMs.  Volume Snapshots—Exact replicas of data contained in the volume of a VM.

These can be used as backups or to create a new VM with the data and configu- ration of an existing VM.

The Volume Snapshots section is used for creating volumes from snapshots or delet- ing snapshots. We’ll cover volume creation shortly, and volume deletion should be self-explanatory.

In the Images section, the images and snapshots are listed. The Public tab shows the images that are available to anyone in this OpenStack deployment. The image named cirros-0.3.1-x86_64-uec was created by the DevStack process for testing. In contrast, any snapshots or images you create while in a specific project, unless they’re explicitly specified as public, will be listed under the Project tab. By clicking the Launch button, you can create a new instance based on an available image. We’ll dis- cuss instance creation shortly, in section 2.3.5.

For now, let’s take a look at how you can create a new image. If you click the Create Image button, you’ll be presented the pop-up window shown in figure 2.9.

As previously described, you need to provide an image source, format, and mini- mum requirements. Once you click Create Image, OpenStack will make the image available for use.

Now let’s take a look at the storage mechanism for OpenStack instances (VMs).