openstack-manuals/doc/training-guide/module001-ch005-vm-provisioning-walk-through.xml

<?xml version="1.0" encoding="utf-8"?>
<chapter xmlns="http://docbook.org/ns/docbook"
  xmlns:xi="http://www.w3.org/2001/XInclude"
  xmlns:xlink="http://www.w3.org/1999/xlink"
 version="5.0"
  xml:id="module001-ch005-vm-provisioning-walk-through">
  <title>VM Provisioning Walk Through</title>
  <para>More Content To be Added ...</para>
  <para>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.</para>
  <para><guilabel>Hypervisors</guilabel></para>
    <para>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 
      <link xlink:href="http://wiki.openstack.org/HypervisorSupportMatrix"></link>
      <link xlink:href="http://goo.gl/n7AXnC">
        http://goo.gl/n7AXnC</link>
      for a detailed list of features and support across the hypervisors.</para>
    <para>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:</para>
    <itemizedlist>
      <listitem>
        <para>KVM- Kernel-based Virtual Machine (visit <link
            xlink:href="http://goo.gl/70dvRb"
            >http://goo.gl/70dvRb</link>)</para>
      </listitem>
      <listitem>
        <para>LXC- Linux Containers (through libvirt) (visit <link
            xlink:href="http://goo.gl/Ous3ly"
            >http://goo.gl/Ous3ly</link>)</para>
      </listitem>
      <listitem>
        <para>QEMU- Quick EMUlator (visit <link
            xlink:href="http://goo.gl/WWV9lL"
            >http://goo.gl/WWV9lL</link>)</para>
      </listitem>
      <listitem>
        <para>UML- User Mode Linux (visit <link
            xlink:href="http://goo.gl/4HAkJj"
            >http://goo.gl/4HAkJj</link>)</para>
      </listitem>
      <listitem>
        <para>VMWare vSphere4.1 update 1 and newer (visit <link
            xlink:href="http://goo.gl/0DBeo5"
            >http://goo.gl/0DBeo5</link>)</para>
      </listitem>
      <listitem>
        <para>Xen- Xen, Citrix XenServer and Xen Cloud Platform (XCP)
          (visit <link xlink:href="http://goo.gl/yXP9t1"
            >http://goo.gl/yXP9t1</link>)</para>
      </listitem>
      <listitem>
        <para>Bare Metal- Provisions physical hardware via pluggable
          sub-drivers. (visit <link xlink:href="http://goo.gl/exfeSg"
            >http://goo.gl/exfeSg</link>)</para>
      </listitem>
    </itemizedlist>
  <para><guilabel>Users and Tenants (Projects)</guilabel></para>
    <para>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.</para>
    <para>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</para>
    <para>For tenants, quota controls are available to limit
      the:</para>
    <itemizedlist>
      <listitem>
        <para>Number of volumes which may be created</para>
      </listitem>
      <listitem>
        <para>Total size of all volumes within a project as measured
          in GB</para>
      </listitem>
      <listitem>
        <para>Number of instances which may be launched</para>
      </listitem>
      <listitem>
        <para>Number of processor cores which may be allocated</para>
      </listitem>
      <listitem>
        <para>Floating IP addresses (assigned to any instance when it
          launches so the instance has the same publicly accessible IP
          addresses)</para>
      </listitem>
      <listitem>
        <para>Fixed IP addresses (assigned to the same instance each
          time it boots, publicly or privately accessible, typically
          private for management purposes)</para>
      </listitem>
    </itemizedlist>
  <para><guilabel>Images and Instances</guilabel></para>
    <para>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 Managementand Volume
      Managementchapters.</para>
    <para>Images are disk images which are templates for virtual
      machine file systems. The image service, Glance, is responsible
      for the storage and management of images within
      OpenStack.</para>
    <para>Instances are the individual virtual machines running on
      physical compute nodes. The compute service, Nova, 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.</para>
    <para>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.</para>
    <para>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.</para>
    <para>Here is an example of the life cycle of a typical virtual
      system within an OpenStack cloud to illustrate these
      concepts.</para>
    <para><guilabel>Initial State</guilabel></para>
  <para><guilabel>Images and Instances</guilabel></para>
    <para>The following diagram shows the system state prior to
      launching an instance. The image store fronted by the image
      service, Glance, 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.</para>
    <para>Figure 2.1. Base image state with no running
      instances</para>
  <figure>
    <title>Initial State</title>
    <mediaobject>
      <imageobject>
        <imagedata fileref="figures/image21.png"/>
      </imageobject>
    </mediaobject>
  </figure>
  <para><guilabel>Launching an instance</guilabel></para>
    <para>To launch an instance the user selects an image, a flavor
      and optionally other 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.</para>
    <para>Figure 2.2. Instance creation from image and run time
      state</para>
  <figure>
    <title>Launch VM Instance</title>
    <mediaobject>
      <imageobject>
        <imagedata fileref="figures/image09.png"/>
      </imageobject>
    </mediaobject>
  </figure>
    <para>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.</para>
    <para>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.</para>
    <para><guilabel>End State</guilabel></para>
      <para>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.</para>
      <para>Figure 2.3. End state of image and volume after instance
        exits</para>
  <figure>
    <title>End State</title>
    <mediaobject>
      <imageobject>
        <imagedata fileref="figures/image22.png"/>
      </imageobject>
    </mediaobject>
  </figure>
      <para>Once you launch a VM in OpenStack, theres 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
        Command Line Interface or the OpenStack Horizon Dashboard.
      </para>
</chapter>