Instance Overview

• 1: Instance Concepts
• 2: Instance Basics
• 2.1: Virtual Machine Types
• 2.2: Ephemeral Linux Instances
• 2.3: EBS-Backed Instances
• 2.3.1: Comparing Instance Types
• 2.3.2: Using EBS-Backed Instances
• 2.3.3: Suspending and Resuming EBS-Backed Instances
• 2.3.4: EBS EMI Creation Overview
• 2.3.4.1: Create an EBS EMI

1 - Instance Concepts

This section describes conceptual information to help you understand instances.

Eucalyptus Machine Image (EMI)

A Eucalyptus machine image (EMI) is a copy of a virtual machine bootable file system stored in the Walrus storage. An EMI is a template from you can use to deploy multiple identical instances—or copies of the virtual machine.

EMIs are analogous to Amazon Machine Images (AMIs) in AWS. In fact, you can download and deploy any of the 10,000+ AMIs as EMIs in a Eucalyptus cloud without significant modification. While it is possible to build your own EMI, it is might be just as simple to find a thoroughly vetted, freely available image in AWS, download it to your Eucalyptus cloud, and use that instead.

When registered in a Eucalyptus cloud, each distinct EMI is given a unique ID for identification. The ID is in the format emi-.

Instance

A instance is a virtual machine deployed from an EMI. An instance then, is simply a running copy of an EMI, which means it always starts from a known baseline. There are two types of instances; instance store-backed and EBS-backed. This section describes store-backed instances. For information about EBS-backed instances, see Using EBS .

Every instance receives a unique ID in the format i-.

You can deploy multiple instances using a single command. In this case all the instances will have unique instance IDs but will share a common reservation ID. This reservation ID can be seen, for example, from the euca2ools euca-describe-instances command that lists running instances. Reservations IDs appear in the format r-.

Persistence

Applications running in ephemeral instances that generate data that must be saved should write that data to some place other than the instance itself. There are two Eucalyptus options available. First, the data can be written to a volume that is attached to the instance. Volumes provided by the Storage Controller and attached to instances are persistent. Second, the data could be written to the Walrus using HTTP put/get operations. Walrus storage is also persistent.

If the application cannot be rewritten to send data to a volume or the Walrus, then the application should be deployed inside an EBS-backed instance. EBS-backed instances are persistent and operate in a manner more similar to a physical machine.

2 - Instance Basics

Instance Basics

This section describes information to help you decide which type of instance you need.

2.1 - Virtual Machine Types

A virtual machine type, known as a VM type, defines the number of CPUs, the size of memory, and the size of storage that is given to an instance when it boots. There are five pre-defined VM types in Eucalyptus. You can change the quantity of resources associated with each of the five VM types, but you cannot change the name of the VM types or the number of VM types available. If you customize the sizes they must be well-ordered. That means that the CPU, memory, and storage sizes of the next VM type must be equal to, or larger than, the size of the preceding VM type. 

The VM type used to instantiate an EMI must have a defined disk size larger than the EMI file. If a 6GB EMI is loaded into an instance with a VM type defined with a 5GB disk, it will fail to boot. The status of the instance will show as pending .  The pending status is the result of the fact that the Walrus cannot finish downloading the image to the Node Controller because the Node Controller has not allotted sufficient disk space for the download. Starting with Eucalyptus 3.2, if the user attempts to launch an instance with a VM type that is too small, they will receive an on-screen warning and the operation will terminate.

Available VM Types

Eucalyptus, like AWS, offers families of VM types. These families are composed of varying combinations of CPU, disk size, and memory. Eucalyptus offers enough VM types to give you the flexibility to choose the appropriate mix of resources for your applications. For the best experience, we recommend that you launch instance types that are appropriate for your applications.

• This family includes the M1 and M3 VM types. These types provide a balance of CPU, memory, and network resources, which makes them a good choice for many applications. The VM types in this family range in size from one virtual CPU with two GB of RAM to eight virtual CPUs with 30 GB of RAM. The balance of resources makes them ideal for running small and mid-size databases, more memory-hungry data processing tasks, caching fleets, and backend servers. M1 types offer smaller instance sizes with moderate CPU performance. M3 types offer larger number of virtual CPUs that provide higher performance. We recommend you use M3 instances if you need general-purpose instances with demanding CPU requirements.

• This family includes the C1 and CC2 instance types, and is geared towards applications that benefit from high compute power. Compute-optimized VM types have a higher ratio of virtual CPUs to memory than other families but share the NCs with non optimized ones. We recommend this type if you are running any CPU-bound scale-out applications. CC2 instances provide high core count (32 virtual CPUs) and support for cluster networking. C1 instances are available in smaller sizes and are ideal for scaled-out applications at massive scale.

• This family includes the CR1 and M2 VM types and is designed for memory-intensive applications. We recommend these VM types for performance-sensitive database, where your application is memory-bound. CR1 VM types provide more memory and faster CPU than do M2 types. CR1 instances also support cluster networking for bandwidth intensive applications. M2 types are available in smaller sizes, and are an excellent option for many memory-bound applications.

• This Micro family contains the T1 VM type. The t1.micro provides a small amount of consistent CPU resources and allows you to increase CPU capacity in short bursts when additional cycles are available. We recommend this type for lower throughput applications like a proxy server or administrative applications, or for low-traffic websites that occasionally require additional compute cycles. We do not recommend this VM type for applications that require sustained CPU performance. The following tables list each VM type Eucalyptus offers. Each type is listed in its associate VM family.

2.2 - Ephemeral Linux Instances

Instance store-backed instances are ephemeral instances. This means that any changes made to a running instance are lost if the instance is either purposely or accidentally terminated. Applications running in ephemeral instances should write their data to persistent storage for safe keeping. Persistent storage available to instances includes Storage Controller volumes and the Walrus.

As an instance store-backed instance is launched, several files are brought together using loop devices on the Node Controller. As these files are brought together they form what looks like a disk to the instance’s operating system. The illustration below lists a some of the files that make up a running instance. Notice that the EKI, EMI, and ERI images are presented to the instance’s operating system as the partition /dev/sda1 and are mounted as the / file system.

Assume that the illustration above shows some of the files that make up an instance that was launched in a vmtype with 2GB of storage. Notice that the eki-* , emi-* , and eri-* files have been downloaded from the Walrus and cached on the Node Controller. These three files consume around 1.06GB of storage space. Notice also that a swap file was automatically created for the instance. The swap file has the string swap in its name and the file is approximately 500MB in size. It is presented to the instance’s operating system as the partition /dev/sda3 .

This means the EKI, ERI, EMI, and swap files have consumed approximately 1.5GB of the available 2GB of storage space. The remaining 500GB is allocated to the file with the string ext3 in its name. In our example, this space is formatted as an ext3 file system and is made available to the instance as the disk partition /dev/sda2 , and is actually mounted to the /mnt directory in the instance. An example of this configuration is shown below.

2.3 - EBS-Backed Instances

EBS-Backed Instances

Eucalyptus supports two different types of instances; instance store-backed instances and EBS-backed instances. This section describes EBS-backed instances.

With EBS-backed instances you are booting an instance from a volume rather than a bundled EMI image. The boot volume is created from a snapshot of a root device volume. The boot volume is persistent so changes to the instance are persistent.

2.3.1 - Comparing Instance Types

The graphic below illustrates the differences between an instance store-backed instance and an EBS-backed instance.   Both types of instances still boot from an EMI; the difference is what is behind the EMI.   For an instance store-backed instance the EMI is backed by a bundled image.  For an EBS-backed instance the EMI is backed by a snapshot of a volume that contains bootable software, similar to a physical host’s boot disk.

Note that for the instance store-backed instance, the EMI, EKI, and ERI (assuming Linux) are copied from the Walrus directly to Node Controller.  Both disk and memory on the Node Controller are used as cache so an instance store-backed instance can be considered a cache-based instance and is not persistent.  Once the instance is terminated both the RAM and the disk cache are cleared and any modifications to the instance are lost.

When an EBS-backed instance is launched, the snapshot on which the EMI is based is automatically copied to a new volume which is then attached to the instance. The instance then boots from the attached volume. Changes to the EBS-backed instance are persistent because the volume used to boot the EBS-backed instance is persistent.  As a result, EBS-backed instances can be suspended and resumed and not just terminated like an instance store-backed instance.

2.3.2 - Using EBS-Backed Instances

An EBS-backed instance is very much like a physical machine in the way it boots and persists data.  Because an EBS-backed instance functions in a manner similar to physical machine, it makes it a good choice to run legacy applications that cannot be re-architected for the cloud. 

An EBS-backed boot volume can still be protected by taking a snapshot of it.  In fact, other non-boot volumes can be attached to the EBS-backed instance and they can be protected using snapshots too.

2.3.3 - Suspending and Resuming EBS-Backed Instances

An EBS-backed instance can be suspended and resumed, similar to the operating system and applications on a laptop.   The current state of the EBS-backed instance is saved in a suspend operation and restored in a resume operation.  Like instance store-backed instances, an EBS-backed instance can also be rebooted and terminated.

To suspend a running EBS-backed instance:

euca-stop-instances i-<nnnnnnnn>

To resume a suspended EBS-backed instance:

euca-start-instances i-<nnnnnnnn>

To reboot an EBS-backed instance:

euca-reboot-instances i-<nnnnnnnn>

To terminate an EBS-backed instance:

euca-terminate-instances i-<nnnnnnnn>

2.3.4 - EBS EMI Creation Overview

EBS EMI Creation Overview

You can create an EBS EMI from an existing .img file or create your own .img file.  One way to create your own EBS .img file is to use virt-install as described below.

Use virt-install on a system with the same operating system version and hypervisor as your Node Controller. When using virt-install , select scsi as the disk type for KVM if the VIRTIO paravirtualized devices are not enabled. If you have KVM with VIRTIO enabled (the default), select virtio as the disk type of the virtual machine. If you create, successfully boot, and connect the virtual machine to the network in this environment, it should boot as an EBS-backed instance in the Eucalyptus cloud.

To create an EMI for EBS-backed instances will require initial assistance from a helper instance.  The helper instance can be either an instance store-backed or EBS-backed instance and can be deleted when finished.  It only exists to help create the initial volume that will be the source of the snapshot behind the EMI used to boot other EBS-backed instances.

First you will need to create a volume large enough to contain the boot image file that was created by virt-install .  Once this volume has been created attach it to the helper instance. Then transfer the boot image file to the helper instance.  The helper instance must have enough free disk space to temporarily hold the boot image file. Once there, transfer the boot image file, using the dd command, to the attached volume.

At this point the volume can be detached from the helper instance, a snapshot taken, and the snapshot registered as a new EMI.

The process to create a new EMI is summarized as follows:

1. Create the file using (the file is the virtual machine’s disk file).
2. Create the helper instance.
3. Create and attach the volume to the helper instance.
4. Copy the file to the helper instance and from there to the attached volume.
5. Detach the volume and take a snapshot of it.
6. Register the snapshot as a new EMI.

This process is illustrated below.

2.3.4.1 - Create an EBS EMI

To create a new EMI that is used to boot EBS-backed instances:

1. Create a new volume whose size matches the size of the bootable file:

2. Attach the volume to a helper instance:

3. Log in to the instance and copy the bootable image from its source to the helper instance.

4. While logged in to the helper instance, copy a bootable image to the attached volume:

5. While logged in to the helper instance, flush the file system buffers after running the command:

6. Detach the volume from the instance:

7. Create a snapshot of the bootable volume:

8. Register the bootable volume as a new EMI:

9. Run a new EBS-backed instance: