Monday, November 12, 2012

Working with oVirt via EC2/CIMI APIs using Deltacloud

Overview

The oVirt engine is a large scale, centralized  virtualization management platform, which provides many Infrastructure as a Service (IaaS) capabilities. Every such capability is exposed via rich API, UI, CLI and SDK.

Motivation

More and more cloud providers start to support more standard and common APIs, such as EC2 and CIMI API. It is useful when working in heterogeneous virtualization environment, in which you have more than one cloud provider, or even when you already have scripts developed to use these APIs, and you would like to use them on top of a different cloud provider. Moreover, existing projects such as Aeolus, HEAT, Synaps and more, support (or plan to support) working with common API(s).

The Deltacloud project allows you to use oVirt (and other cloud providers) using a standard and common cloud APIs, that include EC2, CIMI and the Deltacloud API. This post will focus on EC2 and CIMI APIs, which are new additions to the Deltacloud server.

This blog post will show how you can use Deltacloud in order to perform basic operations via EC2/CIMI APIs, on top of the oVirt engine. This post is informative and technical, and it is directed for those who are interested in a solution for using oVirt via common cloud APIs.

Note that the examples in this blog post were run on oVirt engine 3.1and Deltacloud server version 1.0.4, both running on Fedora 17.

Installing and Running the Deltacloud server

 

Installing the Deltacloud server

The deltacloud server can be installed very easily, using the following commands (Useful for Deltacloud development environment):



Or just using the following command (In a Deltacloud deployment environment):


Running the Deltacloud server

In order to run the Deltacloud server, on top of oVirt, exposing all three APIs (EC2, CIMI and the Deltacloud API) use the following command:



Note that in this command we haven't set the details of the oVirt engine URL. You can do that by setting the API_PROVIDER environment variable. Each Deltacloud server request is in a specific oVirt Data-Center scope, so this variable must contain both the oVirt engine URL, and the oVirt Data-Center ID.

In order to get the available oVirt Data-Centers you can use the oVirt CLI, using the following commands:




Now, you can set the API_PROVIDER as follows:



And run the Deltacloud server as shown before.

Setting the API_PROVIDER only sets the default engine and Data-Center. If you want a specific request to use a different oVirt engine, or a different Data-Center, you can set the "X-Deltacloud-Provider" HTTP Header parameter in your request to a different oVirt engine+Data-Center, and the request scope will change accordingly.

Note that in Fedora, if you installed the deltacloud-core-all package, then you'll get a deltacloud service, that reads its configuration from /etc/sysconfig/deltacloud-core. The problem is, that you cannot configure there the APIs you would like deltacloud to expose, so for now the manual approach is the only way (unless you change the startup scripts to do that for you).

Examples

Now lets move to some examples on using EC2 and CIMI on top of oVirt

EC2 Examples

Note that some operations support passing more than one object to do the operation on, for example InstanceId.1=...&InstanceId.2=... and etc. Deltacloud currently doesn't support more than one object, so all examples contain only one such object.

Get oVirt Clusters (Get Availability Zones)


Request



Response



Get oVirt Templates (Get AMIs)


Request



Response



Create VM from Template in a Cluster (Run Instance created from AMI in an Availability Zone)


Request



Response



Notes:
  • IP Address will be accurate only if guest agent is installed
  • InstanceType is hardcoded as SERVER, as oVirt still doesn't have hardware configuration object (oVirt template contains both hardware and software configuration). Adding instance types is planned for oVirt 3.2.
  • Passing User-Data is supported, currently via oVirt hook that is installed on the oVirt host, but in the future the native VM payload will be supported by Deltacloud as well.


Get VM(s) (Describe Instances)


Request



Response



Start VM (Start Instances)


Request



Response



Note that Deltacloud doesn't query for the status of the object before running this action, so it is set to unknown (-1).

Stop VM (Stop Instances)


Request



Response



Note that Deltacloud doesn't query for the status of the object before running this action, so it is set to unknown (-1).

Delete VM (Terminate Instances)


Request



Response



Note that Deltacloud doesn't query for the status of the object before running this action, so it is set to unknown (-1).

CIMI Examples

The CIMI API is a REST-based API, supporting GET (retrieve objects/collections), POST (create new objects), and DELETE (delete objects). PUT (modifying objects) is currently not supported in Deltacloud.

Get oVirt Templates (Get Images)


Request
In the request we use the URI of the machine_images collection.


Response
The response is a collection of Machine Images. Note that according to the CIMI spec, the ID is the resource URI, the name is the GUID, and the description is the name.


Create VM (Create Machine)


Request
In the request we use the URI of the machines collection, using HTTP POST, and passing body that contains the new machine details.


Response



Get VM (Get Machine)


Request



Response


Note that the list of operations that one can do on a machine changes according to its status. Now that it is STOPPED, you can wither start or destroy it. When creating the machine (in the previous example), it was in PENDING status, so no operations were available.

Start VM (Start Machine)


Request
In the request we use the URI of the specific machine, followed by "start", with an action body.


Response
The response is just HTTP code 200, which means that a start action was triggered. One needs to go HTTP GET on the machine resource to monitor for its progress.

Stop VM (Stop Machine)


Request
In the request we use the URI of the specific machine, followed by "stop", with an action body.


Response
The response is just HTTP code 200, which means that a stop action was triggered. One needs to go HTTP GET on the machine resource to monitor for its progress.

Delete VM (Delete Machine)


Request
In the request we use the URI of the specific machine, using HTTP DELETE.


Response
The response is just HTTP code 200, which means that a delete action was triggered. One needs to go HTTP GET on the machines collection (or the machine itself), so see that it was indeed deleted.

Summary

The oVirt engine is a strong IaaS platform, and it is useful to use this platform using standard APIs, such as EC2 and CIMI. By using Deltacloud, supporting these APIs can be achieved very easily. There is still more work to be done to give better integration between Deltacloud and the oVirt engine, but the basics are there, allowing to use oVirt via standard APIs.

2 comments:

  1. Thank you guys for the feedback!
    Would be happy to hear how you use the Deltacloud integration, on top of what cloud provider you do that, and etc.

    Oved

    ReplyDelete
  2. This is an awesome post Oved..

    I am just getting started with Deltaclouds API.. trying to create a unified portal for AWS, Eucalyptus, Openstack etc..

    This will really help me getting started !!

    Thanks :-)

    ReplyDelete