Using Instances

• 1: Instance Overview
• 1.1: Instance Concepts
• 1.2: Instance Basics
• 1.2.1: Virtual Machine Types
• 1.2.2: Ephemeral Linux Instances
• 1.2.3: EBS-Backed Instances
• 1.2.3.1: Comparing Instance Types
• 1.2.3.2: Using EBS-Backed Instances
• 1.2.3.3: Suspending and Resuming EBS-Backed Instances
• 1.2.3.4: EBS EMI Creation Overview
• 1.2.3.4.1: Create an EBS EMI
• 2: Instance Tasks
• 2.1: Authorize Security Groups
• 2.2: Create Key Pairs
• 2.3: Find an Image
• 2.4: Launch an Instance
• 2.5: Log in to an Instance
• 2.6: Reboot an Instance
• 2.7: Terminate an Instance

1 - Instance Overview

Instance Overview

An instance is a virtual machine (VM). Eucalyptus allows you to run instances from registered images.

The following sections describe instances in more detail.

1.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.

1.2 - Instance Basics

Instance Basics

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

1.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.

1.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.

1.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.

1.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.

1.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.

1.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>

1.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.

1.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:

2 - Instance Tasks

Instance Tasks

This section describes the tasks you can perform with instances in Eucalyptus.

2.1 - Authorize Security Groups

Before you can log in to an instance, you must authorize access to that instance. This done by configuring a security group for that instance.

A security group is a set of networking rules applied to instances associated with a group. When you first create an instance, it is assigned to a default security group that denies incoming network traffic from all sources. To allow login and usage of a new instance, you must authorize network access to the default security group with the euca-authorize command.

To authorize a security group, use euca-authorize with the name of the security group, and the options of the network rules you want to apply.

euca-authorize <security_group>

Use the following command to grant unlimited network access using SSH (TCP, port 22) and VNC (TCP, ports 5900 to 5910) to the security group default :

euca-authorize -P tcp -p 22 -s 0.0.0.0/0 default
euca-authorize -P tcp -p 5900-5910 -s 0.0.0.0/0 default

2.2 - Create Key Pairs

Eucalyptus uses cryptographic key pairs to verify access to instances. Key pairs are used if you want to connect to your instance using SSH. Creating a key pair generates two keys: a public key (saved within Eucalyptus) and a corresponding private key (output to the user as a character string). To enable this private key you must save it to a file and set appropriate access permissions (using the chmod command), as shown in the example below.

Create Key Pairs with the Console

From the main dashboard screen, click the Key Pairs icon. The Key Pairs page opens. Click the Create Key Pair button. The Create new key pair window opens. Type a name for the new key pair into the Name text box. The name may contain up to 255 alphanumeric and special characters. Click the Create and Download button. The private half of the key pair (.pem file) is saved to the default download location for your browser.

chmod 0600 <keypair_name>.private

Create Key Pairs with the Command Line

Enter the following command:

euca-create-keypair <keypair_name> -f <keypair_name>.private

where <keypair_name> is a unique name for your keypair. For example:

euca-create-keypair alice-keypair -f alice-keypair.private 

The private key is saved to a file in your local directory. Query the system to view the public key:

euca-describe-keypairs

The command returns output similar to the following:

KEYPAIR alice-keypair ad:0d:fc:6a:00:a7:e7:b2:bc:67:8e:31:12:22:c1:8a:77:8c:f9:c4

2.3 - Find an Image

To find an image:

Enter the following command:

euca-describe-images

The output displays all available images.

IMAGE	emi-EC1410C1	centos-32/centos.5-3.x86.img.manifest.xml ↵
admin	available	public 	x86_64	machine
IMAGE	eki-822C1344	kernel-i386/vmlinuz-2.6.28-11-server.manifest.xml ↵
admin	available	public 	x86_64	kernel
IMAGE	eri-A98C13E4  initrd-64/initrd.img-2.6.28-11-generic.manifest.xml ↵
admin	available	public 	x86_64	ramdisk

Look for the image ID in the second column and write it down. The image ID starts with emi- . Once you find a suitable image to use, make sure you have a keypair to use.

2.4 - Launch an Instance

To launch an instance:

Use the euca-run-instances command and provide an image ID and the user data file, in the format euca-run-instances <image_id> . For example:

euca-run-instances emi-EC1410C1 

For additional details and options that can be used with the euca-run-instances command. Enter the following command to get the launch status of the instance:

euca-describe-instances <instance_id>

Need response from Eucalyptus then uncomment the para below.

2.5 - Log in to an Instance

For a Linux Instance

When you create an instance, Eucalyptus assigns the instance two IP addresses: a public IP address and a private IP address. The public IP address provides access to the instance from external network sources; the private IP address provides access to the instance from within the Eucalyptus cloud environment. Note that the two IP addresses may be the same depending on the current networking mode set by the administrator. For more information on Eucalyptus networking modes, see the Eucalyptus Administrator’s Guide.

To use an instance you must log into it via ssh using one of the IP addresses assigned to it. You can obtain the instance’s IP addresses using the euca-describe-instances query as shown in the following example.

To log into a VM instance:

Enter the following command to view the IP addresses of your instance:

euca-describe-instances

Eucalyptus returns output similar to the following:

RESERVATION	r-338206B5	alice	default
INSTANCE	i-4DCF092C  emi-EC1410C1  192.168.7.24	  10.17.0.130 ↵ running 	alice-keypair 	0 	m1.small  2010-03-15T21:57:45.134Z

Note that the public IP address appears after the image name, with the private address immediately following.

Look for the instance ID in the second field and write it down. Use this ID to manipulate and terminate this instance.

ssh -i alice-keypair.private root@192.168.7.24 

You are now logged in to your Linux instance.

Using SSH to Connect via PuTTY

If you are a Windows user and want to securely connect to instances via PuTTY, you must first have a key pair.If you don’t have a key pair, you can create one through the Management Console or the command line. For the key pair to be used with PuTTY, convert your .pem file to a .ppk file by performing the last step in the Creating SSH Credentials for the Master Node: Modify Your PEM File procedure.

2.6 - Reboot an Instance

Rebooting preserves the root filesystem of an instance across restarts. To reboot an instance:

Enter the following command:

euca-reboot-instances <instance_id>

To reboot the instance i-34523332 , enter:

euca-reboot-instances i-34523332

2.7 - Terminate an Instance

The euca-terminate-instances command lets you cancel running VM instances. When you terminate instances, you must specify the ID string of the instance(s) you wish to terminate. You can obtain the ID strings of your instances using the euca-describe-instances command.

Enter euca-describe instances to obtain the ID of the instances you wish to terminate. Note that an instance ID strings begin with the prefix i- followed by an 8-character string:

euca-describe-instances
RESERVATION	r-338206B5	alice	default
INSTANCE	i-4DCF092C  emi-EC1410C1	192.168.7.24	10.17.0.130 ↵
running 	mykey 	0 	m1.small 	2010-03-15T21:57:45.134Z ↵
wind 	eki-822C1344 	eri-BFA91429

Enter euca-terminate-instances and the ID string(s) of the instance(s) you wish to terminate:

euca-terminate-instances i-4DCF092C
 INSTANCE	i-3ED007C8