More Content To be Added ... OpenStack Compute gives you a tool to orchestrate a cloud, including running instances, managing networks, and controlling access to the cloud through users and projects. The underlying open source project's name is Nova, and it provides the software that can control an Infrastructure-as-a-Service (IaaS) cloud computing platform. It is similar in scope to Amazon EC2 and Rackspace Cloud Servers. OpenStack Compute does not include any virtualization software; rather it defines drivers that interact with underlying virtualization mechanisms that run on your host operating system, and exposes functionality over a web-based API. Hypervisors OpenStack Compute requires a hypervisor and Compute controls the hypervisors through an API server. The process for selecting a hypervisor usually means prioritizing and making decisions based on budget and resource constraints as well as the inevitable list of supported features and required technical specifications. The majority of development is done with the KVM and Xen-based hypervisors. Refer to http://goo.gl/n7AXnC for a detailed list of features and support across the hypervisors. With OpenStack Compute, you can orchestrate clouds using multiple hypervisors in different zones. The types of virtualization standards that may be used with Compute include: KVM- Kernel-based Virtual Machine (visit http://goo.gl/70dvRb) LXC- Linux Containers (through libvirt) (visit http://goo.gl/Ous3ly) QEMU- Quick EMUlator (visit http://goo.gl/WWV9lL) UML- User Mode Linux (visit http://goo.gl/4HAkJj) VMWare vSphere4.1 update 1 and newer (visit http://goo.gl/0DBeo5) Xen- Xen, Citrix XenServer and Xen Cloud Platform (XCP) (visit http://goo.gl/yXP9t1) Bare Metal- Provisions physical hardware via pluggable sub-drivers. (visit http://goo.gl/exfeSg) Users and Tenants (Projects) The OpenStack Compute system is designed to be used by many different cloud computing consumers or customers, basically tenants on a shared system, using role-based access assignments. Roles control the actions that a user is allowed to perform. In the default configuration, most actions do not require a particular role, but this is configurable by the system administrator editing the appropriate policy.json file that maintains the rules. For example, a rule can be defined so that a user cannot allocate a public IP without the admin role. A user's access to particular images is limited by tenant, but the username and password are assigned per user. Key pairs granting access to an instance are enabled per user, but quotas to control resource consumption across available hardware resources are per tenant. While the original EC2 API supports users, OpenStack Compute adds the concept of tenants. Tenants are isolated resource containers forming the principal organizational structure within the Compute service. They consist of a separate VLAN, volumes, instances, images, keys, and users. A user can specify which tenant he or she wishes to be known as by appending :project_id to his or her access key. If no tenant is specified in the API request, Compute attempts to use a tenant with the same ID as the user For tenants, quota controls are available to limit the: Number of volumes which may be created Total size of all volumes within a project as measured in GB Number of instances which may be launched Number of processor cores which may be allocated Floating IP addresses (assigned to any instance when it launches so the instance has the same publicly accessible IP addresses) Fixed IP addresses (assigned to the same instance each time it boots, publicly or privately accessible, typically private for management purposes) Images and Instances This introduction provides a high level overview of what images and instances are and description of the life-cycle of a typical virtual system within the cloud. There are many ways to configure the details of an OpenStack cloud and many ways to implement a virtual system within that cloud. These configuration details as well as the specific command-line utilities and API calls to perform the actions described are presented in the Image Management and Volume Management chapters. Images are disk images which are templates for virtual machine file systems. The OpenStack Image Service is responsible for the storage and management of images within OpenStack. Instances are the individual virtual machines running on physical compute nodes. The OpenStack Compute service manages instances. Any number of instances maybe started from the same image. Each instance is run from a copy of the base image so runtime changes made by an instance do not change the image it is based on. Snapshots of running instances may be taken which create a new image based on the current disk state of a particular instance. When starting an instance a set of virtual resources known as a flavor must be selected. Flavors define how many virtual CPUs an instance has and the amount of RAM and size of its ephemeral disks. OpenStack provides a number of predefined flavors which cloud administrators may edit or add to. Users must select from the set of available flavors defined on their cloud. Additional resources such as persistent volume storage and public IP address may be added to and removed from running instances. The examples below show the cinder-volume service which provide persistent block storage as opposed to the ephemeral storage provided by the instance flavor. Here is an example of the life cycle of a typical virtual system within an OpenStack cloud to illustrate these concepts. Initial State Images and Instances The following diagram shows the system state prior to launching an instance. The image store fronted by the Image Service has some number of predefined images. In the cloud, there is an available compute node with available vCPU, memory and local disk resources. Plus there are a number of predefined volumes in the cinder-volume service. Figure 2.1. Base image state with no running instances

Launching an instance To launch an instance, the user selects an image, a flavor, and other optional attributes. In this case the selected flavor provides a root volume (as all flavors do) labeled vda in the diagram and additional ephemeral storage labeled vdb in the diagram. The user has also opted to map a volume from the cinder-volume store to the third virtual disk, vdc, on this instance. Figure 2.2. Instance creation from image and run time state

The OpenStack system copies the base image from the image store to local disk which is used as the first disk of the instance (vda). Having small images will result in faster start up of your instances as less data needs to be copied across the network. The system also creates a new empty disk image to present as the second disk (vdb). Be aware that the second disk is an empty disk with an emphemeral life as it is destroyed when you delete the instance. The compute node attaches to the requested cinder-volume using iSCSI and maps this to the third disk (vdc) as requested. The vCPU and memory resources are provisioned and the instance is booted from the first drive. The instance runs and changes data on the disks indicated in red in the diagram. There are many possible variations in the details of the scenario, particularly in terms of what the backing storage is and the network protocols used to attach and move storage. One variant worth mentioning here is that the ephemeral storage used for volumes vda and vdb in this example may be backed by network storage rather than local disk. The details are left for later chapters. End State Once the instance has served its purpose and is deleted all state is reclaimed, except the persistent volume. The ephemeral storage is purged. Memory and vCPU resources are released. And of course the image has remained unchanged throughout. Figure 2.3. End state of image and volume after instance exits

Once you launch a VM in OpenStack, there's something more going on in the background. To understand what's happening behind the dashboard, lets take a deeper dive into OpenStack’s VM provisioning. For launching a VM, you can either use the command-line interfaces or the OpenStack dashboard.